Escalation paths and the manager
Give every exception class a named person, a time-to-human and a next hop, so no stuck item waits silently and the manager sees what to fix.
On this page
An automation that cannot finish an item has two choices: hand it to a person, or hold it. Every tool's default is to hold it quietly, a failed run in a log or a ticket tagged "needs review", and that default is how a customer waits three days for an answer nobody knew was owed. Escalation decides, for each kind of exception, who sees the item, by when, and who sees it next if they do not.
One channel for everything
The online retailer this module uses in place of the agency, from approval gates, takes 3,000 tickets a day in an 8-hour window and first sent every exception to one chat channel. That was about 75 messages a day, and by the second week nobody read it. One Thursday at 13:00 the payment provider began rejecting refund calls because a credential had expired. The failure was one more line among the day's 75. It was found at 11:00 on Friday, when customers started asking. At 30 refunds an hour, four hours on Thursday and two on Friday left 180 refunds unissued; assume a quarter of those customers wrote again, 45 extra tickets at 6 minutes and $3 each, before counting the ones who disputed the charge with their bank.
The channel held every fact needed and named nobody whose job it was to read it.
Three classes, three clocks
Definition of done and the exception list sorts exceptions into three classes: unknown input, ambiguous rule, external failure. Each gets a person and a time-to-human, the longest an item of that class may sit before a person is looking at it. The numbers come from what waiting costs. The agency's lead handler in the virtual employee frame already carries two of them: an unmatched lead seen within 15 minutes, and a page at once when the CRM is unreachable.
Unknown input: 15 minutes, to the support queue. A ticket in a language the desk does not support, an order number that does not exist, an attachment the parser cannot read. One customer is waiting and the desk promises a first reply within an hour. Handling an odd case takes up to 30 minutes, so noticing it gets 15, leaving slack. Assume 2% of tickets, 60 a day, 7.5 an hour; at 5 minutes each that is 5 hours a day for whoever is on the queue.
Ambiguous rule: 4 working hours, to the role owner. Two rules apply and disagree, or none decides: a return on day 31 for an item that arrived on day 3; a refund on an order paid half by gift card. A person on the queue cannot settle it either, because it is a policy question, so it goes to the owner, the manager in a role's six fields. Four hours keeps the answer inside the day, and the customer gets a holding reply that names the time. Assume 0.5% of tickets, 15 a day.
External failure: at once, by page, to the owner. The payment provider rejects calls, the order system times out, a credential expires. This is not one item but every item: at 6.25 tickets a minute, a 30-minute outage strands about 190 tickets and 15 refunds. The automation stops calling the failing system, a circuit breaker, holds the items with their clocks still running, and pages one person once, not once per failed item.
Every clock has a next hop
A person can miss a page, be at lunch, or not know the answer. So every class has a second clock and a second name. The last row is the gate from the first lesson of this module, whose expired state is an escalation like any other:
| Class | First person | Time to human | Next hop | When |
|---|---|---|---|---|
| Unknown input | whoever is on the support queue | 15 minutes | shift lead | unclaimed at 45 minutes |
| Ambiguous rule | role owner | 4 working hours | founder | still open at 17:00 |
| External failure | owner, paged | at once | backup on call | no acknowledgement in 10 minutes |
| Approval gate | reviewer on shift | 1 hour target | owner | expired at 4 hours |
Nothing waits silently
Every item that leaves the happy path gets a deadline when it is created, due_at = now + the clock for its class. A sweeper runs every minute, finds anything past due, and moves it one hop up: code, not someone's memory. The same holds where an automation waits on purpose, for an approval, a webhook that should arrive, or a retry with backoff. Each wait has a timeout, and a timeout is an escalation, never a silent drop. Guardrails as gates asks every gate for a named failure path; this is where those paths lead.
The number on the screen is the age of the oldest open item in each class, not the count. Three open unknown inputs is a normal afternoon unless one is two hours old, in which case a customer has already been failed. Alarm on age per class, the way monitoring alarms on the tail rather than the mean.
The manager reads the escalations
Escalations are the cheapest design feedback an automation produces, and the owner reads them weekly. Each class says something different:
- Unknown inputs rising means the input changed: a new partner's order format, a new language. Sixty a day becoming three hundred is not 300 exceptions but one drift, fixed once in the parser.
- Ambiguous rules repeating means the procedure has a hole. Each answer the owner gives becomes a rule, and the class should shrink week on week.
- External failures each get a short note: what failed, how long until the page was acknowledged, what the breaker held.
The ambiguous class is where the money is. Fifteen a day at 10 minutes is 2.5 hours. If the owner is the founder, at the course's assumed $100 an hour, that is $250 a day, about $5,500 over 22 working days. If three recurring cases make up 60% of them, three written rules cut the class to 6 a day. Handing the rest to a support lead at $30 an hour makes those 6 cost $30 a day, and the founder sees only what is still open at 17:00.
In practice
To the team: "Unknown inputs reach the support queue within 15 minutes, ambiguous rules reach the owner within 4 hours, and an external failure pages the owner at once. Anything past its clock moves up one hop by itself, and the dashboard shows the oldest open item in each class." To a vendor, ask what their tool does with a run that fails at 2 a.m., and who is told.
The mistake that costs money is an exception path that ends in a channel or a log with no name and no clock. It holds every fact and assigns none of them, and the first person to notice is the customer. The second is ending every path at the founder: at $100 an hour, a routine escalation should stop at someone whose hour costs less.
Check yourself
1. A partner starts sending orders in a new format, and unknown inputs go from 60 to 300 a day. Who should notice, and what do they decide?
300 × 5 minutes is 25 hours a day; the queue cannot absorb it and every item breaks its 15-minute clock. The owner should get one alarm on the class's rate, unknown inputs at twice normal, not 300 items. The decision is one parser change, and until it ships, a holding reply on that partner's orders naming when the fix lands.
2. The payment provider fails at 23:00, and the desk's window is 09:00 to 17:00. Page the owner now or at 08:30?
The clock follows cost, and cost needs work flowing. If refunds only run inside the window, nothing is stranded overnight, so page at 08:30, with time to fix or hold before 09:00. If refunds approved late in the day are issued overnight, each hour strands some of them, and the page goes now.
3. The desk relaxes its first-reply promise from 1 hour to 4. Does the 15-minute clock on unknown inputs stay?
It can lengthen. With 30 minutes of handling inside a 4-hour promise, noticing can take up to 2 hours, so the queue can be worked in sweeps every 2 hours with the shift lead as the next hop at 3. The clock still exists; only its number changed, because the cost of waiting did.