I should really count my blessings. Technical Support, to some companies, means a bank of Rhesus monkeys picking up telephones and telling customers to 'turn it off and then on again'. Previous to this prevalent statement, 'is it plugged in?' was de rigeur until customers found this too insulting to their intelligence -- particularly the ones who did actually forget to plug it in. The point is that a lot of technical support managers live and die by the stats: ring time, hold time, and wrap-up.

It's almost conventional wisdom down in the trenches that this type of management is self-defeating and results in poor service. For instance, if you penalize staff for breaking your arbitrary ten-minute wrap-time, the support representatives are going to dole out bogus information and the customer will inevitably have to call back! But that's just fine with management, because there will be one more call to add to their stats that conforms to the ten-minute wrap-time, where inevitably a second support representative will 'accidentally' cut off the customer at 09:59.0001.

A good customer support department has three main goals: solve problems, prevent problems, and maintain a good relationship between the customer and the company. Ideally, you could call the company and an omnicient semi-deity in the computer field will pick up in one ring, be able to provide the required answer, thank you so much for being a good sport, and sing you a pacifying lullabye to make you feel completely at ease.

In the real world, though, this is not entirely possible. At a minimum, the goal of tech support is to provide you with the solution to a problem, enough background information to prevent knock-on effects of the proposed solution, and steps to prevent the problem from re-occurring. Now if that ain't good service I don't know what is!

At my place of work, we take customer care to this level; the average work time on an issue is 45 minutes. Clearly, this has some scalability concerns, so preventing issues from occurring is paramount. Two ways to accomplish this are effective feedback mechanisms to the developers so outstanding issues can be fixed and documenting known issues.

Once the customer has run into an issue, I feel the company has already let them down, and our job is merely to recover some trust and let them know that they're being taken seriously. As soon as new issues are discovered, they are duly reported to the development team, along with a complete description, and where possible, a reproduction of the bug to make it easier (and quicker!) for them to find the root cause. The end effect is that the software will be modified to correct the problem, or the help file updated, or the wording of an error message changed. Et ouala! A few less phone calls to answer.

Next, any open issues are documented in a knowledge base. This allows customers to locate the solution themselves on our website's search facility, but also allows us to quickly respond to email queries where the KB article fits the customer problem. (It has also has the effect of reduced cases of Repetative Strain Injury in Technical Services by not making them type the same paragraphs over and over again!)

There is a temptation for support representatives to gain knowledge and keep it to themselves so they will be 'important' to the company. The cure is for management to keep an eye on how much KB material individuals are producing and keep that statistic handy for performance reviews!

Finally, a one-on-one response is still the preferred communication model for technical support. Even in the age of instant messaging, chat, forums, and self-help, one-on-one synchronous communication methods still reign. According to the Service and Support Professionals Association, a whopping 54% of technical support is done via email. Slightly less by phone, and impersonal means such as forums and self-service account for only a tiny percentage. Clearly, people want to 'talk to someone' and this is unlikely to change in the near future. I feel that the ideal synergy between the customer and the service provider is that of a partnership. The customer bought our software to solve a problem. Our job is to work with them to make sure that the problem is solved, and does not become an even more formidable problem.

I suspect that supporting utility software may not be the same as supporting an Internet Service Provider or a manufacturer of novelty timepieces, but I hope that I've impressed the importance of taking the time and expending the effort to provide excellent customer service -- and that extends beyond trivia such as how long someone spends on a telephone call!