(Barn raising image: Ian Adams)
As mentioned here, I had the opportunity to spend yesterday speaking with the fine folks from the Consortium for Service Innovation about emerging collaborative technologies, primarily in areas of blogging, wikis and social networking. What I expected was a good, conversational session about how collaboration tools could be used to improve customer support. What I didn’t expect was to leave, head spinning with notions, with an entirely different idea on how to address ongoing customer needs over the course of a business relationship. Happily, however, that’s exactly what occurred.
Perhaps a bit of background on the current “state of the art” (::cough::) in customer support is useful to set the stage. Currently, a large number of organizations view customer service and support (that is, interactions with a customer after the initial sale) as a series of “incidents” that need to be “closed.” That is, when a customer has an issue, the customer contacts the organization’s support center, and opens an “incident” (or a “trouble ticket”) that needs to be resolved. This is very transactional, very discrete.
Customer support is also viewed as a cost center by many organizations. This causes support to be measured internally within an organization with an eye toward keeping support investment as low as possible. How to do this? Use the least-expensive resources that can be mustered in order to close the incidents, and close them as quickly as possible.
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.
(The Level 1, 2, 3 definitions above were generalized from this list from Caspian.)
From the vendor’s perspective, this arrangement makes perfect sense. Support is a cost center. Highly trained development resources are expensive. Many problems can be answered by rote, by Level 1 support (read “inexpensive”) personnel. Therefore, the logical thing to do from the vendor’s perspective is to have incidents come into Level 1 support first and only then, and only if they cannot be resolved, escalated to Level 2 and then, in very rare cases, to Level 3. It’s all very logical, rational and measurable with a stopwatch and a stats counter.
However, that’s not what customers see. Here’s the customer view of support:
(By the way, the graphics above and below were cribbed from the folks over at XPlane. If you haven’t seen the things that Dave Gray, Aric Wood and the team at XPlane have done around Visual Thinking School, you’re missing out.)
From the customer’s point of view, there’s a gatekeeper who is required to exhaust all (inexpensive, and ineffective) possibilities before escalating the incident to Level 2 or Level 3. If escalated to Level 2, all possibilities must be exhausted before escalating to Level 3. It’s slow. It’s inefficient. It’s maddening from the customer’s perspective.
Now, the Level 1-2-3 customer support arrangement is pretty much standard practice, at least across the technology industry. But what if there existed a better way…? (Cue Wayne’s World dream sequence music here.)
The big “a-ha” moment for me yesterday with the consortium was their idea of “swarming” around an incident. Instead of going through the rigid, rote routine of support escalation, what if there was a model that looked like this?
Instead of pushing issues through a funnel, resources
swarm to an issue to resolve it, then disband.
This idea can be described thusly:
Instead of issues (incidents) being pushed through a series of increasingly onerous screens in order to find a solution, what if the solutions were drawn to the issues?
A reading from the Book of Clue, the word according to Dr. Weinberger (p. 127):
“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.”
Dave Weinberger nailed the fundamental aspect of this concept back in 2000, per the above, and now the members of the consortium are actually thinking about how to get it done. As important as the “markets are conversations” meme from Cluetrain is, this idea of resource swarming to resolve customer issues is equally important.
Put another way: when an incident occurs, the right people from the social network that forms the community (from inside the company, from the existing customer base, from the broader community of interested parties) will find out about the issue, collaborate using a combination of formal (e.g. FAQs, formal diagnostic processes) and informal (blogs, wikis, Skype, instant messaging) mechanisms, and resolve the issue in a real, human and adhoc manner. The right people come together with their appropriate tools and skills, and they get the job done together, and then disband and reform fluidly for the next incident.
It’s customer support as barn raising. More here.
How to get there? Some ideas to discuss…
What if we abolished the support “department?” What if individuals in the organization were encouraged to invest, say, 10%-20% of their time working directly with customers (not unlike what Google does with their engineering staff and Google Labs)?
What if people within the organization subscribed to an RSS feed of incidents, and jumped in and helped when something in their wheelhouse came across their feed reader?
What if dynamic, living profiles were set up, a la Haystack, where people within the organization could tag themselves based on their areas of experience and expertise, and be matched up with incidents that they were best suited to resolve?
What if, when those incidents were resolved, they were stored in a public knowelege base that customers could peruse, and help themselves? (Yes, there are a number of systems out there right now that do this, but they are the exception, not the norm.)
