Escalation & Warm Transfer

Escalate before the caller asks — over-persistence is the failure mode.

An agent trained to complete tasks will keep trying past the point where a human should have taken over, because "give up" looks like failure to a model optimising for resolution. In voice this is worse than in chat: the caller cannot skim ahead or open a second tab, so every wasted turn is real seconds of a person's patience. The escalation decision is a product decision, not an afterthought, and it should trigger on more than the explicit ask:

• Low task confidence. The agent is unsure it can resolve the intent — hand off while the caller is still calm, not after three failed attempts.
• No progress across turns. Two or three turns without moving the task forward is a loop; count it and break out. This is the voice version of the runaway loop from voice-failure-modes.
• Detected frustration. Rising sentiment signals, interruptions, repeated rephrasing — treat these as an escalation trigger, not just telemetry.
• Out-of-scope or high-stakes intent. Anything policy reserves for a human (disputes, cancellations above a threshold, vulnerable-caller signals) escalates on sight, per the least-privilege line in human-in-the-loop.
• The explicit request. When the caller asks for a person, the argument is over. Never make a caller ask twice, and never route the second ask back into the same failed flow.

Pick the transfer shape deliberately; warm is the default for a reason.

There are three shapes, and the difference between them is entirely about what the caller experiences at the seam:

• Cold transfer. The agent drops the caller onto a human or a queue with nothing attached. Fast to build, and the reason customers hate phone trees — the human starts from zero and the caller pays for it. Reserve it for genuine last resorts (the context system is down and the alternative is a dropped call).
• Warm transfer. The caller waits briefly while the human receives the context — a screen-pop, a whispered brief, or both — then joins already oriented. This is the default for anything that matters, because it is the only shape that spends the caller's wait buying them something.
• Supervised handoff. The agent stays on the line as a silent participant, available to fetch data or resume if the human releases the call back. Useful for complex accounts and for training the agent on real escalations, at the cost of a live seat per call.

The seam is where warm transfers are won or lost: what the caller hears while they wait (branded hold, or a spoken "connecting you to Maria, who can see everything we've discussed"), how long that wait is allowed to run, and whether the caller can barge in during it. Barge-in handling here follows the same rules as mid-turn interruption in turn-taking-and-barge-in — a caller who speaks during the hold must not be ignored.

The context packet is the actual deliverable.

Everything else is plumbing; this is the product. The human must receive, and have read, a compact packet before they greet the caller — otherwise they improvise, and the caller repeats themselves. The packet carries:

• Verified identity and auth level. Whatever caller-authentication already established travels with the transfer. Making an authenticated caller re-verify to the human is the most infuriating and least excusable repeat of all.
• The intent, stated in the caller's own words. Quote the request; do not paraphrase it into a category. A human who reads "wants to dispute the $240 charge from the 14th" starts three steps ahead of one who reads "billing issue."
• Actions already taken and their side effects. What the agent did, what it changed, and critically any holds, pending writes, or partial transactions the human must not re-run — the side-effect ledger from voice-tooling-and-state, handed across the seam.
• The reason for escalation. "Caller frustrated after two failed refund attempts" tells the human how to open; "escalation" tells them nothing.

Timing is part of the spec: the packet must land and be readable before the human's first word. A screen-pop that arrives after "hello" has already failed, because the human has committed to an opening line built on nothing.

Give the transfer its own latency budget and a "no human" branch.

The handoff is not instantaneous, and its latency is invisible in the agent's own latency-budget because it lives in the telephony layer: finding an available, skilled human, executing the SIP/PSTN transfer, delivering the brief. Budget it explicitly, because dead air during a transfer reads as a dropped call:

• Fill the wait, and bound it. Tell the caller what is happening and give the wait a ceiling. When the ceiling trips, do not leave them in limbo.
• Design the "no human available" branch first, not last. Queue with an honest wait estimate, offer a scheduled callback that preserves the context packet, or fall back to a ticket that contains the same packet — anything but stranding the caller in a transfer that never completes. The most damaging outcome on this whole page is the caller who waited and got nobody.
• Make the transfer idempotent. A retried or double-fired transfer must not spawn two sessions or two tickets. Carry a transfer id so the telephony and CRM sides can dedupe, mirroring the discipline in telephony-and-pstn-integration.

The failure modes that only exist because an AI is in the loop.

A human-to-human warm transfer has known risks; inserting an agent adds four more, and each one is worse than the cold transfer it was meant to improve on:

• The summary that over-claims. A hallucinated or confidently-wrong brief is more dangerous than no brief, because the human trusts it and acts on it. Quote the caller and the system of record; mark anything the agent inferred as inferred; never let a generated summary assert a fact the transcript does not support.
• Context dropped at the seam. The packet is built but lost crossing from the voice platform to the CRM or the agent-desktop, and the human silently falls back to zero. Treat delivery as something to confirm, not assume — if the packet did not land, the human should know they are flying blind.
• The transfer loop. The human bounces the caller back to the agent, which escalates again, and the caller ping-pongs. Cap the number of hops, record each one, and route a re-escalated call to a supervisor, never back into the flow that already failed.
• Compliance state lost across the transfer. Recording consent, disclosure status, and any regulatory flags must survive the handoff. A call that started compliant must not become non-compliant because the state stayed on the agent's side of the seam.

Measure the repeat, not the transfer.

Transfer success rate is the vanity metric here — it counts connections, which is the part that was never hard. The numbers that describe whether the handoff actually served the caller:

• Repeat rate. Did the caller restate their identity or their problem to the human? This is the single number that captures whether the context packet did its job; drive it toward zero.
• Escalation precision and recall. Of the calls that should have escalated, how many did, and how early — and of those that escalated, how many actually needed a human. Both an agent that clings too long and one that dumps every call are failing, in opposite directions.
• Time-to-human and abandonment during transfer. How long the seam lasts, and how many callers hang up inside it — the direct measures of whether your "no human" branch is doing its job.
• Post-transfer resolution and re-escalation. Did the human resolve it, and did any calls loop back? Feed these into evaluating-voice-agents so the escalation policy is tuned on outcomes, not intuition.