The Art of _Technical_ Customer Service

Guy Kawasaki writes about the art of customer service. While all of the points are applicable, he did not take the one about integrating customer service into the mainstream far enough.

He talks that customer service people receiving accolades as much as sales, engineering and marketing. That's great. But what about actively helping them to do their jobs better. Sales have fancy tools to track customers' pipelines, marketing get party budgets, engineers get multiple-monitors and fancy tech toys. Support is lucky if they get headsets that do not suck.

So, what can be done to increase the productivity for technical support people?

• Are all communications with customers logged with specific cases? Usually this is true. But does that case tracking system allows to have files/attachment linked to it? Does it have web view so that both customer and the support engineer have a common history to discuss if the issue gets hairy? Does the case tracking system records every email sent out to the customer or is it an extra burden to record what's happening?
  
• Are there tools/training that would make common tasks easier? For example, what text editor is being used to look at all those log files? Notepad? Shareware textpad? Or has someone actually introduced a feature rich editor (I like Vim) and trained people in how to use it.
  
• Is there a backchannel from support to engineering and/or customer service advocate? This one is extremely important, as there are many things engineers do not have time to think of when the product is rolled out or updated. Small things like visible versioning of release and patches, like locations and types of configuration and log files, like whether the log files produced by the application miss correlation information such as thread id. Similarly, is there a checklist from support to engineering, QA and doc groups on what kind of things the product needs to have/explain so the new functionality is immediately supportable.
  
• Is there a communication forum (mailing list, IM group, wiki) for the support people, especially if they span multiple locations? Given enough pain, support groups will collect the knowledge themselves, but it will be delayed, fragmented and not universal.
  

These things taken together are a pie in the sky, but each one individually is actually within an easy reach with a strong return on investment. I am presenting at JavaONE this year on a similar topic, so if anybody is interested to chat with me about it, I would be happy to meet.

BlogicBlogger Over and Out