The Handoff, Not the Conversation, Decides Whether a Voice Agent Is Usable

Ask a team why they switched off their voice agent and almost nobody says the voice sounded wrong or the answers were poor. They say callers ended up back at reception explaining the whole thing from scratch, or that the agent transferred people into a queue at seven in the evening, or that the sales team stopped trusting the notes it left. The conversation was fine. The exit was not.

This is worth stating plainly because the market still sells on conversation quality. Latency, interruption handling and naturalness of speech are genuinely better than they were, they are broadly comparable between serious providers, and they are not where deployments die. Deployments die at the boundary, in the handful of seconds when the agent stops being responsible for the call and something else has to take over.

The handoff is a data problem wearing a telephony costume

A transfer looks like a telephony operation, so it gets treated as one: dial a number, bridge the call, done. That framing is why so many handoffs are bad. Bridging the audio is the easy half. The hard half is that a human now has to reconstruct everything the caller already said, and unless the system hands it over explicitly, that context is gone.

What has to travel with the call is short and specific:

1. The caller's number and, where you have it, the matched customer record.
2. The reason for the call in the caller's own words, not the agent's category label.
3. What the agent already told them, so nobody contradicts it thirty seconds later.
4. Anything already collected: a date offered, a reference read out, an address confirmed.
5. Why the agent handed over, distinguishing "out of scope" from "could not understand" from "caller asked for a person".

That fifth item is the one teams skip and later wish they had. "Out of scope" is a working system doing its job. "Could not understand" three hundred times a month is a defect report. If your logs collapse both into a single transfer event, you have no way to tell whether the agent is improving.

Four handoff types, and the failure attached to each

Most implementations build one transfer path and use it for everything. There are really four, and they fail differently.

Handoff type	When it applies	The failure mode when it is done badly
Warm transfer	Someone is available now	Audio bridges before context arrives, so the human starts cold
Cold transfer to queue	Team is available but busy	Caller waits after already investing five minutes, and abandons
Callback commitment	Out of hours, or no one free	Promised without a real slot, so the callback never happens
Written handoff only	Non-urgent, asynchronous work	Note lands in a system nobody reads until Monday

The callback row causes the most damage per occurrence. An agent that says "someone will call you back shortly" without writing a task into a system with an owner has not handled the call. It has ended it while creating an obligation nobody holds. Callers treat a stated commitment as a commitment, and the second one is broken you have lost more trust than a straight "we are closed until nine" would ever have cost.

Design the handoff against the clock, not against the org chart

The single most common configuration error is routing built from an organisational structure rather than from a calendar. Enquiries go to sales, complaints go to the complaints owner, technical questions go to support. All correct at eleven on a Tuesday morning and all wrong at nine on a Sunday night, which is exactly when a voice agent earns its place, because that is when the alternative was nobody at all.

So the routing table needs the hour as an input alongside the category. For each category, three answers: who takes it in hours, who takes it out of hours, and what the agent says when the honest answer is that nobody takes it until tomorrow. The third answer is the one that needs writing before launch, because in its absence the agent will improvise, and improvisation on a phone call is how you get a promise your business cannot keep.

Volumes matter here too. A category that arrives twice a week can route to one named person's mobile. A category arriving forty times a day cannot, and needs a queue with real capacity behind it or a different resolution path entirely. Work out the per-category volume from your existing call logs before you assign destinations. Our guide to what an AI receptionist can and cannot do is a reasonable starting point for which categories are worth automating at all.

The systems on the other side set the real timeline

Here is the part that reorders project plans. Getting an agent to hold a competent conversation is now a matter of days. Getting the handoff to work end to end depends entirely on what it has to hand off into, and that is where the weeks go.

If your calendar is a shared Google calendar and your CRM has a usable API, the handoff is straightforward. If bookings live in a scheduling system with no write access, or your CRM is an on-premises install behind a VPN, or the out-of-hours rota is a spreadsheet someone updates by hand, the handoff has to be built around those constraints and the timeline changes shape. Our guide to how long an AI integration takes sets out where the time actually goes, and in voice projects it is nearly always the write path into existing systems rather than the model work.

There is a permissions question sitting alongside it. A handoff that includes a transcript is a handoff that moves customer speech, sometimes including account details and health or financial information, between a voice provider, a model provider and your own systems. Deciding what may be retained, for how long, and by which party is a decision to take before you design the payload rather than after. The considerations in our guide to sending company data to AI providers apply directly, with the extra wrinkle that a voice deployment usually involves two vendors in the chain instead of one.

What to measure once it is running

Containment rate tells you how many calls avoided a human. It says nothing about whether the ones that reached a human reached them well. Four numbers are more useful:

• Handoff completion rate: of calls the agent tried to transfer, how many actually reached a person or a logged callback.
• Repeat rate: how often the human had to ask for something the caller had already given the agent. This is the direct measure of whether context is travelling.
• Callback honour rate: of callbacks promised, how many happened inside the stated window.
• Handoff reason split: out of scope against not understood against caller requested, tracked over time.

Sample a handful of transferred calls each week and listen to the first thirty seconds after the transfer. That thirty seconds tells you more than any dashboard, because it is where a caller decides whether the whole arrangement wasted their time.

What to do next

Before evaluating any platform, write the routing table: category, in-hours destination, out-of-hours destination, and the exact words for when nobody is available. Then check, for each destination, whether the receiving system can actually accept a note or a task programmatically. That second check is what determines your timeline, and it is answerable in an afternoon.

With the table and those answers in hand, a scoping conversation about AI voice assistants and inbound call handling becomes concrete: not whether the agent can talk, but what it can hand a call to when it stops.