Escalation: What It Means, How to Build a Path, and the Matrix to Copy

Escalation is what happens when a support ticket stops being solvable by the person holding it and has to move, either sideways to somebody who knows the system deeper, or upward to somebody carrying the authority to spend money and make promises on the company's behalf. Two motions, one word covering the both of them. This page gives you the plain definition, a filled-in escalation matrix you can copy on to your own wall, three worked examples running from the first line to the third, and the sum for working out your own escalation rate along with the numbers that count as normal. No framework needed for any of it.

Nobody builds any of this in the calm, mind you. Picture a support lead at a company selling barcode scanners and the warehouse software that runs them, forty staff, a support desk of four. One Tuesday morning a customer wrote in at 06:40 to say that their entire night shift had been unable to scan anything at all since about two in the morning, and the goods were sitting on the dock, and the lorries were waiting. The agent who picked it up did every reasonable thing. He replied inside twenty minutes, asked good questions, tried the things that usually work. Then he sat there for close to three hours with the problem plainly above his head and no clear notion of whose desk it belonged on next, and this is the honest shape of a support team with no escalation path, four capable people and not one of them sure who to hand it to. The engineering lead only heard about it at half nine. From the founder, mind you, who had heard about it from the customer over the phone.

Escalation meaning, in plain words

The word gets used loosely, so it helps to split it the way ITIL splits it, since the split is genuinely useful and not just vocabulary. Functional escalation is the sideways one, moving a ticket to greater expertise, the agent handing off to the person who has read the database schema and knows what the sync job does at two in the morning. Hierarchical escalation goes upward instead. That one moves a ticket to greater authority, because somebody now needs to authorise an out-of-hours engineer or a refund or a phone call to a very cross operations director. A single bad Tuesday will usually want the both of them at once, funnily enough, which is why teams muddle the two together and end up escalating everything to their manager, who then has to go and find the engineer anyway. Long way round.

Worth saying out loud as well, since it gets missed constantly. An escalation is not a failure, and it is not a complaint about the agent who raised it. The system is working as meant. A first-line agent who escalates a genuine database problem after fifteen minutes has done the job properly, and the one who wrestles the very same problem alone until lunchtime out of pride has not, whatever his ticket count says at the end of the week. Teams that quietly treat escalations as an admission of weakness end up with slow tickets and agents who learned to stay quiet, and that culture is much harder to repair afterwards than any process is to write. Fair is fair, the pride is understandable enough.

What an escalation path actually is

An escalation path is the answer to one question, asked at the worst possible moment. This ticket cannot stay here, so where does it go, and by when. The whole of it comes down to naming the levels, naming a person or a rota on each level, and fixing a clock against each hop so that nothing sits waiting on somebody's good judgement at seven in the morning.

Most desks land on three levels and there is no prize for inventing a fourth. Level 1 is the front line taking everything that arrives, working from documented answers, and resolving the large majority of it, password resets and how-do-I questions and the settings people cannot find. Then comes level 2, the specialist tier, agents or engineers with system access, the ones who read logs and reproduce bugs and know which configuration causes that particular error. Level 3 gets it when the product its self is broken. So development, plus sometimes the vendor behind whatever component fell over. Sitting across the whole of it, on a separate track, is the management escalation, and that track exists for the commercial side of a bad incident rather than the technical side, the promises and the money and the calls that only a senior person should be making.

Our support lead wrote her first version of this on a Wednesday, the day after, on a whiteboard, and it took about forty minutes. The forty minutes were not the hard part. Getting the engineering lead to agree, in writing, that a severity 1 could reach him directly at any hour without going through the founder first, that conversation took a fortnight and it was the one that mattered. To be honest with you, most of the work in escalation management is that conversation.

The escalation matrix, filled in

