Are you escalating the right cases?

A big thank you to Kathy DiSandro for inspiring this post.

Escalations are a fact of life for all complex-support organizations but they are resource-intensive, hence expensive, so it’s a good idea to make sure they are used judiciously. How do we know that there was a legitimate reason and benefit to escalate a particular situation? We explain, below.

First, let’s make sure we’re all on the same page: an escalation is a situation that requires special handling. It is not a mere elevation (to a higher support tier, or to the engineering team for diagnostic help or a fix) or a simple request (from a customer or a sales rep, to get management attention). A true escalation often includes an elevation, but most elevations are escalation-driven–and not all escalation requests result in a full-fledged escalation.

It’s easy to calculate an escalation ratio, which is the percentage of cases that escalate (using the restrictive definition above). It usually is a couple percentage points. If it’s more than that, something’s wrong. Keep reading regardless.

Even if the overall percentage is low, you may still be escalating the wrong cases. For instance, if you have a lot of cases that escalate within the first couple hours or days, it may be a sign that the team is not giving the normal troubleshooting process a chance to resolve the issue before switching to what we know is a resource-intensive process.

To determine whether you are escalating the right cases (and many other reasons), I’m a fan of conducting retrospectives, ideally on each and every escalation. If you need to deliver formal root-cause analyses to customers, you are already pretty close to conducting a retrospective: just make sure you take a good look at internal support processes, especially the initiation of the escalation. If you feel systematic retrospectives are too much work, focus on a small sample, say a week’s worth, or a month’s worth.

Here are some relevant questions to explore during the retrospective:

• Are early escalations connected to basic service quality issues? Is the team missing response targets or treating customers poorly in the first interactions? [Amp up the training.]
• Do certain customers routinely escalate right away? [Have a lovely conversation with them.]
• Are managers too quick to start formal escalations? What else can they do instead? [Train the managers.]
• Conversely, are managers too slow to escalate? What signs and criteria should suggest a formal intervention? [Ditto]
• Are there tool or process issues that encourage unneeded escalations? For instance, the team may escalate all issues that require engineering help because they have found that escalated issue linger. [Fix the process.]

What do you do to make sure you are escalating the right cases?

(We can help with the analysis, process improvements, and soft-skills training. Contact me for more details.)