Escalation matrix: who gets involved, when, and with what authority

An escalation matrix maps severity to people: at this level of problem, these roles get involved, within this time, with this authority to act. It is a small table that removes a specific failure — the hour spent wondering whether a situation warrants interrupting somebody, while the situation gets worse.

The reason it works is that the judgement is made when nobody is under pressure. During an incident, the person closest to it is the worst-placed to decide whether it is serious, because they are busy and they would rather not be the one who overreacted.

Building the table

1. Define severity levels in observable terms, not adjectives. Not critical but service unavailable to all customers, or one customer blocked with no workaround.
2. For each level, name the roles — not the individuals — who are involved, so the table survives people leaving.
3. Set a time-to-involve per level: immediately, within an hour, next working day.
4. State the authority each level carries: who can approve overtime, take a system offline, issue a refund, or talk to the press.
5. Add the contact route per level and the fallback. A person who cannot be reached needs a documented second choice, or the matrix stops at their name.
6. Say what happens when a level does not respond within its time — automatic escalation to the next, without anyone asking permission.

The most valuable line in the matrix is the one giving explicit permission to escalate. Junior staff routinely delay because escalating feels like admitting they could not handle it, and the cost of that hesitation is far higher than the cost of an unnecessary call. Writing escalating early is always correct — nobody will be criticised for it into the document, and saying it out loud once, is the whole intervention.

Functional and hierarchical

Two directions worth distinguishing. Functional escalation moves a problem sideways to somebody with different skills — this needs the person who knows the payment integration. Hierarchical escalation moves it upward to somebody with more authority — this needs a decision about spending money or telling a customer. They are different needs and the matrix should show both, because a technical problem routed upward gets a manager who cannot fix it, and a commercial decision routed sideways gets an engineer who cannot make it.

Keeping it honest

• Review after every significant incident. The matrix is a hypothesis and incidents test it.
• Check contact details quarterly. Phone numbers and names decay silently, and an incident is the wrong time to discover it.
• Keep it short. One page, or people will not read it under pressure — the same argument as in incident response plan.
• Keep an offline copy. If the escalation matrix lives only in the system that is down, it is unavailable exactly when needed.
• Do not create levels nobody uses. Three severities that mean something beat five that get argued about.

Where it lives

Ettex Chat is where escalations actually happen in most small teams — a channel per severity, or a named group that the matrix points at — and Ettex Records holds the matrix itself with owners and review dates. The commitments it exists to protect are in service level agreement, and the incident sequence around it in incident response plan.

The boundary: there is no paging, no on-call rota automation, no alert routing. Those are on-call platform features and a business that needs them should buy one. What is described here is the decision the tool would be executing — and the decision is the part that is usually missing.