Here is the artifact almost nobody publishes. An escalation matrix crosses how badly the thing is broken against how much of the business it is hurting, and every cell tells you who owns it, how fast the first response goes out, and when it climbs to the next level on its own. Copy this one. Change the names to your own people, then argue about the timings with whoever owns the money.

Read the last two columns before the first two, they are the columns that actually do the work. A matrix naming owners but leaving out the clock is decoration, and this is precisely where most published versions of this table stop. The escalate-after timer is what stops a ticket sitting politely in a queue while everybody assumes somebody else has got it, which is the exact thing that went and happened on the Tuesday with the lorries.

One more piece of it, and it is the piece teams forget. Severity is not the customer's to set. Every customer writes urgent, every one of them, and fair is fair, from where they are sitting it genuinely is urgent. Impact decides the row instead. So the agent sets the severity by asking how many users are stopped and whether there is any way around it, and there should be a named person allowed to overrule that judgement in either direction without anybody taking offence.

Three tickets, walked from level one to level three

Take an ordinary one first. A warehouse supervisor writes in on a Thursday morning saying she cannot print labels from the packing station. Level 1 takes it, checks the printer mapping against the documented steps, finds the workstation lost its driver after an update, walks her through the reinstall over email and the whole of it is finished in fifty minutes. No escalation anywhere. Around eight in ten of everything arriving ought to end this way, otherwise your first line is either under-trained or under-documented, one or the other.

Now a harder one, and this is the functional escalation doing its job. A customer reports that stock counts in the app are twenty or thirty units off from what their team counted on the floor, at three sites, since roughly the weekend. Level 1 verifies it is real, gathers the specifics, confirms the workaround of counting manually is horrible but survivable, and tags it S2 with a note that three sites are affected. Level 2 picks it up inside the business hour, goes and reads the sync logs, and finds that a job which reconciles counts overnight has been failing silently since a schema change on the Friday. Product defect, then. So it climbs to Level 3 with the log extracts attached, and development ships a fix on the Tuesday following. Total elapsed time about four days, and the customer heard something from a human on every single one of them, which is genuinely the part they remember afterwards.

The Tuesday incident is the third one, and it is the one the whole path was written for. Scanners dead at every station from two in the morning, nothing scanning, lorries waiting on the dock. Under the matrix above that is an S1 the moment the agent reads the words no workaround, so it does not sit with him at all, it goes straight to the level 2 on-call inside fifteen minutes, and if there is no diagnosis by the half hour it reaches the engineering lead and the head of support at once, at whatever hour it happens to be. Both motions running together there. The sideways one for the expertise, the upward one because somebody has to go and decide whether a customer this size gets an engineer woken up. Which is the whole of the argument for writing the thing down beforehand. On the actual Tuesday it took three hours and a founder to achieve what a written path achieves in thirty minutes, and not one person involved had done anything wrong.

How to calculate your escalation rate

Our support lead ran the numbers at the end of that quarter and got 14%. She had closed 1,240 tickets across the three months and 174 of them had left the first line at some point, so you count the tickets that got escalated, divide by everything you resolved in the period, and multiply by 100, which is the whole sum and it needs no tooling beyond whatever your desk already records. Fourteen is a little high. Under about 10% is the comfortable place to be sitting for a software support desk, and above 20% is your first line telling you something, usually that they lack either the documentation or the permissions to finish what they are perfectly capable of finishing on their own selves.

Cut the number by reason before you go acting on it, that is the part worth insisting on. Hers came apart into three uneven piles once she read them properly. Some had escalated because the agent genuinely lacked access to a tool, and that pile was fixed inside a week by an admin changing some permissions. No training needed at all. A second pile was one recurring bug, all of it, thirty odd tickets pointing at the very same defect, which made it an engineering priority rather than a support problem. The last pile was honest knowledge gaps, and those got written up into the internal knowledge base one at a time over the following month. By the next quarter the rate was 9%. Hardly any of that improvement came from anybody trying harder, mind you.

