Most automation programmes are judged on what happens before the handoff. The interesting economics are on the other side of it.
A customer who has spent four minutes with an assistant and is then asked “can I take your account number?” has not been helped. They have been delayed. Whatever the assistant saved in handle time, the restart just spent, and the customer now believes the automation was a gate rather than a service.
What a handoff should carry
We treat escalation as a contract with a defined payload, not as a transfer of a chat window. Four things cross the boundary:
- The transcript, in full, with the assistant’s turns marked as such.
- The resolved intent, plus the confidence and the reason the assistant stopped.
- The systems state the assistant read — the records, the identifiers, the figures — with timestamps, so the agent knows how fresh it is.
- The action it could not complete, named specifically: “issue a goodwill credit above the automated limit”, not “customer needs help”.
That last item is the one most implementations skip, and it is the one that determines whether the agent’s first sentence is useful.
Verification should not happen twice
If the assistant authenticated the customer, the agent desktop should reflect that, at the assurance level the authentication actually achieved. Re-verifying a customer who has already verified is the single most common complaint we hear in post-handoff surveys, and it is nearly always an integration gap rather than a policy requirement.
Where the action being requested needs a higher assurance level than the assistant obtained, the step-up should be explicit and explained — “because this changes your payout details, I need to confirm one more thing” — not a silent restart of the whole interview.
Agents on deployments with a full context payload open the conversation knowing the record, the figures and the blocked action. The first ninety seconds of re-interviewing simply disappears.
Design the stopping rule before the flow
Deciding when to escalate is a product decision and belongs in the specification, not in a prompt written late in the build. Ours usually looks like a short list: categories that are never contained, a repeated-failure rule, an explicit request for a human, and a distress signal.
Two of those are worth stating plainly. An explicit request for a person should always be honoured immediately — arguing with it destroys more goodwill than the contained contact was worth. And a repeated failure means two attempts, not five.
The measurement that matters
Containment tells you how many conversations did not reach an agent. It says nothing about whether the ones that did arrived in a usable state.
We ask agents a single question after a transferred conversation: did you have what you needed to start? It takes three seconds, and the trend line on that number is the earliest warning we have found that a read path has broken, a payload field has silently stopped populating, or a new intent is escaping the stopping rule.
What it changes
When the handoff carries context, escalation stops being a failure state. It becomes the deliberate route for the work that genuinely needs a person — which is the only version of the arrangement that customers experience as service rather than obstruction.
