Agent Handover
The mechanism that moves a conversation to a person with everything already said. It is the part that decides whether an assistant feels helpful or feels like an obstacle.
The mechanism that moves a conversation to a person with everything already said. It is the part that decides whether an assistant feels helpful or feels like an obstacle.
What it does
Handover is the transfer of a live conversation from the assistant to a human agent. Technically it is routing plus context; experientially it is the moment a customer finds out whether the assistant was helping them or delaying them.
Every assistant reaches its limit. What distinguishes a good deployment is not how rarely that happens but what happens next — how quickly a person arrives, and whether they arrive knowing what has already been discussed.
Where it shows up in a conversation
Explicit requests
A customer asking for a person, which must always work immediately.
Configured boundaries
Complaints, distress, money, or anything the agent was told not to attempt.
Repeated failure
Escalating after two unsuccessful attempts rather than continuing to try.
Low confidence
Where the assistant is uncertain and the consequence of being wrong is material.
Agent-initiated
A human watching a conversation stepping in before the customer has to ask.
Out of hours
Telling a customer plainly when someone will be available rather than queueing them into silence.
Why it is harder in two languages
Language routing is the bilingual requirement that most deployments miss. A conversation conducted in Arabic that reaches an English-speaking agent has achieved nothing — the customer now explains again, in a second language, to someone who cannot read the transcript in front of them.
Queue routing therefore has to treat language as a first-class attribute, alongside topic and skill. Where an organisation cannot staff both languages at all hours, the honest configuration says so rather than routing an Arabic conversation to whoever is free.
Transcript readability follows the same logic. Translating a transcript for an agent loses exactly the nuance that made the customer upset, which is why routing by language beats translating the record.
What to look for when you evaluate it
| Time to a person | From the request, not from when an agent noticed. Beyond a couple of minutes it reads as being ignored. |
|---|---|
| Context completeness | Whether the agent sees everything. The test: does the customer have to repeat anything? |
| Language routing | Whether an Arabic conversation reaches an Arabic-speaking agent. |
| Availability of escalation | Whether asking for a person always works, or the assistant deflects first. |
| Out-of-hours behaviour | Silence is the worst answer. A clear statement of availability is the minimum. |
| Unified record | Whether the assistant and human halves remain one reviewable conversation. |
Where it should not be trusted alone
Handover should not be made difficult in order to improve containment. This is the most common quiet failure in the industry: a metric improves while the relationship deteriorates, and the deterioration surfaces months later as churn rather than as complaints.
It should not be silent either. A customer told they are being connected, who then waits with nothing happening because presence was misconfigured, experiences the same thing as being ignored deliberately.
And the assistant should never pretend the handover has happened when it has not, or imply a human is present when one is not. That specific deception damages trust disproportionately when it is discovered, and it is always discovered.
How this fits the whole
No single capability answers a question on its own. A conversation passes through several in sequence — understanding what was asked, finding the relevant material, composing a reply, checking it before it is sent — and the quality of the result is set by the weakest link rather than the strongest.
That has a practical consequence for evaluation. Vendors tend to demonstrate their strongest component, and a system with excellent retrieval and weak language handling will demo beautifully and disappoint in production, because the demo was conducted in the language and phrasing the system handles best.
It also explains why grounding matters more than raw capability. A more capable model that answers from its own training rather than from your material produces confident, fluent, unsupported answers — which is a worse outcome than a less capable one that retrieves correctly and declines when it cannot. Capability without grounding increases the cost of being wrong rather than reducing it.
The pieces are described separately here because that is how they are evaluated and configured. They are not experienced separately: a customer asking a question encounters one system, and judges it as one.
Where this sits in a conversation
- Something arrivesA typed message, a spoken sentence, an uploaded document. The first job is establishing what was actually received — which language, which script, whether it is legible, whether it is one question or several.
- It is interpretedWorking out what is being asked rather than what words were used. The same question arrives phrased twenty different ways, in two languages, often mixed, frequently misspelt, sometimes as a fragment.
- Material is retrievedThe relevant part of your own approved content is found. This is where answer quality is largely decided: a correct answer assembled from the wrong source is still wrong.
- A reply is composedIn the language of the question, in the configured tone, from the retrieved material and nothing else. Where the material is silent, the reply says so rather than filling the gap.
- It is checkedBefore sending, the reply is examined for claims the retrieved material does not support and for personal data that should not be repeated back. This runs on every reply.
- It is deliveredAs streamed text, as speech, or as a structured response — and the conversation is recorded so that what happened can be reviewed later.
Why this is built rather than bought in
Every capability described here could, in principle, be obtained by calling somebody else's service. That is how most assistants in this market are assembled, and it is why so many of them cannot answer the question that decides regulated procurements: where does the data go.
When a component is a call to an external provider, every question that passes through it leaves the organisation. That may be perfectly acceptable for a retailer answering questions about opening hours. It is usually not acceptable for a bank explaining a transaction, a hospital confirming an appointment, or a public body handling a citizen case — and the constraint is architectural, so it cannot be configured away later.
The second consequence is control over behaviour. A capability obtained as a service behaves the way the provider decides, changes when the provider changes it, and cannot be tuned for the specific way your customers speak or write. A capability that runs inside your own estate can be adjusted for dialect, for your terminology, and for the particular failure modes your material produces.
The third is continuity. External services are deprecated, repriced and withdrawn. A deployment whose core capability depends on somebody else's roadmap inherits that roadmap, including the parts nobody announced in advance.
Measuring this component honestly
| Measured in which language? | Nearly every published benchmark in this field was developed against English. An overall figure that averages across languages hides exactly the gap that matters in this market. |
|---|---|
| Measured on what input? | Clean or realistic. Read speech or spontaneous speech. Typed text or phone-typed text with autocorrect. The difference between these is usually larger than the difference between vendors. |
| Measured by whom? | Self-reported figures with an undescribed method are marketing. Ask for the test set and the procedure. |
| What counts as correct? | A surprising number of published figures count a partially correct answer as correct. Ask what the scoring rule was. |
| How does it fail? | A component that degrades gracefully is worth more than one with a higher headline figure that fails silently and confidently. |
| Does it report uncertainty? | A component that surfaces low confidence lets the system confirm rather than guess. One that hides it produces confident errors downstream. |
What to ask about this specifically
Ask for the Arabic figure
Not the overall figure. Nearly every published benchmark in this field was developed against English, and the gap between the two languages is where deployments disappoint.
Ask how it was measured
Against what test set, by whom, on what kind of input. A number without a described method is marketing rather than measurement.
Ask what it does when uncertain
Whether uncertainty is surfaced or hidden. A component that hides low confidence produces confident errors downstream.
Ask about real conditions
Noisy audio, poor scans, dialect, informal phrasing, mixed languages. Laboratory conditions are not predictive of contact-centre reality.
Ask where processing happens
For any component touching personal data, this is a procurement question rather than a technical curiosity in regulated sectors.
Ask what is retained
What data this component keeps, for how long, and whether it is used to improve anything.
Common questions
Yes, immediately. Asking for a person is an instruction, not a question to be answered, and systems that deflect first convert mild frustration into complaints.
The full conversation, what was retrieved, and anything the customer already provided. If the agent has to ask the customer to repeat, the handover failed.
Where the queue is configured for it. Language is a routing attribute rather than an afterthought — reaching an agent who cannot read the transcript achieves nothing.
The customer is told plainly when someone will be. Silent queueing is the most damaging default in this whole area.
Yes, where you enable it — watching a conversation go badly and stepping in before the customer has to ask.
It should be. Splitting the assistant and human halves across two systems makes review harder exactly when review matters.