Date Published October 18, 2016 - Last Updated April 19, 2019
Through several decades of working in and around the customer service areas of information service organizations, I’ve yet to encounter a service desk analyst that can resolve every single contact. For that matter, I’ve yet to see a single support center that never had to call on a second- or third-level team for assistance with resolving an incident. So, why is there so much confusion around the incident escalation process?
Wait…you don’t have a well-defined incident escalation process? By the end of this piece, you will have at least two or three items to work on to move your organization closer to having a well-defined incident escalation process.
As with any ITSM process, the time to define and document a process is not while you are trying to execute the process.
Are the conditions under which an incident is escalated clear to both the support center and the team receiving the escalated incident?
One of the clearest ways to define this is through the use of priority guides. What is a priority guide? It’s a knowledge article written by the second-level team that helps the support center understand the following:
- Application name and description of the issue
- Information to be documented in the incident (browser used, version of app, screenshot of error, etc.)
- Business-hour and after-hours process (escalate, page, etc.)
Having this document in the knowledge base saves a lot of anguish of trying to figure out what to do with the incident during the initial call. It helps to provide the escalated incident with the information needed so the second-level team doesn’t have to make a call to the customer to collect more information prior to starting work on a resolution.
What happens when a ticket is improperly escalated (i.e., could have been solved at level 1)? Should it be fixed first and discussed later? Kicked back to level 1?
Incidents should never be escalated “just because I didn’t know what to do,” which means that the team receiving the escalation should “seek first to understand, then be understood.” If there’s no knowledge article that addresses the issue, the second-level team that received the escalation should create one. Keeping customer service at the center of all support efforts, the customer should not be left hanging because the incident escalation process went off the rails.
Best practice would be for the team receiving the escalated incident to resolve it and educate the support center after resolution. This education can take many forms:
- High-priority and high-impact incidents should have an incident summary report (ISR) generated by the resolving team. The ISR looks at the timeline in detail, from creation to resolution; reviews the root cause; and communicates to all IS management what happened and what action items and follow-up items need to be addressed to avoid any delay in resolution should the incident occur again. Follow-up items could be faster escalation by the support center, better documentation at the initial incident creation, etc.
- Low-priority incidents should have a less-formal process. The team receiving the “improper” escalation should verify the following: the knowledge article is written in a clear manner, and it’s easy to find and execute the resolution; the analysts have the rights to execute the resolution; and the analysts have been trained on executing the resolution. If all three of these are in place, there should be a tool in place for incident feedback from the second-level support team to the support center management team. This allows the support center manager to determine if this is an issue for a one-on-one or training for the entire group. Incident feedback should be completed and delivered within 48 hours of incident creation. Feedback on incidents more than two days old is not effective. Don’t save up incident feedback for your monthly one-on-one meetings! Incident feedback is a learning tool, and a lack of application of the incident feedback is a performance indication.
Are there conditions (extreme volume, for example) under which there may be more escalations? How are those parameters set?
The use of parent and child incidents is a great process for this type of situation. It does require that either someone in the support center or on the team receiving the escalations realizes and communicates that there are many of the same incidents being generated. The process of establishing a parent, which is assigned to the team for resolution, and then attaching additional incidents without assigning them directly to the second-level team is the desired process.
Depending on your incident-tracking tool, how to do this is something for you to discover and train your support center and second-level teams on. It’s not a best practice to simply increase the call count on a single incident. You want a record of each caller, just in case their problem wasn’t exactly the same as the parent incident and requires additional follow up.
The parameters for this type of activity should not be set in stone. Completing an ISR after an incident improves the understanding for handling future occurrences. Through any of these types of situations, it’s important to remember we are in customer service: The support center plays a key middleman role, and it is responsible for minimizing the impact on both callers and second-level teams.
When there is a dispute between the two groups, how is it resolved? What is done to make sure it’s not at the expense of the customer (i.e., excess downtime)?
In addition to the ISR, which is completed by the resolving team, the support center should complete a post-incident review (PIR). The main difference between these two documents is that the ISR focuses on the incident from creation to resolution, while the PIR focuses on the role of the support center’s activity on the incident (e.g., intake, escalation, communication, IVR).
These documents should be reviewed by both teams, and any lessons learned should be assigned for follow up. The point of dispute is not who’s right or wrong, but how both teams can work together so the dispute doesn’t happen again. And those corrective actions or steps need to be weighed against the overall impact on the customer reporting the issue.
Avoid sending customer service over the cliff!
The most successful incident escalation processes include several key components:
- Well-defined process
- Well-defined tools (knowledge articles, ISR, PIR)
- An open dialogue between the support center and all second-level teams receiving escalations
Remember that when end users are unable to use their technology to complete assigned tasks, restoring that functionality is in the best interests of the company, regardless of the role you play in the escalation process.
Johann Stoessel started his first technical service and support job in 1980 and has spent the past 32 years gaining experience in multiple verticals, including local government, manufacturing, banking, insurance, healthcare, retail, and consulting. Regardless of the vertical, Johann has always held positions that allowed him to pursue his number-one goal: connecting with people.
Johann attended his first HDI local chapter meeting in 2000. He had become an officer by the end of the year and has served in many other positions since then. In 2002, Johann joined the faculty at the HDI annual conference, a role he would reprise several times over the next 10 years. The next year, after attending the Local Chapter Officers’ Summit, Johann joined the Member Advisory Board (MAB), serving as the director of the Central region in 2004 and as the chair from 2006–2007.
In 2008, Johann joined the HDI Retail Forum and became the first chair of the Forum’s steering committee. Working with Leslie Cook and a small committee of Forum members, he helped establish a model that quickly added value to the group. Joh currently works for Costco Wholesale as a member of the Incident Management Escalation Team.