Intelligent Matching at Cisco
Play Catch, Not Ping-Pong
In 2010, leaders at Cisco set out on a journey to redefine the customer experience based on a collaboration model instead of an escalation model. While it was tempting to try to “boil the ocean” and start too big, Cisco began by focusing on one specific customer problem.
At the time, the Cisco support structure was very traditional with “lines” of support transferring cases from one level to the next (an escalation model). This meant that the support experience felt like “ping pong;” cases bounced around from engineer to engineer until a resolution was reached. The vision was to change to an intelligent swarming and collaborative engagement model, where the right engineer was identified using a set of key attributes, who then engaged with other experts via collaboration processes.
To facilitate this new model, Cisco had to make many systemic and cultural changes. This case study focuses on one of these changes: exploring the intelligent matching system put in place to help get cases to the right engineer the first time.
- Lack of trust in the tool’s ability to load balance correctly
- The old tools remained available for a time, which prevented movement to the new system
- Culture shift to skills- based routing made people uncomfortable
The work began with a design team comprised of support engineers and first-line managers who focused on creating a sophisticated people profiling system. This system enabled intelligent matching of work to skills, enabled visibility to relevant work, and offered the option to request help from others. In order to make this happen, engineers leveraged a three level taxonomy (Product/Sub-product/problem) that aligns to the work and to the people skills. This enables the routing engine to get cases to the right place.
Great pains were taken to build in the ability for the customer support engineers to indicate their skills and select types of work they are available to take. At Cisco, they feel it is important to allow engineers to have visibility to all relevant work, regardless of whether it is officially assigned to them or not. This enables engineers to not only spend time on their required work, but also opt-in and help others when they have the skills to do so. It also allows them opportunities to grow skills in a new area.
However, facilitating opt-in is not quite enough. The system also must provide tools and processes to ask for assistance from others. To do this, Cisco integrated a way for engineers to request urgent assistance from a specific person or persons. These urgent requests for help appear in the targeted person’s “required” work queue. Non-urgent requests for collaboration appear within the “opt-in” portion of the work queue. To make this all work, there is a rules engine that targets the cases to the right person the first time. When someone says they need to collaborate, the rules engine then connects an engineer to another engineer and creates what looks like a case, but is called a collaboration request. These collaboration requests ensure that the first engineer retains ownership of the case, yet seeks help as soon as it is necessary. This avoids resolution delays or case transfers that would have taken place previously.
The team that designed the system felt that it was important to offer an opportunity for the collaboration participants to fill out a short 3-question survey to assess the interaction. They also wanted to offer an opportunity for peers to express thanks to helpful teammates.
Finally, Cisco provides the engineers with one more avenue to reach out for help. Engineers in need of non-urgent assistance are encouraged to use crowd-source collaboration, which is a forum-style format that is visible to everyone. Relevant crowdsourced items are presented within the optional queue for each engineer. This option has proven to be very effective at encouraging cross- product and cross-LOB participation. It also means that the knowledge generated during these interactions is captured in the knowledge base (within the workflow!) ensuring that others can reuse it.
Cisco has seen transfer and escalation rates drop since focusing on "playing catch."
- Reduction in time to move a case to the right customer support engineer
- Increasing utilization of the collaboration system
- Reductions in resolution time in pilots in multiple teams
- Survey data shows support engineers like the changes
- Improved Mean Time to Final Resolution (MTTFR)
- Transfer rates down
- Escalation rate dropped
- Time to accept case improved
- Be prepared to learn as you go and assume that you will constantly be tweaking the system.
- Make sure you collaborate with your engineers and managers as the system is designed.
- Make sure that all key contributors get credit for participating.
- Offer multiple collaboration requests per case.
- Make a fuss about the collaboration heroes early on in the implementation.
- Measure everything so that you can watch it and improve the routing logic.
- A staff function will not be successful in implementing these changes without the line management and key players taking ownership for the change. Change that is imposed will always be opposed. The people doing the work and their managers must own the changes.
- As much as possible, collapse the tool systems and integrate so that engineers are not jumping from tool to tool. They can click on a button to collaborate, click on a button to post something to the crowd-sourced option and they can click to see all available work.
At Cisco (NASDAQ: CSCO) customers come first. The drive to address specific customer challenges has been with Cisco since its inception. Since then, Cisco has shaped the future of the Internet by creating unprecedented value and opportunity for our customers, employees, investors, and ecosystem partners and has become the worldwide leader in networking - transforming how people connect, communicate, and collaborate.
About the Consortium for Service Innovation
The Consortium for Service Innovation is a non-profit alliance of organizations focused on innovation for the support industry. The Consortium and its members have developed the KCS methodology since 1992, and are committed to developing innovative ways to deliver customer support.
Download as a pdf. Case study developed by MelissaLynne Burch for the Consortium for Service Innovation ©2013 Consortium for Service Innovation. All Rights Reserved. Consortium for Service Innovation and the Consortium for Service Innovation logo are trademarks of Consortium for Service Innovation. All other company and product names are the property of their respective owners.