Call transfer and IVR handoff testing checks that a voice agent moves a caller to another agent, a queue or a human without losing context, dropping the leg or stranding the caller. Cekura tests the transfer as part of a full simulated call, scoring each turn, because a transcript-level score cannot see which side of a handoff failed.
Last updated: August 2026 By Janhvi Nandwani, Founding Member, Cekura
TL;DR
- Cekura treats the handoff as the least tested and most fragile part of a voice deployment, because it spans two systems and neither owns the failure.
- Cekura asserts that control transfers completely: LiveKit's documentation states "Control transfers fully to a new agent. The original agent doesn't participate afterward."
- Cekura asserts on context preservation rather than assuming it, because it is a design decision and not a default.
- Cekura treats voicemail detection as a timing problem, not just a classification one, because Twilio's AMD returns different values depending on whether you wait for the greeting to end.
- Cekura tests the outbound failure modes inbound never sees: answering machines, wrong numbers, and callers who did not ask to be called.
Why do call transfers fail in voice agent deployments?
Cekura treats a transfer failure as a boundary problem: no single component owns the handoff, so the agent believes it handed off, the receiving system believes it received a fresh call, and the caller experiences neither.
LiveKit's workflow documentation is explicit about what a handoff does: "Control transfers fully to a new agent. The original agent doesn't participate afterward." On context it is equally direct, describing the choice as "Explicit: pass chat_ctx, summarize, or start fresh," and advising teams to "Plan how conversation context is preserved or reset across agents."
That word "plan" is the whole problem. Context preservation is a decision someone makes, and an untested decision is indistinguishable from an unmade one. Teams generally do make the decision, write it into the handoff, and never assert on it again, so the first prompt change that alters what the context object carries breaks the transfer silently.
The failures below all present to the caller as the agent being unhelpful, and all of them survive a transcript-level score intact.
| Failure | What the caller experiences | What a transcript score sees |
|---|---|---|
| Context dropped | Asked to repeat everything | A complete conversation |
| Transfer never completes | Silence, then a dropped call | A truncated transcript |
| Wrong destination | Correct information, wrong department | Nothing wrong |
| Data lost mid-handoff | Account number re-requested | A clarifying question |
| Voicemail treated as human | An agent talks to a machine | A one-sided conversation |
| Authentication not carried | Re-verified after already passing | A repeated security prompt |
How do you test call transfer and IVR handoff for voice agents?
Cekura tests a handoff by asserting on the transfer event itself, turn by turn, rather than scoring the finished conversation.
When to hand off is itself a studied prediction problem. Time to Transfer, at AAAI 2021, introduces a metric called Golden Transfer within Tolerance, built on the observation that the right moment to transfer is a window rather than a point. Carry that tolerance into testing: an assertion demanding an exact turn fails on behaviour a caller would have accepted.
Three assertions carry most of the value: that the transfer fired and reached the intended destination, that entities captured beforehand survive it, and that the media leg stayed up, since a transfer completing logically while dropping media leaves the caller in silence.
Per Cekura's benchmarks, one agent was deployed unchanged across six orchestration platforms with a byte-identical, SHA-verified system prompt and four tool definitions, scored by 59 evaluators across four categories with each scenario run three times. That three-run method transfers directly: a handoff that succeeds once and fails once is the common case a single run cannot catch. Those published figures measure orchestration under a fixed harness and do not measure transfers.
What does voicemail detection testing for voice AI need to cover?
Cekura's voicemail detection testing for voice AI covers timing, not only the human-or-machine verdict, because the same detector answers differently depending on when you ask.
Twilio's answering machine detection exposes the trade. Under MachineDetection=Enable, AnsweredBy returns immediately as machine_start, human, fax or unknown. Under DetectMessageEnd, a machine result waits for the greeting to finish, returning machine_end_beep, machine_end_silence or machine_end_other. Exceeding MachineDetectionTimeout, 3 to 59 seconds and 30 by default, returns unknown.
Cekura tests every outcome. A greeting ending in silence rather than a beep is a distinct code path, and unknown is the one teams forget: the call is live, the agent has no verdict, and something must still happen.
Detection is hard rather than solved. A recurrent neural network approach to answering machine detection reports "an accuracy of over 96% on the test set" and notes "an accuracy exceeding 98% can be achieved with the integration of a silence detection algorithm." Even at 98%, one outbound call in fifty is misclassified.
What does outbound voice AI QA cover that inbound does not?
Cekura's outbound voice AI QA covers the entire question of who answered, a question inbound never has to ask because the caller dialled deliberately.
An inbound agent knows a human is present and wants something. An outbound agent may reach a person, a voicemail greeting, a fax tone, a wrong number, an automated switchboard, or nobody at all, and it must behave correctly in each case before any conversation logic runs.
That widens the test matrix in a specific direction. Alongside normal conversation scenarios, outbound QA needs coverage of every answering-machine detection branch from machine_start through unknown, of the case where a person answers mid-greeting, and of what the agent says in its first two seconds, since an outbound opening carries disclosure obligations an inbound one does not. Cekura constructs these as scenarios against a live agent, an approach documented in Cekura: Scripted Testing Tool for IVR and Voice Agents.
What does enterprise authentication flow testing for voice agents require?
Cekura's enterprise authentication flow testing for voice agents proves that a verified caller stays verified across every hop, and that an unverified one never inherits access.
Authentication is where the transfer failure becomes a security question rather than an experience one. If verification state does not survive the handoff, the receiving system either re-challenges a caller who already passed, which is merely annoying, or trusts a caller who did not, which is not.
The assertions are specific: that the challenge fires before any protected action, that a failed attempt cannot be retried indefinitely, that verification state is explicitly carried or explicitly re-established on transfer, and that spoken credentials are redacted from stored transcripts and audio. Cekura covers the cross-channel version of this, where an IVR passes a caller to chat, in Ensuring Reliable IVR to Chatbot Journeys.
Where does Cekura fit?
Cekura tests the handoff as part of the call rather than as a separate integration test. Cekura simulates a full conversation against a live agent over a real telephony path, drives it to the transfer point, and scores each turn against configurable evaluators, so a dropped entity or a lost verification state is attributed to the turn where it happened.
Cekura's predefined metrics cover word error rate and character error rate for transcription, time to first token and end-of-turn detection accuracy for latency, and behavioural checks including hallucination, relevancy and response consistency, documented in A Developer's Guide to Voice AI Evaluation Metrics. Cekura covers the surrounding IVR discipline, including coverage of branches a conversational front end still contains, in IVR Testing Explained.
The reason to test transfers repeatedly rather than once is the same reason Cekura's benchmark scores every scenario across three runs. An intermittent handoff failure is the one that reaches production, because it passed the day someone checked it.
Frequently asked questions
What is call transfer testing for voice agents?
Cekura's call transfer testing verifies that a voice agent hands a caller to another agent, queue or human without losing context or dropping the leg. Cekura asserts on the transfer event itself, on whether captured entities survive it, and on whether the media leg stays up, rather than scoring the finished transcript.
Why do voice agent handoffs lose context?
Cekura finds context loss traces to an explicit design choice, not a default. LiveKit's documentation describes the options as passing the chat context, summarising it, or starting fresh, and states that control transfers fully with the original agent no longer participating. Cekura asserts on whichever option a team picks, because an unasserted choice regresses silently on the next prompt change.
How do you test voicemail detection?
Cover every return value and the timeout, not just human versus machine. Twilio's AMD returns machine_start under Enable, and machine_end_beep, machine_end_silence or machine_end_other under DetectMessageEnd, plus unknown when MachineDetectionTimeout is exceeded. Each is a separate code path, and unknown is the most commonly untested.
How accurate is answering machine detection?
Altwlkany, Delalic, Selmanovic, Alihodzic and Lovric, in a recurrent neural network approach to the problem, report "an accuracy of over 96% on the test set" rising above 98% "with the integration of a silence detection algorithm." At 98%, roughly one outbound call in fifty is still misclassified, so the agent's behaviour on a wrong verdict has to be tested rather than assumed away.
What is different about outbound voice AI QA?
Cekura tests who or what answered before any conversation logic runs, covering answering machines, fax tones, wrong numbers and no answer. Inbound skips that entirely because the caller dialled deliberately. Outbound openings also carry disclosure obligations that inbound ones do not.
