An escalation matrix is only as good as its first trigger. The hard question isn’t who you call when everything is on fire. It’s who decides, at the first sign of smoke, that it’s a fire. On August 11, 2008, a couple of hours of Gmail trouble showed how much depends on that first judgment.
I described the structure in my escalation matrix post: levels, names, numbers, triggers. This one is about the escalation triggers themselves, which are the part teams skip. It’s tempting to think the top of the matrix is where the work is, the 2am call to the director. It isn’t. The top of the matrix only matters if the bottom of it fires on time.
What happened to Gmail on August 11, 2008?
Starting around 2pm Pacific, many people couldn’t get into Gmail. Google’s own apology, posted that day on the Gmail blog under the title We feel your pain, and we’re sorry, said that many people had trouble accessing Gmail for a couple of hours that afternoon. Press coverage at the time attributed the problem to the contacts system, which was preventing Gmail from loading properly.
I don’t have, and won’t make up, anything about how Google’s internal escalation worked that afternoon. What’s public is the outcome. The problem was identified, fixed and explained the same day, with a short, plain apology. From the outside, that’s what a working escalation looks like: a short time to acknowledge, a clear statement of what was wrong, and a human voice.
What I can do is use it as a case to test your own matrix against. If something like this hit your service at 2pm on a Monday, what happens in the first twenty minutes? Not in theory. On your floor, with the people you actually have on shift.
Why do most escalations start too late?
Because nobody was sure it counted. The first reports are always ambiguous. Three tickets say the same thing, an agent mentions it in chat, and the person who sees it thinks someone else has already raised it. Twenty minutes pass. By the time anybody senior knows, customers have been waiting for an hour and the first update is already late.
The fix is a trigger that is mechanical, not a judgment call. Write it as a rule: “three tickets with the same symptom inside fifteen minutes means open an incident.” Or: “any single report from a named customer of a total outage means call the manager.” The numbers matter less than the fact that they exist. A rule lets a junior agent escalate without worrying whether they’re overreacting.
That last part is the real point. Most late escalations aren’t caused by people who don’t care. They’re caused by people who care about looking foolish. A written trigger takes the embarrassment out of it. The agent isn’t raising an alarm on a hunch. They’re following the rule.
What triggers should a matrix include?
Keep it short. Four escalation triggers cover most of what a support team meets:
- Volume. Contacts about the same issue pass a set number in a set window. Choose your own numbers from your own normal volume.
- Severity. Total loss of the service, or loss of a function customers depend on, such as sign-in. If you already have severity levels in a tiered SLA matrix, reuse them here so agents learn one scale, not two.
- Who is affected. A named high-value customer, or a customer in a regulated setting, escalates one level higher regardless of volume.
- Time. Anything unresolved after a fixed period moves up automatically. Two hours is a reasonable first guess for a customer-facing issue. Move it once you’ve seen your own data.
Each trigger should name the next person to call, a backup, and the maximum time you’ll wait for them before moving on. An escalation path that waits indefinitely for one person who’s asleep isn’t a path. It’s a queue with one exit, and the exit is closed.
What do the first twenty minutes look like?
Here’s the sequence I’d write down. It’s a sketch for you to adapt, not a description of anyone’s real incident response.
- Minutes 0 to 5. The first person who sees the pattern posts it in one agreed place and says, in a sentence, what they see. They don’t diagnose.
- Minutes 5 to 10. The duty lead checks it against the triggers. If one is met, they open an incident and call the next level.
- Minutes 10 to 15. Someone is named as the voice to customers. They publish a holding statement: what we know, what we don’t, when the next update is.
- Minutes 15 to 20. The engineering or supplier contact is on the line, and the manager has decided whether senior management needs to know.
Notice that the manager appears late. The first fifteen minutes belong to the agents and the duty lead. That’s deliberate. It’s how you stop the manager from being the first and last point of escalation, which is the pattern I argued against in the curse of the berry.
Notice too that nobody is fixing anything yet. The first twenty minutes are about noticing, deciding and telling people. The fix runs in parallel, but the customer experience of an incident is set by those three steps long before the cause is known.
What should the first message to customers say?
It should be short and it should be early. A holding statement doesn’t need a cause. It needs three things: that you know, what customers can do, and when they’ll hear next. “We’re aware that some customers can’t sign in. We’re investigating. We’ll update this page by 3pm.” That’s enough.
The Gmail apology made the same point from the other end of the incident: how little it needed. A couple of sentences, an admission that people cared, and a promise to do better. No jargon, no attempt to explain it away. Customers don’t expect a service to be perfect. They expect to be treated as people who depend on it.
I covered the internal side of this in my post on internal and external SLAs: your internal target for acknowledging an incident should be much tighter than anything you’ve promised a customer. If your external promise is an update within an hour, your internal target should be fifteen minutes. That gap of 45 minutes is your margin for the trigger firing late, and it will.
Who should own the customer voice during an incident?
One named person, and it’s rarely the person fixing the problem. The engineer or supplier contact needs to concentrate on the cause. The voice to customers needs to concentrate on the message. When one person does both, the updates slow down, because every minute spent writing is a minute not fixing, and the fixing wins.
The same split later turned up in Google’s own site reliability book. Its chapter on managing incidents gives communication its own named role, separate from the people changing the system, and calls that person the public face of the response. Big engineering organisation or six-person help desk, the logic is the same: the fixer fixes, the voice talks.
The voice should have the authority to publish a holding statement without asking for sign-off. If every message has to be approved by three people, the first update arrives an hour late. Agree the approval rule in advance: holding statements are published by the duty lead, anything that admits fault or offers a remedy goes to the manager, and anything that mentions money or legal exposure goes to senior management.
How do you rehearse it?
With a thirty-minute drill once a quarter. Pick a plausible failure, such as sign-in being unavailable for a section of customers, and walk through it as if it were happening. Time each step. Who noticed first, how long before the duty lead was told, how long before a message could be published?
The first drill is usually embarrassing. A phone number is out of date, a backup contact has left the company, or nobody can find the holding-statement template. Those are exactly the things you want to discover on a quiet Tuesday. Fix them, update the matrix, and run it again next quarter. Four drills a year is two hours of the team’s time. One badly handled outage costs more than that before lunch.
What does a small team do differently?
The same thing with fewer names. If you have six agents and one manager, your matrix may have only three levels, and the same person may fill two roles. That’s fine, as long as you write it down and name a backup. The failure to avoid is a matrix whose second level and third level are the same overloaded person. When that’s the case, say so, and put it in front of whoever has the authority to add a name.
Whatever size you are, put the matrix where the first person who notices a problem can reach it in under a minute, preferably in the same chat channel or ticket tool they’re already looking at. A document only the manager has bookmarked won’t get used at 2pm on a Monday. The trigger you wrote is only useful if the person who needs it can find it fast.
What do you do after it’s over?
Write down what you saw, in the same hour, before you forget. Then hold a short review within a week with three questions: how long between the first symptom and the first escalation, how long between the first escalation and the first customer message, and which trigger should have fired earlier.
Those intervals tell you more than the incident’s root cause does. The root cause is usually somebody else’s. The delay in your own process is yours, and you can shorten it. If the first escalation took 35 minutes this time, the goal for next time isn’t zero. It’s twenty, and a trigger that would have got you there.
An escalation matrix isn’t a diagram on a wall. It’s a set of triggers people trust enough to use at 2pm on a Monday without asking permission.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
