“We have eliminated the word ‘escalation’ from our vocabulary,” says Marco Bill-Peter, vice president of Global Support Services at Red Hat. Meanwhile, Steve Young, in charge of Service Business Transformation at Cisco, talks about “playing catch, not ping-pong,” and how “the first person to work on a customer issue (case or incident) [should engage] the best resources needed to solve the issue and [manage] it to resolution.” Red Hat and Cisco are just two of a number of companies that are rethinking how they align people with work. The old model of levels or tiers of support and the escalation process is giving way to a new model of collaboration: intelligent swarming.
Intelligent swarming is a dramatically different way to organize the support organization, challenging thirty years of accepted practice and structure in support. However, the early adopters of this model are seeing improvements in all key operational measures of support, including productivity, time to resolve, employee growth, and customer satisfaction. And while it is not appropriate for all support environments, swarming is most effective when solving new, complex problems. The goal is to get the right people working on new issues, together, and as quickly as possible. Intelligent swarming facilitates the collaboration already happening between support agents and leads to faster and more creative resolutions.
Let’s examine what is driving this change, how it works, where it applies, and why it can be a more efficient and effective way to deliver support.
Why Is the Tiered Support Model Becoming Obsolete?
There are three drivers behind this change. First, support organizations are doing a better job of capturing and reusing what they collectively know. Many support organizations have implemented Knowledge-Centered Support (KCS), a methodology that focuses on creating and maintaining knowledge as a by-product of solving customer issues. By searching the knowledge base, support agents can quickly find answers to customer questions and problems that have already been solved. Reusing the knowledge improves the rate at which issues are recognized as known, as well as the speed and accuracy in providing customers with resolutions. As a result, known issues are resolved faster with fewer escalations. To achieve a corresponding improvement in solving new issues, we need to facilitate collaborative problem solving.
Second, the steady increase in customer self-service activity is changing the ratio of new to known issues that come into the support center. (“Known” issues are those that are captured and searchable in the knowledge base. “New” issues require diagnostic activity or research before they can be resolved.) KCS creates content in the customer’s context, so knowledge articles are searchable and usable by customers on the web. As customer use of and success with self-service increases, the number of known issues reported to the support center declines, shifting the ratio of support requests to new issues.
As solutions move closer to customers via web-based self-help, the response processes in the support center must change. In the past, support tiers acted as filters, with each level resolving 70 to 80 percent of the problems it received. The problem had to be pushed or escalated toward the solution. With the web, we are pushing the solutions toward the problem! Customers are now solving 80 percent of their issues using the web. This is a great thing, but there are two important implications. First, a positive web experience resets customer expectations about time to resolution. Second, when customers contact the support center (for the 20 percent of issues that aren’t solved on the web), the likelihood that problem will require escalation is very high. This has a compound effect. Customers expect an immediate response, and the chance that the problem can be solved on first contact is much lower than it used to be. The support requests coming into the center are new, unique, complex issues. As a result, customers who can’t find a solution on the web feel like they have to “run the gauntlet” to get their problem solved…every time! As known issues are removed from the support organization’s workflow and the percentage of new issues increases, we need to rethink how we align resources to work.
Third, support organizations are undergoing a shift in focus from internal productivity to customer productivity. This is a deeper, more philosophical transformation, one characterized by a broader sense of awareness that includes the customer and the customer experience. At Microsoft, one of the key metrics they are using to measure their success is customer effort. Yahoo! has become obsessed with understanding the customer experience. And Oracle is changing its support vocabulary, swapping “cases” and “customer satisfaction” for “customer health” and “productivity.” The enlightened support organization is as concerned with customer productivity as it is with its own productivity. We can no longer optimize our productivity at the expense of our customers’. Enter intelligent swarming.
How Does Intelligent Swarming Work?
Swarming is not a new concept for support agents and engineers. They have always collaborated to solve problems, often in spite of the processes, structures, and measures we traditionally use in customer support. So what if we facilitated collaboration instead of inhibiting it?
Support organizations with good self-service models are rethinking their support processes and moving from an escalation-based model to a collaboration-based model. They are collapsing their support tiers, creating a single team of people who collaborate on solving customer issues (playing catch). This is replacing the model of multiple teams that toss issues back and forth through incident routing, rerouting, escalation, and rejection (playing ping-pong).
Intelligent swarming is about getting the best people to solve the issue working on the issue as quickly as possible. While we don’t have tiers of support in a swarming model, we do have many different types of skills. We seek to engage the most appropriate or relevant skill(s) on a customer issue, based on what we know about the customer (some are experts, some are novices) and the issue. At the highest level, we could think about generalists and specialists. Some issues are poorly defined and require lateral-thinking skills and an ability to talk to customers in their own context. This is the value of the generalist; they help define the problem when the customer can’t. A good generalist can define the issue in such a way that we can turn around and identify required the specialist skill. However, if the problem is already well defined, we may be able to immediately identify the specialist(s) that would be best able to resolve the issue. The most valuable resource to the support organization is a support agent that is both a generalist and a specialist.
In a swarming model, the person who takes ownership of the issue often owns the issue until it is resolved. They may engage others in the process of solving the issue, but they don’t toss it over the wall (escalate) and lose touch with the resolution. This is how we create support agents who are both generalists and specialists! More importantly, this is how collaboration enables skill development. In the existing model, we aren’t giving people the opportunity to develop the range of skills that are most valuable to the support organization.
Unfortunately, a collaborative process doesn’t align with the way most support organizations think about their people or their processes. Over the years, a caste system has emerged between the tiers, with a strong sense of “us versus them,” and arbitrary boundaries that can only be crossed by escalation. The idea that anyone in support could “earn the right not to have to talk with customers” (a common attitude in higher tiers) is a ridiculous notion. Customer support is, after all, about supporting customers. Thus, the transition from a streaming model (the old, linear, tiered structure) to a swarming model (collaborative) is not easy. It is a significant social change in that we are dismantling the support caste system.
Swarming also requires us to give up the highly siloed and compartmentalized structures we have created. Too many support organizations have become so enamored with their internal processes and service levels between support tiers that they have adopted the dysfunctional practice of “rejecting” incidents. They are more focused on their niche processes and metrics than on solving the customer’s issue, when the only service level agreement that truly matters is the one with the customer. By contrast, in a swarming model we don’t reject customer issues. We pursue their resolution with enthusiasm; we choose to help.
Intelligent Swarming: When Is It Appropriate?
As a general rule, intelligent swarming is most valuable in solving new, complex issues. Two key considerations in determining whether intelligent swarming makes sense are complexity and the ratio of new issues to known issues. Time to resolve is a reasonable indicator for both. If your support center solves a high percentage of customer issues in three to five minutes, it would imply that a high percentage of your issues are known and the complexity is low. While a robust KCS program can improve the speed and consistency of resolution in this environment, swarming typically doesn’t make sense.
If your average time to resolve is greater than fifteen minutes, this would imply a fair amount of complexity and possibly a higher rate of new issues being reported. Ideally, we want to use our support resources to solve new issues, not ones we have already solved. The goals are to get the known issues to the customer through self-service (or remove the cause of the known issues from the environment through root cause analysis) and facilitate a collaborative problem-solving process for new issues.
Is This Really a Better Way?
Four members of the Consortium for Service Innovation are promoting and enabling variations on intelligent swarming: BMC, Cisco, Microsoft, and Red Hat. Each has reported some very compelling benefits. At BMC, one product team has achieved the highest level of customer satisfaction it has ever enjoyed; the backlog is down, and employee morale and enthusiasm is at an all-time high. Cisco, meanwhile, is in the midst of a major initiative to improve their tools’ collaboration capabilities by enabling both a "request for help" model and an "opt-in for help" model. Their goal is to improve skills development for the support engineers and to get the right engineer(s) working on an issue as quickly as possible. The initial results are faster problem resolution, less escalation and bouncing of the customer between people and teams, and a very positive reception by the support engineers.
Microsoft has a program that helps support agents find the right peer for collaboration. In a large, global support organization, knowing who could help best is a major challenge. Microsoft is building rich profiles of support agents, including agent interests and a skills profile based on the content the agent has created, modified, or linked in the past ninety days. This skills profile is maintained by the system, so the profile is always up-to-date and contains a sufficient level of detail to ensure relevant connections.
As mentioned earlier, Red Hat has both integrated KCS and the swarming model and banned the word “escalation” from its vocabulary. By improving the support engineer’s visibility on relevant work and thinking about the support team as a community, they are seeing improved skills development, faster problem resolution, and increased customer satisfaction.
Intelligent Swarming: A Work in Progress
For the past eight years, the Consortium for Service Innovation has been searching for a better way to align people and work, and we are currently working to identify the swarming principles and practices that will enable support organizations to make this dramatic shift efficiently and effectively. Since intelligent swarming is an emerging practice, we don’t have operational experience with all elements of the model as envisioned. However, we are learning a lot about what makes it work and what pitfalls to avoid. If your company is toying with collaboration or is interested in helping to develop the next best practice, please visit www.serviceinnovation.org.
Greg Oxton is the executive director of the Consortium for Service Innovation, a nonprofit alliance of customer support organizations develops innovative ways to address the challenges of customer service and support, like the Knowledge-Centered Support methodology. Before joining the Consortium, Greg held management positions in customer service, operations, planning, support strategy, and development at IBM, N.E.T., and Tandem Computers.