Some months ago, I took my car in for a safety inspection, and the garage found a small hole on the inside of the wheel-well. In order for the car to pass inspection, they said, that would need to be welded shut.

Great, I said, can we do that now? No, they said. They do not do bodywork. My eye was drawn to the corner of the garage, where I could quite distinctly make out a bottle of acetylene and a welder’s mask. Couldn’t you make an exception, just this once? I’m a busy fellow and I’d rather not make an appointment at a body shop and come back here for re-inspection. Nope. Company policy and all that… sorry… and so forth.

Even though the equipment was there, and the expertise was there, I was inconvenienced by an arbitrary policy that says the garage does not perform body work on cars, even though the hole was somewhere that nobody could even see. I was certainly surprised it was there!

Unsurprisingly, the same paradigm exists in software support, only users who are frustrated to their wit’s end by a software failure refuse to be turned away and sent to Microsoft Product Support Services if the cause of failure is not determined to be our little piece of software!

The complexity of the application doesn’t matter. You could, for example, produce a program that prints ‘Hello World’ to the console. The skill level of the developer writing the application can be minimal or even non-existing, but the support engineer’s required skill level is still astronomical! What if you run helloworld.exe across a network share? What if the user wants to redirect the output to a file? What if the domain administrator has set a policy that prevents the user from opening a command prompt?

Luckily, all software vendors have support departments like ours who can help us find the flaw in the underlying platform our software uses. The downside is that some of these vendors aren’t as easy-going as we are and our enquiries may cost additional time or money. They may require us to buy a support contract or support us for free after some administrative work to set us up with access to their resources. This makes it all too easy for us to say ‘Look, this is not our problem, contact PSS!’. Then the user is standing in the middle of the garage, much like I was, wondering why the welder can’t patch my perferated car body and save me so much time.

For the last few months, Red Gate has been intently looking at improving our knowledge base so that the information is more timely, more appropriate, and easier to locate. I had noticed that there are quite a few KB articles that are drawn from other sources such as SQL Server Books Online and Windows product documentation. We distill this information and make it relevant to a particular product. Companies like Microsoft publish a wealth of really good, freely available resources like Technet, Books Online and insider information from developer blogs, so kudos to them! If only some of the third-party vendors we use would be more forthcoming with their knowledge…

For our part, we do not place any restrictions on the product knowledge that we collect, and if we do encounter a problem that is caused by a third-party, we do our best to solve it for you in the context of our own product. This level of obligation is not easy or cheap, and reflects a high level of commitment to customer satisfaction.