What Happens When a Handoff Carries None of the Customer’s Request?

A human handoff fails when the agent transfers the call without the customer’s actual request, the language used, and the point where the conversation broke down. The human agent then has to ask the customer to begin again, often after the customer has already repeated themselves.

At 8:42 on a Monday morning, Esi is standing outside a support desk in Kumasi with one earbud in and a receipt folded into quarters in her hand. She has already tried three times to explain in Twi that her delivery instruction needs to change before the parcel goes out.

The voice agent recognises pieces of the request. It asks Esi to repeat the location. Then it repeats back a different issue. On the third attempt, Esi says she wants a person.

A human agent receives the transfer. The screen says only “transferred call.”

“Please explain the problem,” the human says.

Esi goes quiet for a second. The delivery could still be sent to the wrong place. She has already spent several minutes saying the same thing, and the handoff has carried none of it forward.

That pause is where a voice workflow loses trust.

A transfer event does not explain the customer’s need

“Transferred” tells an operations team that one call state changed. It does not tell the receiving agent what the caller asked for, what the voice agent heard, which language the caller used, or whether the caller corrected the agent twice before requesting help.

Those details determine whether the human can continue the conversation or has to restart it.

For a Twi and English voice experience, the missing context can be especially costly. A caller may switch languages mid-sentence, use a local phrase for the issue, or correct a place name that the system has misheard. The receiving agent needs the original request in a usable form, plus enough call history to see where confidence dropped.

A handoff record should make the next action obvious. At minimum, the human needs:

• The customer’s stated intent, captured as close as possible to their own words.
• The relevant conversation turns, especially repeats, corrections, and unresolved questions.
• The reason for transfer, such as a direct request for a person, a failed confirmation, or an escalation rule.
• Consent and contact status, so the team can handle the call within the rules already attached to it.

Without that, the transfer is a routing action. It does not preserve the work the customer has already done.

Build the handoff around the receiving agent’s first sentence

The practical test is simple: can the human’s first sentence prove they understand why the caller is here?

A useful opening might be: “I understand you want to change the delivery location, and you corrected the location twice. Let’s confirm the new instruction.” That sentence gives Esi a reason to stay on the line. It also lets the human verify the one detail that matters instead of searching through a blank call record.

This requires more than a generic call summary. The workflow needs to preserve the source turns that support the summary, because summaries can be wrong. If the agent understood “change the location” but missed the actual alternative location, the human needs to hear or read the correction before acting.

Asenda Talk’s current platform work includes telephony lifecycle webhooks with call-truth tracking, alongside consent, opt-out, and audit records for every call. Those are the building blocks for knowing what happened across a call. They do not, by themselves, guarantee a complete human-handoff experience. Teams evaluating a handoff design should define the intent payload, transcript access, escalation reason, and receiving-agent view before treating transfer as ready.

That distinction matters in early access. Native Twi speech recognition and synthesis are being developed in-house, and the assistant runtime is orchestrated through Vapi. Outbound calling remains gated behind an explicit telephony-provider decision that is not yet live. A handoff workflow should be evaluated against the call paths available today, rather than assumed from a future campaign flow.

Repeated attempts are evidence, not noise

Esi’s three attempts should change how the system behaves.

The first attempt may be an ordinary recognition error. The second should raise the possibility that the request is ambiguous or that the caller is using language the agent has not resolved well enough. By the third, the system has evidence that another repetition may make the interaction worse.

A good escalation rule treats repetition as context. It records what was attempted, marks the unresolved field, and gives the human a short explanation of the failure point. That helps the support desk improve the agent later without making Esi pay for the evaluation with another full retelling.

This is also where call-truth tracking has a practical role. A dashboard status such as “completed” can hide a poor outcome if the caller reached a human but had to restart from zero. Teams should separate a successful connection, a completed automated turn, a requested transfer, and a resolved human handoff. What Does “Completed” Actually Mean in a Voice Campaign Dashboard? explores why those states need different meanings.

The next call should leave a usable trail

Later that morning, Esi’s request reaches a human agent with the request, the failed confirmation, and the transfer reason visible together. The agent confirms the revised delivery instruction once. Esi folds the receipt back into her bag and ends the call knowing she did not have to start over.

That is the standard to design for: the human joins the conversation where the customer left it.

Before adding a transfer button, write the exact information the receiving agent must see. Test it with a Twi correction, a language switch, and a caller who asks for a person after repeated attempts. Keep the conversation turns available beside the summary. Review the handoff as a customer outcome, not only a telephony event.