Intelligent Matching at Cisco

Challenges

• 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

Intelligent Matching

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."

Leading Indicators

• 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

Results

• 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

Lessons Learned

• 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.