Escalation Matrix: Who Gets Called at 2am

An escalation matrix decides, before anything breaks, who gets told about an unresolved problem and exactly when. Mine has two parts: a clock that fires a new escalation level at set intervals for each priority, and a ladder that says which people in which departments get notified at each level. I’ve used this 2-stage internal escalation matrix with great success, and the timings are below. The point is simple. When your front line can’t fix the problem, you get it to the people who can, in a timely manner, without anybody having to decide in the moment whether it’s bad enough to wake someone up. That decision was made months ago, in daylight, with a clear head.

Picture it. It’s 2am and you’ve got a Tier 1 customer with no telephone service, hard down. That’s the top tier of the tiered SLA matrix, and it means your definition of customer tiers was settled before any of this started. The outage is costing them money every hour it runs. Your engineer has taken the call and started working the issue, which is exactly what the SLA and the Erlang C staffing maths were there to guarantee: someone qualified picked up. Great. Now, what happens if they can’t fix it? This company is paying you a lot of money for the service. That IS why they’re Tier 1, after all. So you need all the right people available and working their problem as quickly as possible, and “all the right people” can’t be whoever your engineer happens to have a mobile number for.

When does each escalation level get notified?

This is the clock. Every row is an escalation level, every column is a priority, and each cell says how long after the ticket was created that level fires.

All times are measured from when the ticket was created. Look at how it’s built and you’ll see there’s really only one number per priority. Critical steps every hour, High every 2 hours, Medium every 4, Low every 24. Each level simply fires at the next multiple, so a Critical ticket reaches level 5 at 5 hours and a Low ticket takes 120 hours, a full five days, to get there. That makes the whole thing easy to explain and even easier to automate. Your ticketing system only needs the priority and the creation time to know who should be hearing about it right now.

Level 5 is the one people forget to design. It doesn’t stop. Once a Critical ticket has been open 5 hours, the full list gets an update every hour until it’s fixed, because by then the problem has outlived every normal response and the most senior people in the building need to keep seeing it. The groups also accumulate as you go up. Level 3 notifies escalation groups 1 through 3, not group 3 alone. Nobody drops off the thread just because someone more senior joined it. Line it up against the 4-hour Tier 1 resolution target and the timing is no accident: a Critical ticket reaches level 4 at hour 4, so the VPs hear about it the moment that promise is broken, not the next morning.

Who’s on the escalation ladder?

The clock tells you when. The ladder tells you who. Each level of the escalation matrix maps to a set of people across five groups: Support, Sales, Operations, Product Management and Engineering.

Level 1 is the working layer: the support lead or supervisor, the Ops/NOC lead or supervisor, and defect control in product management. Level 2 brings in the support manager, the sales rep, the Ops/NOC manager and an engineering rep. Level 3 is the support director, sales manager, ops director, product manager and engineering manager. At level 4 it’s the VP of support and customer service, the sales director, the VP of ops and the director of engineering. Level 5 is the VP of sales and the VP of engineering. Not every group has a name at every level. That’s deliberate. Engineering doesn’t need a level 1 contact because the level 1 people are the ones already working it.

Sales is on the ladder for a reason, and it’s the group I see left off most often. A sales rep at level 2 means the account owner knows their biggest customer is hard down before that customer rings them to ask what’s going on. That’s a much better conversation than the alternative. The same logic runs all the way up. By the time a VP gets the notification, their counterpart in every other affected group has had it too, so nobody’s first move is a panicked message asking who else knows. They already know who else knows. It’s on the matrix.

Your escalation matrix has to fit your organization

This structure only applies to larger companies, where the problem and the responsible party could be in a variety of different locations. If your escalation only ever goes to one group, it’s fairly easy to remove the additional escalation group step. You keep the clock, drop the ladder, and let each level mean one more person in the same team. Don’t build a five-department matrix for a small support team with one engineering group down the hall. It’ll look thorough on paper and nobody will maintain it.

The groups also vary based on the type of organization. Ops/NOC made sense in a telco environment, where the network was the product and a NOC was watching it around the clock. It doesn’t necessarily apply in a manufacturing one, where the equivalent might be plant operations or field service. Swap the columns for whoever actually owns the fix in your business. The shape of the matrix stays the same. The names in it don’t.

Two more things before you publish it. First, this is an internal document. You’ll need a separate matrix for customers, and it shouldn’t be this one with the job titles blanked out, because the customer needs to know what to expect from you and when, not your org chart. Second, an escalation matrix only works if the names in it are current. People change roles, go on leave and leave the company. Review it on a schedule and test it, because the night you find out level 3 points at someone who left in the spring is the same night you needed level 3. An escalation matrix nobody has tested is a guess with a table around it.

HDI splits escalation into two kinds: functional escalation, which moves an incident sideways to specialists, and hierarchical escalation, which moves it up to management. This matrix is the hierarchical kind. It doesn’t replace your engineer pulling in the right specialist at 2:15am. It makes sure that, if the specialist can’t fix it either, the people with the authority to throw more at the problem know about it on a schedule rather than by accident.

Frequently Asked Questions

What is an escalation matrix?
An escalation matrix is a pre-agreed table that says who gets notified about an unresolved ticket and when. This one combines a timing table, where each priority fires a new level at a fixed interval, with a list of the people in each department who are notified at each of five levels.

How fast should a critical incident be escalated?
In this matrix a Critical ticket reaches level 1 one hour after it’s created and climbs one level every hour after that, reaching level 5 at 5 hours. From then on, everyone on the list gets an update every hour until it’s resolved.

What’s the difference between functional and hierarchical escalation?
Functional escalation moves an incident to someone with the specialist skills or access to fix it. Hierarchical escalation notifies management so they can add authority or resources. A time-based escalation matrix like this one handles the hierarchical side.

Do small support teams need an escalation matrix?
Yes, but a simpler one. If every escalation goes to the same group, keep the timing table and drop the multi-department ladder, so each level just adds the next more senior person in that team.

Hutch Morzaria

Hutch Morzaria is a CX and Support Leadership professional with 19 years of experience building and leading support organizations across SaaS, Fintech, and enterprise technology. He has held Director-level roles at Q4 Inc, AudienceView, Johnson Controls, and others, and holds ITIL Expert certification across V3 and V4.