Tag: support

The key is to create a virtuous cycle of great support, product improvement, and customer loyalty & recommendations. It’s a virtuous cycle of good will. Here are the steps:

What customers want, more than anything else, is for your support to be effective. They want an answer their request promptly, they want us to understand the problem they are having, and help them fix it. Maybe they’d also like to understand a bit about it themselves. Oh, and could you make it so that this problem doesn’t happen anymore?

Tall order. But we all know this is right, because it’s what we all want. But it’s too expensive to deliver that sort of service to everyone, right?

Wrong.

Delivering effective support is more cost effective than any alternative. It solves problems the first time, eliminating call-backs and telephone-tag. It understands the problem, and takes the right actions to document the work-around, file the right bug report, and make the right change to the documentation. It gets that understanding built into the product, making the product better and more valuable.

You want the virtuous cycle, or the vicious one?

The key is to create a virtuous cycle of great support, product improvement, and customer loyalty & recommendations. It’s a virtuous cycle of good will. Here are the steps:

– Do a great job of supporting your customers and understanding their problems

– Build what you learn back into your product

– Repeat

This is simple, but it’s not easy. And this isn’t just the job of the support team. It takes a whole company focus.

Tech Support folks should also be friendly and like helping people. They should be communicative both inside the organization and with customers. Dont just expect your team to “be professional”. That admonition is at the core of the wooden, scripted responses that frustrate customers.

What should you look for when hiring Tech Support staff? My answer to this may be a little counter intuitive.

This last point is very important, and too often overlooked. It’s critical in Tech Support to have a team that will respond well when presented with something they don’t know. Every one of them should not only be comfortable with it, but should relish the opportunity to figure something out.

Tech Support folks should also be friendly and like helping people. They should be communicative both inside the organization and with customers. Don’t just expect your team to “be professional”. That admonition is at the core of the wooden, scripted responses that frustrate customers.

“Knowing the answer doesn’t scale. Hire Tech Support people who can figure things out.”

Why didn’t I include something about technical qualifications? While a foundation of technical expertise may be important in your business, a candidate who is a better problem solver and better with people will still be the best choice, even if they lack experience in some aspect of your product or market. The best Tech Support people learn very quickly, and learn best while solving real problems.

Knowing the answer doesn’t scale. Focusing on “knowing the answer” is part of the “Quick Resolution Paradox” – it puts you on that treadmill that brings ever growing costs and support staff burnout. If you know the answer, you should be working to make sure you never get that question again, first by putting the answer at the fingertips of your users, and then by fixing the product so that this problem goes away forever.

Knowing the answer is a side-effect of providing good support, not its goal.

To make a great Tech Support team, the right hiring is critical. The right folks, with the right skills, will build your reputation with your customers with every call.

This recent research is shows the difference you can get when focusing on resolving problems:

The study found that customers from each company are generally satisfied with hold times, ease of reaching an agent and agent professionalism. In contrast, there was a significant difference in the percentage of customers who reported their problem was solved: 53% of Apple customers reported their problem had been resolved on the call, while 45% of Dell customers and only 39% of HP customers reported they were able to resolve their problem on the call.

My friend Ken wrote a nice piece a couple days ago about ROI and the role of the community manager. In particular, I liked this observation:

… The community is not a structured presence. You cannot simply pen in the community as they’re a wild herd of virtual voices. The skill of the community manager is their expert knowledge in finding these “voices” and listening to them.

I’m not sure I like “4th party” as a description. We spent way too much time at the VRM West Coast Workshop wrangling over the naming of firs, second and third. But when you get past all that, this key idea is really something big:

VRM is about enabling the first party. It is also about building fourth-party user-driven (and within that, customer-driven) services, which make use of first-party enablement.

…

Fourth parties will provide many services for first parties. In fact, VRM should grow large new fourth party businesses, and give new work to large old businesses in the same categories. (Banks, brokers and insurance companies come to mind.) Native enablements, however, need to live with first parties alone, even if fourth parties provide hosting services for those enablements.

Fourth parties also need to be substitutable. They need service portability, just as the customer needs data portability between fourth (and other) party services. That way whatever they can provide can be swapped out by the user, if need be.

I’ll use an example tech support pros will all know: A customer calls, you know the answer, you give it to them and it works, and everyone is happy. Simple, straightforward, case closed. Right?

No. This is a failure. Simply put, if you knew the answer then why did the customer need to call you for it? Why wasn’t the answer quickly available to them? Why wasn’t it already fixed in the product?
The answer immediately at hand for tech support tells you that something else has failed to work, or isn’t completed. Measure it, for sure, but you must drive those known answers out of your system.

In your business, what is it that looks on the surface like a good thing, but is actually an indicator of a more fundamental failure?

Robert Scoble posted details of this week’s blow-up over failing drives and censored forum posts:

Seagate (maker of hard drives and storage devices) has been getting slammed on forums and blogs the past couple of days. Partly because they had a bad batch of hard drives and didn’t properly recognize or fix the problem quickly. Partly because they removed a few anti-Seagate threads from its forums.

This week, Ross Mayfield makes an interesting point about the level of service experience at the Apple Store. It’s a brilliant post and poses some great follow-on questions, but the thing I liked most was this point about support knowledge:

But I think Apple gets something more than the value of customer experience. According to the Consortium of Service Innovation, there is an iceberg effect for product knowledge. 90% of conversations about supporting products never touch the company. Only 10% touch the call center. And 1% of this service and product quality knowledge are assimilated.

Sometimes this distribution is purposeful. Support is viewed as a cost center. Time to resolution (which we’ve decreased by as much as 30%) often trumps customer satisfaction or capturing knowledge. Worst practices are often employed to incent contact center reps to avoid contact.

The problem is far worse with multi-vendor support. Multi-vendor issues take 3-4 times longer to resolve. So almost all vendors explicitly do not support these issues at all. There is some promise in Vendor Relationship Management, or communities that address systemic needs through the demand side supplying itself, but only the beginning of promise.