Two neighbours are worth watching beside it, since escalation rate on its own can be gamed as easily as any other number. Falling rate, climbing reopen rate, the two of them moving together like that means your first line has quietly started closing things it has not actually fixed. No two ways about it. And time-to-escalate deserves its own look now and then, the gap between a ticket arriving and somebody making the call to move it, because a desk with a fine looking rate can still be leaving people to struggle alone for six hours before they ask. And those six hours were spent out of the customer's day rather than out of yours.

Customer escalations, which are a different animal

Everything above is about a ticket climbing a technical ladder. The other sort of escalation is a person deciding they have had enough, and it arrives as an email in capitals, or a message that mentions the contract renewal date for no innocent reason, or a customer asking to speak to whoever your manager might be. Handle those on the commercial row of the matrix rather than the technical rows, because the underlying problem is rarely technical by that stage, and often the original fault has been sorted already while the annoyance about the whole of it has not.

The moves that work here are unglamorous and they are the very same three every time, more or less. Acknowledge inside the hour, and acknowledge the feeling out loud rather than only the fault, since a person who has written in capitals is telling you something about the last fortnight and not just about today. Get one named owner on it, senior, and let that person write every reply from then on, no rota, no shared signature, on account of a cross customer counting how many different names have replied without fixing anything. Then say what you are doing and by when, in dates. Where you cannot commit to a date, say so plainly instead of going vague, since the vagueness is what most people actually escalate about in the end. Follow up once after it closes, a week later, when nothing is on fire and there is nothing to sell. That last one costs about four minutes and our support lead reckons it went and saved two accounts over the year.

Who sits on the escalation team

The phrase makes it sound like a standing department with a room of its own. In a company of forty it is four names on a page and a rota, plainly said. What matters is that each name has one job written next to it. Somebody owns the technical diagnosis. Somebody owns the customer communication, and it should not be the very same person who is elbow deep in the logs, since one of those two jobs always gets dropped when a person tries to hold the both of them. Commercial decisions want an owner too, the credits and the goodwill and the promises. And somebody, on the big ones, owns writing down what happened afterwards.

That last role earns its place quietly. A short write-up after every S1 and every commercial escalation, half a page, what broke and what was done and what should change, and it goes to one and all rather than into a private folder. Our support lead's file of these ran to eleven entries by the end of the year. Reading the whole of it in one sitting told her more about the product than any dashboard had, on account of four of the eleven being the very same integration failing in four different disguises.

Escalation management without buying a process

You do not need a framework consultant and you do not need a fortnight. Write down three levels and a name against each. Agree the severity definitions with whoever pays for the out-of-hours calls, then go and put the matrix somewhere the agents can see it at four in the afternoon without asking anyone. That is genuinely the whole of the setup, plainly said, and everything after it is upkeep.

The tooling part is smaller than it gets made to sound as well. What you want from an IT ticketing system is that severity is a field on the ticket rather than a word buried in an email thread, that a rule can go and move an unattended S1 to the on-call queue by its self after fifteen minutes, that the reassignment carries the whole history along so the level 2 person is not asking the customer to explain it all again, and that the timestamps are kept properly so your escalation rate is a report rather than an afternoon of counting. Over here at Maxdesk all four of those sit on the free workspace, along with unlimited agents, the SLA timers, the automations, roles and permissions and the audit trail, and no plan of ours charges by the agent, so putting the whole escalation team into the tool costs the same as putting one person in it.

There is a trade and you should hear it from us rather than find it later. The free workspace shows supporting ads, it keeps three months of history, and the number of automations you can have running at once is capped, so a desk wanting a year of incident history for its post-incident reading will want a paid plan. Email is also the only channel we have shipped, and if your escalations arrive by phone at two in the morning, that part of the path still lives with your on-call rota rather than with us. For a team whose bad Tuesdays arrive by email, which is most teams, the whole of what this article describes can be running by Friday.

Questions people ask about escalation