Start free trial

By Yair Knijn · May 14, 2025

The escalation path that lives in one senior engineer's head, until the night they're on a plane

Every desk has a Priya. She has been here six years, she knows which vendor account manager actually answers his phone, she knows the database lead carries a second pager, and she knows that the payments incident from two summers ago needs the CTO looped in before it hits an hour. The head of customer success calls escalation "solid" because for six years it has been. What they are actually describing is one person's memory, not a policy.

The failure mode is specific and it always arrives the same way. Priya is on a flight to a conference, the wifi is down, a P1 opens at 02:14, and the ticket sits in a shared queue with nobody named as the next responder. The clock that the SLA promised the customer is running. Nobody on shift knows the second pager exists.

Functional vs hierarchical escalation, and which one your desk skips

ITIL splits escalation into two kinds. Functional (horizontal) escalation moves a ticket sideways to someone with the right skill or access. Hierarchical (vertical) escalation moves it up to someone with the authority to spend money, wake a vendor, or accept a tradeoff. Most desks have a rough handle on functional escalation because tier 1 knows tier 2 by name. The hierarchical path is the one that lives in Priya's head, because it gets used a few times a year and never gets written down.

That is exactly the path you need at 2am, and exactly the one nobody can reconstruct from a wiki.

The on-call gap: why escalation by Slack DM fails at 2am

Escalation by direct message has no acknowledgement, no timeout, and no fallback. You DM the person you think is on call, you go back to the incident, and you assume the message landed. If their phone is on do-not-disturb, the message is read by no one until morning. There is no rule that says "if not acknowledged in five minutes, page the backup, then page the manager."

Australia's Optus saw a sharp version of this in September 2025. A network fault ran for around thirteen hours and roughly 600 emergency calls to Triple Zero failed before the fault was properly addressed; the public review centered on how long it took to detect and route the problem to the right people. Different stakes than a SaaS desk, same structural hole: the gap between "something is wrong" and "the right person is working it" was filled by chance, not by a configured rule.

Automatic escalation triggers tied to the SLA clock, not a human

The fix is to bind escalation to the clock the customer was promised, not to whoever happens to be awake. The trigger should be a percentage of the resolution target, not a vibe. A workable default:

None of that depends on Priya being reachable. The clock fires the same way at 02:14 as it does at noon, and the audit trail records who got paged and when.

Documenting the escalation matrix so it survives a resignation

An escalation matrix that only exists as muscle memory leaves with the person who has it. Write down, per priority and per service, who is functional next, who is hierarchical next, the timeout before each hop, and the out-of-hours number that actually rings. Then test it by having someone who is not Priya run a P1 drill while she is explicitly unavailable. If the drill stalls, you found the single point of failure before a real customer did.

OpsDesk treats the escalation matrix as configuration, not folklore. Each customer workspace defines response and resolution clocks per priority, automatic escalation hops tied to those clocks, and an audit trail that shows a director exactly where the time went and who was paged at each hop. The point is that the path keeps working on the night your most reliable engineer is on a plane. You can see how the SLA clocks and escalation rules fit together on the features page.