An escalation directory is the list of who receives each kind of case that an agent or a reviewer escalates. For each type, such as suspected fraud, a vulnerable customer or a legal threat, it names the person or team, their authority, their cover and how quickly they must respond. It answers one question: escalate to whom?
Why does it matter?
An agent can be very good at recognising that a case is beyond it and still fail the customer if the case lands nowhere. Agents escalate by design: a well-built agent holds or hands off anything outside its bounds. If the target of that hand-off is vague ("the compliance team", "a manager"), escalated cases sit in shared inboxes while everyone assumes someone else has them.
The directory makes escalation concrete. It also gives the agent owner something to test against. If the brief says "escalate suspected fraud to the fraud desk", the directory must say who on the fraud desk, during which hours, and who covers outside them.
What goes in an escalation directory?
| Field | What it records |
|---|---|
| Escalation type | The trigger, described the same way the agent's brief describes it |
| Receiving role | The team or role that owns this type of case |
| Named people | Primary and backup, with their current standing |
| Authority | What they may decide, and the limit of that authority |
| Response target | How quickly a case must be picked up |
| Out-of-hours route | Who receives it outside normal hours |
| Onward escalation | Where it goes if the receiver cannot decide |
The directory is reviewed whenever people move, and every escalation is filed in the record, so you can check it was used.
An example
Take a hypothetical telecoms operator's support team. Its agent answers billing questions and holds several case types it must not handle. The directory says: suspected account takeover goes to the fraud desk, named analysts on each shift; a customer who mentions a bereavement goes to the specialist care team; a threat of legal action goes to the complaints lead; a data access request goes to the privacy team. When a customer writes that they never ordered a new phone, the agent holds the case and routes it to the fraud analyst on shift. The analyst picks it up within the target time. The structure behind those routes is often built as an escalation matrix for customer support agents.
How is it different from an escalation path?
An escalation path is the route a case follows: from the agent, to a first reviewer, to a senior decision-maker, and so on, with the conditions for moving up each step. The directory is the reference that puts names to each step. A path describes the shape; a directory supplies the addresses. You need both. A path with no directory sends cases into the void, and a directory with no path leaves people guessing which name to use.
It also differs from escalation rate, which measures how often an agent escalates rather than where escalations go.
How do you keep it accurate?
Test it. Run sample cases through the agent and check each one arrives with the named person, a method set out in how to test an AI agent's escalation behaviour. Check monthly that every named person still holds the role and their standing is current. The guide to AI agent skills by role helps identify who should appear in it.
Where the Academy fits
The Operator track at Pryme Intelligence Academy includes a module on when something goes wrong, which covers routing and escalation, and a module on running the rhythm, which covers the daily and weekly checks that keep queues and routes in order. Team leads who maintain the directory are its intended audience.
Questions people ask
Who owns the escalation directory?
Usually the operations manager or team lead for the agent's queue, with each receiving team confirming its own entries. One owner keeps it consistent.
Should the agent read the directory directly?
It can, as one of its sources, so its hand-offs reach the right queue. People should still own and update it; the agent only reads it.