Getting the Incident Escalation process right
Incident Management tends to be one of those ‘must-do but I really wish we could focus on something else’ kind of tasks. But understanding proper Incident escalation is indeed highly important, and can also contribute to less confusion in the Incident Management Process.
Can I fix it straight away?
The first step is the simple question “can I fix this?” If the answer is “no”, then the incident should be escalated to someone else. But keep in mind that there are a lot of tools that can help make sure that the answer here is more often a “yes”.
Implementing and maintaining a solid knowledge base, for example, is a great way to increase your solve rates. Using already generated answers sourced from the team’s experience makes it a lot easier and quicker for a team member to solve the incident themselves without escalation, even if they don’t know the answer by heart. Shift Left, as they say, and bring knowledge down the lines.
Assess the correct escalation
It’s also important to understand who the escalation is for. Generally speaking, there are two forms of escalation in Incident Management. Hierarchical escalation means moving the incident to usually someone with decision-making power. This can be appropriate if it seems like a bigger task, or some aspect of the Incident needs a sign-off.
Functional escalation is about targeting someone who has the required expertise. This means reassigning the incident to another team that are more suitable to deal with the task – either through emails or in your Service Management software. In some tools like TOPdesk, for example, you can also escalate parts of the incident to another operator group if necessary.
Assess the impact and urgency clearly
Another thing to keep in mind is the impact and urgency of the incident. If it’s very urgent and the knowledge base doesn’t offer good enough guidance for some reason, perhaps it is better to let someone who is more familiar with the task handle it.
You may already be familiar with Incident Priority matrices from ITIL courses. If not, you can read my post that quickly explains Incident Prioritisation. Matrices are a great way of mapping out the impact and urgency of a call and making sure it’s assigned the right priority, and therefore help in understanding escalation.
The only thing you need to keep in mind is to avoid generic terms that can be misinterpreted, leading to the wrong prioritisation in your Service Desk software. Be specific. For impact, who is affected? The whole company, site, department, or one user? For urgency, are the impacted people able to work, partially able to work, or completely unable to work? Specific terms make it much clearer what you need to do when.
And lastly, I want to mention that if you do need to escalate an Incident, make sure to provide as much supporting documentation and detail as possible to ensure that the handover goes as smoothly as possible.
Get Incident Management right
Standard processes don’t have to be boring. We have several resources to help make your Incident Management more streamlined and inject something extra to it. Download our Incident Priority Matrix PDF, including a guide to all terms and how to improve your Incident Management Process.
Maintaining a Best Practice Incident Management process
We often overlook simple things when improving our services. For Best Practice Incident Management you should make sure you’ve done the fundamentals right.