Swarming to resolve customer’s queries

Christopher Carfi from The Social Customer referred me to this post on his blog suggesting a departure from the traditional triage approach to customer services which he describes as follows:

In emergency and battlefield situations, triage (another definition here) is usually performed in order to best prioritize need and allocate scarce resources. In many modern customer support organizations, a similar idea is used. In customer support orgs, this is usually referred to as “Level 1,” “Level 2,” and “Level 3” support. While the definitions vary, these three support levels are usually defined as some variant on the following:

Level 1: The Level 1 support team is the first point of contact in the incident response process. Customer service personnel are responsible for call handling, triage, problem characterization, and resolution of basic problems. Oftentimes, Level 1 Support answers questions by consulting lists of frequently-asked questions (FAQs).

Level 2: The Level 2 support team is staffed with support engineers assigned by product type. The support engineers are responsible for lab-based simulation, difficult problem resolution, defect correction or escalation management to Level 3 support.

Level 3: The Level 3 support team is staffed with senior analysts, program managers, and development engineers dedicated to working on the critical problems. They are responsible for confirmation of defects, including complex failures, performing interoperability studies, and enacting engineering level changes to permanently resolve any issues in released products.

Instead, Carfi recommended an approach suggested by David Weinberger in The Cluetrain Manifesto in his example of the hyperlinked organisation:

Here’s one example of how things work in a hyperlinked organization: You’re a sales rep in the Southwest who has a customer with a product problem. You know that the Southwest tech-support person happens not to know anything about this problem. In fact, she’s a flat-out bozo. So, to do what’s right for your customer, you go outside the prescribed channels and pull together the support person from the Northeast, a product manager you respect, and a senior engineer who’s been responsive in the past (no good deed goes unpunished!). Via e-mail or by building a mini-Web site on an intranet, you initiate a discussion, research numbers, check out competitive solutions, and quickly solve the customer’s problem – all without notifying the “appropriate authorities” of what you’re doing because all they’ll do is try to force you back into the official channels.

This approach makes more sense to me than the triage approach, irrespective of how well the triage approach may work, mainly because you are presenting the issue to a wider audience within your organisation and there may well be people who can better deal with the issue than the people left sitting in the call centre.  Depending on how the call centre staff are selected, they may also not be the people who actively work on the product or in the service department each day and may not have the best answers anyway.

Carfi made a few really good suggestions including publishing an RSS feed of incoming issues that is fed to everyone dealing with that product; rotating staff in and out of the call centre to ensure that everyone participates in this process and publishing solutions to queries as part of a growing knowledgebase.

The one thing I’d watch out for is making sure that employees don’t spend all their time watching the feed and less time doing the other work.  One way to deal with this may be to delay the feeds by half an hour to an hour or so or even to stagger the feeds.  Works for me and my email.  I find that if I only download email every half hour or so I spend less time watching my inbox and more time working.  My email is attended to too, just not in realtime.

Technorati Tags: , , ,

%d bloggers like this: