The short version
- Sort a month of escalations and most were not decisions. They were unanswered questions that got old enough to look like problems.
- An escalation is what a question becomes after 48 hours of silence. The severity is a function of the delay, not of the content.
- Classify every escalation for a month: needed authority, needed information, or needed someone to notice. The middle category is usually largest.
- Reducing escalations is mostly reducing latency, not improving triage.
Escalations are treated as a triage problem: better routing, clearer severity levels, faster response. Those help at the margin. What changes the volume is noticing that most escalations did not start as escalations.
"I get escalated things a brief would have answered."
What an escalation actually is
Trace one backwards. On Monday someone had a question. They asked the person most likely to know, who was busy or asleep. On Tuesday they asked again. On Wednesday the thing they were waiting on became late, so they raised it with a manager, and it arrived in your inbox marked as blocked.
At that point it looks like an escalation and it is still a question. What changed was not the content but the age, and the age converted a two-minute answer into a piece of work for two senior people plus a status update for whoever was affected.
This is why escalation volume tends to be a measure of your organisation's answer latency rather than of its problem rate.
Classify a month of them
Do this before changing any process. Take every escalation that reached you in the last month and put each into one of three categories.
| Category | Test | Right response |
|---|---|---|
| Needed authority | Only you could have decided it | Correct escalation. Consider delegating the class |
| Needed information | The answer already existed somewhere | Should never have reached you |
| Needed someone to notice | It was ignored until it was late | A response-time problem, not an escalation |
Most leaders running this exercise for the first time find the middle row is the largest, often by a wide margin, and that the first row is smaller than they assumed. That inversion is the finding worth acting on.
Latency is the cause
Two features of a distributed organisation make latency the dominant factor.
Time zones add a night to every hop. A question that takes three attempts to reach the right person has taken three days, and three days is long enough for anything time-sensitive to become an escalation.
And routing is guesswork. Without published ownership, people ask whoever they think might know, which adds hops. Each hop is a chance for the question to age into something else, which is why ownership clarity reduces escalations without touching the escalation process at all.
Reducing the largest category
For the information category, the intervention is to make the answer available at the moment of the question rather than after two failed attempts.
With StandIn, each person confirms a ninety-second brief at the end of their day, mostly pre-drafted from the work they already did: current state, decisions and reasoning, blockers, next actions. While they are off, their StandIn answers questions from that brief in their words, with a source under every answer, and it never guesses. The person with the Monday question gets their answer on Monday, from the record, without the hops.
The effect on a leader's week is direct. The escalations that still arrive are the ones in the first row, which genuinely needed authority, and those are the ones worth your attention. See StandIn for leadership teams.
The escalations you want to keep
Fewer escalations is not the goal, and an organisation with none has usually taught people not to raise things. Three categories are worth protecting explicitly.
Anything where someone believes a commitment will be missed, raised as early as possible. Anything involving a customer's trust. And anything where a person has tried the normal route twice and it did not work, because that is information about your routing rather than about them.
Say all three out loud, because a campaign to reduce escalations reliably suppresses the useful ones first.
Common Questions
How do you reduce escalations?
Classify a month of them into needed-authority, needed-information, and needed-attention. The information category is usually the largest and is removed by reducing answer latency rather than by improving the escalation process.
Why do so many escalations turn out to be simple questions?
Because an unanswered question ages. After two or three days the thing it was blocking becomes late, and lateness is what makes people escalate. The content never changed; the delay did.
Is a formal escalation process worth having?
Yes, and keep it small: one route, a clear definition of what qualifies, and a named owner. What you should not do is treat the process as the lever for reducing volume, because volume is driven by latency upstream of it.
How do we avoid suppressing useful escalations?
Name the categories you want raised early, especially missed commitments and anything affecting customer trust, and respond visibly when someone raises one. People calibrate on what happened to the last person who escalated.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.