The handoff fires correctly and the call still dies at the counter

The escalation logic works. The agent detects the thing it was told to detect — a complaint, a large order, a request nobody wrote a path for — and initiates the transfer, and the log records a clean handoff. Then the guest listens to a ringing tone for 40 seconds and hangs up. Nothing in your dashboard says so, because the dashboard is counting the trigger.

Almost every failed handoff in a restaurant is a destination failure, not a detection failure. The destination is a physical handset in a room that gets busier at exactly the moments escalation fires, and the transfer was designed as though it were an API call to a service that is always up. It is not. It is a call to a person who is currently carrying two plates.

Count outcomes, not triggers

Build one table and the argument ends. For every transfer over a fortnight, record what happened to it and which service period it fell in. Most telephony platforms expose enough call-leg detail to do this without new instrumentation; if yours does not, that is itself a finding.

Then split the table by hour. In almost every build, the second and third rows concentrate between 18:00 and 20:30, which is the same window in which escalation triggers fire most often. That correlation is not a coincidence and it is not bad luck — a busy room produces both the reasons to escalate and the absence of anyone to escalate to.

The five places a transfer goes to die

1. One handset, and it is in use. The destination is a single device that a person is already holding for a supplier call, a delivery rider or another guest. Confirming check: compare unanswered transfers against till activity or another handset's call log for the same minute.
2. No ring timeout. The bridge is told to ring and never told when to stop. The guest sits in a tone until they give up, and no fallback ever executes because none was defined.
3. Nothing was said to the person who answered. The staff member picks up an already-connected guest with no idea what was wanted or what has already been captured, so the whole conversation restarts and the guest concludes the agent was a waste of their time.
4. The number rings in the wrong room. Transfers land on the main line, which rings in the office, the back corridor or a stockroom — anywhere except the pass or the counter where somebody is standing.
5. Escalation fires more often than staff can absorb. Nothing is broken. The rate is simply higher than the number of interruptions a counter can take during a rush, so the queue at the destination is permanently full.

The fourth cause usually predates the agent. The transfer destination is often whatever internal extension already existed, chosen back when someone sat in the office all evening. Whether that device should be a fixed handset, a cordless one or a mobile carried on the floor is a fleet question, with the trade-offs set out in rolling twelve handhelds into three rooms.

A transfer is not an API call to a service that is always up. It is a call to a person who is currently carrying two plates.

The transfer contract, clause by clause

Write these five down before the number is forwarded. Each one has a value, an owner and a fallback, and a transfer path with no terminal state is not finished.

1. Destination by daypart. Name the device for each service period, not one number for the week. Lunch may ring the counter; dinner may ring a floor mobile; after close it may ring nothing at all, and that is a legitimate answer if the next clause covers it.
2. Ring timeout and second destination. About 15 seconds — roughly three rings — then move to a named second destination, then to the terminal path. Past 20 seconds of ringing the guest concludes the line is dead, and every second after that is spent losing them.
3. The announce leg. Before bridging, the agent speaks a short summary to whoever answered: what the guest wants, what has already been captured, and the callback number. Eight seconds is enough for all three. This is the single change that moves the 'answered with no context' row.
4. The terminal path: capture and call back. When no destination answers, the agent does not apologise and hang up. It takes the callback number, states a window in which someone will ring, and writes a task somewhere a manager will see it. A promise with no owner is worse than no promise.
5. The escalation cap. A rate at which the agent stops transferring and starts capturing instead, so that a rush cannot fill the destination queue faster than it drains.

Warm, cold, and the one a counter can actually staff

The textbook distinction is between a cold transfer, where the guest is dropped onto a ringing line, and a warm transfer, where a person briefs the receiving party first. Restaurants are told to prefer warm transfers and then cannot staff them, because one traditionally needs a third party with time to talk.

The agent removes that constraint. It can perform the announce leg itself: dial the destination, speak three facts to whoever answers, and only then bridge the guest. The staff member gets the briefing a warm transfer provides, at the price of a cold one, and can decline before the guest is ever connected. If they cannot take it, the guest never hears a failed connection — the agent moves to the second destination or the capture path with the guest still on a held line.

• Announce and bridge. The default for anything with an order attached, because the cost of restarting the order is high.
• Straight bridge with no announce. Acceptable only for a dedicated line answered by someone whose job is answering it — rare in a restaurant at 19:30.
• Decline path. The person who answers must be able to say no, and the agent must have somewhere to go when they do. Without a decline path, an announce leg is just a slower cold transfer.

The escalation budget a counter can absorb

Escalation is not free, and the constraint is not the phone system. Take a peak hour of 40 calls. At a 10% escalation rate, that is 4 transfers in the hour; at 25% it is 10. If a transferred call takes a staff member 2 minutes of undivided attention, 10 transfers is 20 minutes of one person's hour, arriving in unpredictable bursts while they are also serving a physical queue.

That arithmetic is why the escalation threshold is a staffing decision rather than a model setting. Where the line sits, and what it should be per field rather than per call, is worked out in setting the point at which the agent stops and asks.

The transfers that should never have been transfers

Before tuning the destination, cut the demand. A large share of restaurant escalations are guests asking where their food is, and that is a fulfilment-visibility gap surfacing on the phone line rather than a genuine need for a person — the read path that answers it is described in when most of the calls are people asking where their food is. Another share are orders the catalog cannot express, like a topping on one half of a pizza, which the agent correctly refuses to guess at; that shape problem is traced in half-and-half orders arriving as whole ones.

The remainder — complaints, allergies, unusual bookings, anything with money or safety attached — should escalate, and those are the ones the contract above exists to protect. An unanswered transfer on one of them is not a neutral outcome: it lands in the same bucket as a call nobody picked up, with the same four consequences set out in what happens to the calls nobody answered.

When scoping this with anyone, ask one question early: what happens when the transfer is not answered? A partner who has run a phone agent through a real dinner service will answer with a timeout, a second destination and a callback path. A partner who has not will say the transfer works. The rest of that conversation is covered in choosing an AI development partner, and the build itself — triggers, announce legs, capture paths and the logging that makes any of it measurable — is AI agents and automation work inside voice and phone ordering and the wider restaurant and food service stack.

• voice ordering
• escalation
• telephony
• diagnostics