(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 techology 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.)
(cross-posted from The Social Customer Manifesto)
Big news today: As of this morning Haystack Networking now supports OpenID! We are entering an age where the users and customers (that's us) are increasingly in control of our own information, at least when interacting with vendors who respect us. That means we're moving away from the silo-oriented model of the industrial age (where the vendors have all the power, and we have none), and moving into a time where we are afforded increasing power and commensurate responsibility. The emergence of disciplines like VRM (Vendor Relationship Management) and CRM2.0 are the bellwethers that are pointing the way, and OpenID is one of the tools that will enable us to get further down the path toward that goal. We've been working on this for a while, and it's important stuff.
Swaps are not just for items, but also for swapping household and business services. Haystack networking allows SwapCircle members to connect based on affinity, interests, geography, and similarity. Since every community is unique, this allows community members to tailor the community to their individual needs.
"
Want to come out and connect with others who are thinking about how social media are changing marketing and customer relationships? You may be interested in attending one of the upcoming sessions of 
Have been road-testing this model over the past few months, most recently with the fine folks from 
So, we're quite fond of our application. (Naturally, we may be a little biased.) But this is really good stuff, especially if you're a road warrior...or even if you just have a long commute. All of the best aspects of the 
The cover story of the current issue of BusinessWeek sums it up well: "
