Consider a repair-service caller who wants a manager to explain a charge. The AI finds the service record but cannot approve an adjustment. It calls the manager. Nobody answers.
In this hypothetical example, the caller still needs help. The workflow must either keep the conversation going or record a next step that someone will handle. If it cannot save that request, it must not tell the caller a callback has been arranged.
Designing those outcomes before launch gives the receiving team something specific to test.
What Is Human Handoff in Voice AI?
Human handoff in voice AI moves a caller from an AI-led conversation to a person, along with the information and responsibility needed to continue.
For operational purposes, we recommend counting a live handoff as complete when the appropriate person has accepted the work, the caller is connected, and the person has the context they need. Resolving the issue is a separate outcome.
A phone transfer alone does not establish all of that. Moving between two AI assistants is not a human handoff, either. Our AI voice agent guide covers the broader call workflow.
The boundary is especially important in property inquiries: an agent can collect requirements and arrange a viewing, while negotiation, legal or financial guidance, disputes, and unverified listing answers should move to a qualified person. See the workflow and escalation boundaries in our guide to AI voice agents for real estate.
| Option | When it fits | What to verify |
|---|---|---|
| Cold or blind transfer | A simple request for a known department, with little need for a briefing | Destination behavior, any separate notes, and who handles failures after the AI releases the call |
| Warm transfer | A complaint, complex issue, or conversation that needs a briefing | Whether the mode sends context, detects a person, asks for acceptance, and handles an unanswered call |
| Callback or ticket | Nobody suitable is available, or the caller prefers not to wait | The request was saved, a team owns it, and its progress is tracked |
A bridge connects the caller and receiving person. A whisper is a private spoken briefing to the receiving side. An IVR is an automated phone menu. A callback is a later call from your team.
Transfer names do not establish the exact behavior. Retell's transfer documentation, for example, distinguishes ordinary warm transfer from an agentic version in which a separate AI speaks with the destination and decides whether to connect or cancel.
A cold transfer can still have a separately delivered customer record. Conversely, a warm-transfer message does not prove the receiving person agreed to handle the case.
Set the Triggers, Priority, and Destination
Define When the AI Should Stop
Write conditions your team can recognize in a test call:
- The caller asks for a person.
- The request needs approval, an exception, or authority the AI does not have.
- Approved information cannot answer the question.
- Identity verification or a connected-system action cannot be completed safely.
- Repeated misunderstandings, corrections, or failed actions prevent progress.
- Frustration indicates that the caller may benefit from human help.
Honor an explicit request without adding unnecessary troubleshooting or sales questions. Frustration can inform routing, but a sentiment label alone should not determine urgency. An ordinary change of request is not a reason to escalate if the AI understands it and can proceed.
In the service-charge example, the limit is authority. Finding a record does not authorize the AI to decide that the charge is wrong.
Match Priority to Staff and Coverage
An urgent service interruption may need an authorized specialist or on-call team. A routine charge explanation may go to the service desk. Both routes need a fallback.
There is no required number of escalation queues. Use the teams, skills, and priority rules your organization can actually staff. Keep emergency handling on a separately approved and tested path, not in an ordinary callback queue.
Open hours and current availability are different. A department can be open while everyone is busy. Record its timezone, holidays, language requirements, and on-call coverage. If the workflow cannot check live availability, plan for unanswered calls instead of assuming someone is free.
Use this policy card for each call type. These are recommended operating fields, not a platform configuration schema.
| Policy field | Decision to record |
|---|---|
| Trigger | What requires a person, and what the AI may still do |
| Priority | The business reason for handling this case sooner |
| Destination | Authorized team, number or queue, and required skills |
| Coverage | Hours, timezone, holidays, and source of availability information |
| Waiting and attempts | Total permitted wait and attempt limit |
| Backup | Approved alternate destination or follow-up process |
| Accountable owner | Team responsible for failed transfers and overdue work |
| Stop condition | Verified takeover, caller withdrawal, or recorded recovery outcome |
Here, an owner means a person or team accountable for the work. The AI can manage the conversation without replacing that accountability. For broader front-desk coverage choices, see our AI receptionist workflows.
Give the Receiving Person a Usable Brief
Include What Has and Has Not Happened
The brief should tell the receiving person what the caller needs and what remains to be done. Make it available when the person needs it, rather than relying only on a summary generated after the entire call ends.
Use these fields:
Caller goal:
Transfer reason and priority:
Identity and verification status:
Confirmed facts:
Completed actions and confirmation:
Failed or unknown actions:
Next decision or action:
Record or evidence reference:
Callback permission and confirmed contact, if needed:
Current owner:In the service-charge example, the essential distinction is straightforward: the caller questions the charge; the system has found the service record; no adjustment has been approved. The manager needs to review it. Writing "incorrect charge confirmed" would turn a complaint into an unsupported finding.
Likewise, distinguish a caller-provided name, a matched account, and completed identity verification. Pass the verification status, but let the receiving team apply its own requirements. Sharing a status does not remove every reason to verify again.
Confirm a callback number with the caller when needed. That confirmation is not proof of identity or control of the number. Share only the information the intended recipient is authorized to receive.
Check Delivery and Corrections
A short spoken briefing can introduce the case; a customer relationship management system (CRM) or ticket can hold the fuller record. Your team should check both what arrives and when it becomes available.
Context delivery depends on the connection. ElevenLabs documents that its warm-transfer message requires its native Twilio integration and is not available on SIP-based transfers. SIP helps phone systems connect calls; it does not by itself ensure that the receiving person gets the full transcript.
Check corrections, too. Retell's documented transfer agent receives the earlier conversation, but not speech added after the transfer starts. A corrected detail therefore needs a tested way to reach the recipient; do not assume a second agent automatically receives every update.
Preserve completed business actions. If an appointment was saved but the human transfer failed, retrying the handoff must not create another booking. Our guides to recording call outcomes in your CRM and reliable AI appointment booking cover those separate results.
Define When the Handoff Is Complete
Track what you can prove. These stages are a reporting model, not universal event names or a required sequence for every phone system.
| Stage | What it establishes | What it does not establish |
|---|---|---|
| Requested | A caller or rule asked for a person | A transfer was attempted |
| Attempted | The destination was dialed | Someone answered |
| Answered | The destination picked up | The answerer is human or willing to help |
| Human detected | The system classified the answerer as a person | The person accepted this case |
| Human accepted | An appropriate person agreed to take it | The caller is connected and context is available |
| Connected with usable context | The live handoff meets the defined checks | The issue is resolved |
| Follow-up saved | Recovery work was recorded | Someone acknowledged or completed it |
An automated queue can accept a call under a defined service process. Record that as queue receipt, not human acceptance. If the system cannot observe what happens after a blind transfer, retain an unknown result rather than inventing a success.
Even familiar status names need checking. In Twilio's Number reference, the completed call-progress notification can follow an unsuccessful outcome such as busy or no answer. In its separate Dial reference, DialCallStatus=completed describes an answered, connected call. Neither proves that a person accepted the work or resolved the issue.
Ask your implementation team which records support acceptance, connection, and context delivery. For a managed warm transfer, retain a working recovery path until those checks pass. After a released blind transfer, recovery may instead belong to the receiving phone system or follow-up team.
What Should Happen When the Transfer Fails?
Choose Recovery Based on Who Still Controls the Call
Before planning a return to the AI, confirm that the system can still do it. A bridge connects call participants; the word does not guarantee that the original AI remains available afterward.
In Vapi's assistant-based warm-transfer mode, labeled Experimental in its documentation, fallback configuration determines whether the original assistant can continue or the call ends. That is a specific configuration, not a guarantee for all transfers.
Assign real team names to the suggested roles below. The team controlling the live call handles caller messaging; the accountable owner follows any unfinished work.
| Result | Recovery action | Accountable owner |
|---|---|---|
| Busy or no answer | Offer the approved alternate, wait, or callback choice; stop at the total wait and attempt limit | Receiving team or recovery team |
| Voicemail | Use it only as an approved message route; never record it as live human acceptance | Team monitoring that mailbox |
| IVR or queue | Navigate or wait only if supported and permitted; otherwise use the fallback | Queue or routing owner |
| Wrong team or refusal | Use an authorized alternative without bouncing between the same destinations | Routing supervisor |
| Team closed | Follow the actual hours and after-hours policy; do not invent a response deadline | After-hours recovery team |
| Number or carrier failure | Record the connection error; retry only when justified and within the limit | Phone-system owner, with the recovery team handling the caller |
| Acceptance followed by bridge failure | Check whether either party remains connected; coordinate one follow-up | Accepting person or designated backup |
| Missing or incorrect summary | Deliver an authorized correction or record reference; do not claim the person already has it | Receiving team and integration owner |
| Caller disconnects or withdraws | Cancel pending transfer activity where possible; apply the permitted callback or closure rule | Current case owner |
| Callback or ticket save fails | Use a tested alternate record or alert route; do not confirm an unverified save | Follow-up system owner and recovery team |
Voicemail and IVR are not always technical failures. They may be approved destinations or intermediate steps, but they are not evidence that a person took over.
Keep the attempt result, destination, current owner, next action, and supporting record together. For cases needing sensitive or essential context, a connection without that context should remain an exception for review.
Keep Callback States Separate
A callback request should progress through distinct states:
Requested -> Saved -> Assigned -> Staff acknowledged -> Attempted -> Completed or closed with a reason
Save the request even if no staff member can acknowledge it immediately. Assign the request to a named team, set an internal deadline, and specify who must act if it becomes overdue. A staff deadline is not automatically a customer promise.
If a save times out, its result may be unknown rather than failed. Check for the existing request before creating another. If the system explicitly rejects it, use the backup path. In neither case should the caller hear that the request was recorded before confirmation.
Track the callback outcome as well: an attempted call, a conversation with the customer, and resolution of the original issue are different results.
Bound Retries and Use Honest Scripts
Set a total waiting and attempt limit across the whole handoff. Do not restart an unlimited allowance at each destination. Ask your implementation team to configure checks for delayed transfer confirmations and existing follow-up tasks before the workflow retries.
Use wording that matches the observed state:
- Before hold: "May I put you on hold while I contact the service desk?"
- After no answer, if the AI is still connected: "The service desk hasn't answered. Would you like me to request a callback?"
- After a confirmed save: "I've recorded your request for the service desk."
- If saving fails: "I couldn't save that request." Then explain the actual backup available.
Give a callback window only when the receiving team's agreed process supports it. If no reliable live or recorded recovery exists for a call type, keep it human-led until that gap is fixed.
Test the Failed-Transfer Scenarios Before Launch
Use preview calls to check conversation rules, then arrange controlled tests through the actual business number, receiving route, and follow-up system. Simulate faults in a test setup first; do not disrupt customer calls to create a failure.
Operations staff can make scripted calls and inspect what the receiving team gets. The implementation owner should simulate connection errors, delayed results, and failed saves.
| Test | Required result |
|---|---|
| Caller asks for a person | The first clear request triggers the approved path without unnecessary extra questions |
| Normal warm handoff and simple blind routing | Each mode has the expected connection, context, and recovery behavior |
| Conversation moves to another AI | The result is recorded as AI routing, not human takeover |
| Busy, no answer, voicemail, or IVR | Correct result is recorded; no false human-acceptance claim |
| Closed hours, holidays, or wrong team | Correct fallback, timezone handling, and owner |
| Person declines the call | The workflow uses the approved alternative or follow-up without connecting the caller to that person or repeatedly dialing them |
| Verification fails or the request is not authorized | The AI does not share restricted details or perform an unauthorized action; it follows the approved review or recovery path |
| Person accepts but connection fails | No false completion; one person or team handles recovery |
| Summary is late or the caller corrects a detail | Required information reaches the authorized recipient |
| Caller hangs up or declines a callback | Pending activity stops where possible; permission and closure rules are respected |
| Duplicate trigger or delayed success | No transfer loop, duplicate task, or competing callbacks |
| Booking succeeds but transfer fails | Existing booking remains intact; only missing work is recovered |
| Save fails, task is unacknowledged, or follow-up is overdue | No false promise; an accountable team sees and handles the exception |
For each test, record the date, workflow version, phone route, destination setup, language, conditions, and number of runs. Use this record for each result:
Scenario | Caller heard | Receiver received | Final state and evidence | Owner | Pass/fail and fix
Compare the observed result with the expected behavior in the table. Assign failed tests to an owner.
Do not launch an affected flow with unexplained dropped calls, false success messages, unauthorized disclosure, lost requests, duplicate actions, or unbounded loops. Retest after changes to routing, staff coverage, prompts, or integrations. Our voice agent latency testing guide covers timing and interruptions on real phone calls.
Measure Accepted Handoffs and Unfinished Work
Record requested, attempted, accepted, connected, and resolved outcomes separately. A call can involve several transfer attempts. State whether each rate counts handoff requests or individual attempts.
Use a metric dictionary like this one. These are proposed definitions, not built-in Airsound reports or industry benchmarks.
| Measure | Definition |
|---|---|
| Live handoff completion | Requests with verified acceptance, caller connection, and usable context divided by all eligible live-handoff requests |
| Attempt outcomes | Each result, including busy, no answer, declined, failed, canceled, and unknown, divided by all transfer attempts |
| Caller waiting time | Time from the defined handoff request or waiting start to verified human connection; report unsuccessful waits separately |
| Context quality | Reviewed handoffs with an available, accurate brief divided by all reviewed handoffs |
| Follow-up work | Saved, unacknowledged, overdue, attempted, and completed requests reported separately |
| Business resolution | The verified outcome of the underlying request, independent of transfer success |
Define eligibility before reporting. Keep failed and unknown outcomes visible. If callers withdraw their request or choose a callback, show those outcomes separately and disclose any exclusions.
Rates need a collection period, sample size, workflow and route scope, denominator, and original records. Review changes by destination, trigger, hours, and language where the sample allows it.
These measures guide investigation; they do not diagnose the cause by themselves. A gap between request and acceptance could involve routing, staffing, caller withdrawal, or missing records. If you also measure repeat calls about the same issue, link calls to customer and case records; call-status logs alone may not be enough.
Do not judge the workflow only by how rarely it escalates. A requested or necessary handoff is an appropriate outcome.
Plan and Test the Workflow with Airsound
At Airsound, we provide visual workflows for call routing, information collection, CRM updates, SMS, and full-context human handoff. Teams can define fallback rules that transfer a call, create a ticket, send a summary, or mark a case for follow-up.
Our preview calls help check intent detection, knowledge responses, and handoff rules before launch. Transcripts, outcomes, and workflow events are available for review and export.
Use those capabilities to build the call flow, then verify the receiving phone route and follow-up records with your implementation team. Acceptance signals, waiting limits, retry behavior, and the reporting definitions in this guide still need to be mapped to your setup. Test each transfer mode you plan to use, since acceptance and recovery behavior can differ.
Before launch, complete the policy card and test both a successful handoff and an unanswered transfer. Request an Airsound demo to walk through your workflow, the receiving person's context, and the follow-up record left when nobody answers.
