Musings on customer service

I've noticed a trend over the past few years among IT professionals to lose track of the fact that IT is a customer service industry.

Think about that for a minute:  IT is not the end game, it is a service organization that enables other groups to accomplish goals.  I've kept many bosses and customers alike happy over the years by keeping that simple fact in view.

Unfortunately, this trend is moving beyond IT organizations and into customer service groups.  Once upon a time, when you contacted a customer service department and reported an issue, there was a clear process to get the issue resolved.  That process might involve escalating the issue to the engineering department and having a developer fix the issue in the next release of the product or service.

I have noticed that I'm getting more and more "We don't do that." answers back from vendors than I used to.  Customer support is becoming less and less customer focused and seems to be morphing into an organization focused exclusively on reducing company costs by pigeonholing enhancement requests, denying bugs exist (until they are fixed, of course), and being generally unhelpful.

I wonder if customer service managers understand the damage that they are doing to their companies by taking a non-caring attitude towards its customers.  Perception is reality, and once customers decide that a support organization is useless, that perception is difficult to change.  Eventually the poor quality support is going to impact the company's bottom line.  I have already stopped purchasing products and services from one vendor because I got tired of them ignoring issues until the product was old enough that the problem was classified differently and could be closed with a "WONTFIX" status.

There are exceptions to this, of course, and I will gladly reward companies with quality support with more business.  So what do I look for?

• First and foremost a product that "just works".  Something that you setup once, and can completely forget about except when you need to make an operational change: manage capacity, adjust settings, monitor performance.  With a high enough quality product, I may never need to contact support.  Sadly, these are rare.
• Excellent documentation.  If the documentation is good enough, I can generally find examples of what I'm trying to setup, or answer some obscure question by ample notes and clear explanations of how things work and what the design philosophy was.
• A good self-help portal or knowledge base.  It is so much faster to search a quality knowledge base and find well-written articles than it is to go through a support process.  But producing that content and keeping it current is not an easy task, so I appreciate the companies that excel here that much more.  Generally I'll find 2 or 3 topics while looking that I didn't even know I was interested in, so that's the down side -- a good knowledge base creates more work for me, because I found more things that I need or want to do with the product.
• And efficient ticketing and support process.  There are several things that really annoy me when it comes to having to actually open a ticket and get support.

1. Taking the time to collect data, analyze what is going on, present the data in a logical fashion, and lay out the cause-effect relationships in the ticket.  Then I have to spend just as much time talking to the support person on the other end to re-explain everything that I put into the ticket.  Why did I spend the time writing up the ticket explanation if I just had to verbally repeat everything I put into the ticket?
2. Sending the detailed explanation, and then being asked for screen shots that show exactly what I documented, but in an inferior pictorial form.  While reporting a web site issue to a vendor recently, I explained the mechanism by how I discovered the issue, the symptoms of the issue, the causes of the issue, and how to reproduce the issue.  I was asked for screen shots of the problem.  I literally took screen captures of the exact same entry URL and resulting destination URL that caused the problems and replied back, even though both were clearly documented in the problem report.  I do not understand why the textual description was insufficient.  I fear that this is the result of an entire generation of students who were taught visually vs. textually hitting the workforce.
3. Having a screen sharing session be the instant go-to when I have already captured log files showing the beginning state, the command histories showing the actions taken and the resulting state.  I can fully appreciate the ability to virtually watch over someone's shoulder, but when you ask me to login to a device and run the exact same commands as before, see the exact same output that I documented, and offer no alternative approaches, what exactly did that accomplish other than wasting my time?

The key here is that when I contact a support organization, I'm trying to get something done.  The more that support organizations do to:

• give a path to engineering to address product issues
• provide high-quality documentation
• maintain a richly populated and easy to search knowledge base
• create a support process that does not have me doing double work to document and then verbally, visually, or interactively explain the problem

the more credibility they are going to give their company in my eyes, and the more likely I am going to be to support that company financially.