A warm transfer is a live call handoff in which the current agent briefs the receiving person before connecting the caller. A cold transfer sends the call through without that conversation. For sales and support teams, the choice affects what the next person knows, how long the caller waits, and who handles a failed connection. With an AI voice agent, those handoff decisions need explicit behavior for the briefing, connection, recovery, and call record.
Warm transfer vs. cold transfer
The defining difference is whether the recipient gets a briefing before speaking with the caller. A warm transfer gives the receiving person context while the caller waits. A cold transfer has no spoken consultation between the transferring agent and the recipient.
Phone systems often label warm transfers attended or consultative, and cold transfers blind or unattended. Terminology varies by system.
For calls using the Session Initiation Protocol (SIP), RFC 5589, published as Best Current Practice 149, describes consultation and attended-transfer mechanics. The transferring party establishes a conversation with the recipient before completing the handoff.
A webhook-routed transfer sends a request to your application for a routing decision at handoff time.
| Transfer approach | Who speaks first? | What does the recipient know? | When does it fit? |
|---|---|---|---|
| Warm transfer | The current agent briefs the recipient before the caller joins. | The reason for the call and relevant background from the briefing. | Sales handoffs, complex support issues, and escalations where context matters. |
| Cold transfer | The caller reaches the destination without an agent-to-recipient briefing. | Whatever is available separately, such as an existing record. No spoken briefing is included. | Simple requests for a named person, department, or automated destination. |
| Webhook-routed transfer | The handoff behavior determines who speaks first. A routing request does not provide a spoken briefing. | Depends on the handoff and the information your application supplies. | A destination that your own system must select at transfer time. |
Webhook routing describes how the destination is chosen. Warm and cold describe the handoff experience. Keeping those decisions separate prevents a routing integration from being mistaken for a complete human handoff.
In Dasha, we support warm transfers that brief the recipient before connecting the caller, and cold transfers that free the AI agent immediately. Choose from our call transfer options according to the conversation's needs.
When should a call get a warm transfer?
Use a warm transfer when the recipient needs information already gathered on the call to take the next useful action.
- A qualified sales conversation: Pass along the caller's stated need, relevant qualification answers, and the question they want a salesperson to answer. Keep unknowns explicit. Interest in a product does not establish readiness to buy.
- A support issue that exceeds the agent's authority: Include the problem, actions already attempted, their results, and the decision a person must make.
- An escalation: Explain what remains unresolved and what the caller expects. Keep the briefing factual rather than labeling the caller as difficult. Our call escalation playbook covers the broader response process.
- A request to speak with a person: Honor the request without forcing the caller through more qualification. Brief the recipient with whatever useful context is already available.
A cold transfer fits a simple request such as reaching a specific extension before any substantive discussion. It can also fit an automated menu that expects the caller to make the next selection. A long consultation adds little when there is nothing useful to pass along.
A cold transfer can still carry a separate customer record. A warm transfer can still have a poor briefing. The label alone does not establish handoff quality.
How an AI agent should make a warm transfer
The sequence is: decide, select a destination, call, brief, bridge, and step back. Each step needs a clear result before the next one begins.
1. Decide to transfer and explain the next step
Define the conditions that require a person: an explicit request, an authority boundary, or an unresolved issue that needs human judgment. Give the caller a plain explanation of who can help and why.
Ask permission to put them on hold while the recipient is contacted. For example:
“I can connect you with billing and explain what we've already discussed. May I put you on hold while I reach them?”
If the caller declines, offer only alternatives the workflow can fulfill. Do not promise a callback unless someone will own it.
2. Select the destination
Choose the person or team responsible for the next action. A recipient who can discuss the issue but cannot act on it may create another transfer.
Keep destination selection separate from confirmation that someone has answered. A configured number, a staffed department, and a person ready to take this call are different things.
3. Call the recipient while managing the hold
The caller should know the connection is still in progress. Define a bounded waiting policy and a return path to the conversation if the handoff cannot proceed. Avoid promises about the wait that the system cannot support.
A ringing destination is still an attempt. An answered destination may also be a menu or voicemail. Neither event alone establishes that a person received the briefing.
4. Brief the recipient with the facts needed next
Use a compact structure:
- Reason: Why is a person needed?
- Context: What did the caller say, and what has already happened?
- Next action: What does the caller want the recipient to do?
- Unknowns: Which important facts remain unconfirmed?
For example, a support briefing could say:
“The caller disputes an invoice charge and wants billing to explain it. They say the charge appeared after a plan change. We have not confirmed the cause or promised an adjustment.”
This gives the recipient a starting point without turning the caller's explanation into a verified finding. A fixed announcement suits a narrow, predictable handoff. A conversation-generated briefing can carry case-specific details, with instructions to preserve uncertainty and omit irrelevant information.
5. Bridge the caller into the conversation
Connect the caller after the recipient has received the briefing and the handoff can proceed. Make the change of speaker clear so the caller knows who is taking over.
Confirmation of an answered phone and confirmation of a ready recipient should remain separate in the workflow. If the recipient cannot help, return to the caller with an accurate explanation and an available next step.
6. Step back and define what happens afterward
Once the person takes ownership, the AI should stop competing for the conversation. Decide separately what happens if that person disconnects: end a completed call, or resume with the caller if help is still needed and the platform supports that behavior.
A resumed agent needs the current state. Repeating the original qualification questions after a human conversation defeats the purpose of preserving context.
Plan for busy, unanswered, and interrupted transfers
A failed connection needs its own caller experience. Treat these outcomes separately:
- Busy or unavailable: Return with the known result. One failed destination does not establish that every representative is busy.
- No answer: Stop waiting at the configured boundary and explain that the intended recipient did not answer.
- Caller disconnects during the attempt: Record an incomplete handoff rather than a completed transfer.
- Recipient disconnects after joining: Distinguish a finished conversation from an interruption before resuming or closing.
For a warm transfer in Dasha, we can resume the agent's conversation or end the call when the destination is busy, unavailable, or unanswered, according to configuration. Resuming when the person disconnects is a separate option.
Resuming the AI conversation does not create an automatic warm-to-cold fallback or establish a retry sequence. Keep any further attempt and any promised follow-up explicit.
Preserve the conversation and its ownership
The spoken briefing serves the person taking the call. The persistent record serves the team responsible afterward. Design both.
When enabled in Dasha, call recording continues during a warm transfer and speech recognition stays active. Configure these separately so the intended audio and text record extends through the handoff.
In your application, keep a customer relationship management (CRM) summary that includes:
- The call identifier and transfer reason.
- The selected destination and whether the caller was actually connected.
- The useful facts, attempted actions, and unresolved questions.
- Any promise made to the caller, with its owner.
- The post-transfer outcome, or an explicit unknown when it is unavailable.
A transcript alone does not assign follow-up responsibility. A successful connection alone does not establish a resolved issue or a completed sale. If the receiving team's outcome is unavailable, preserve that gap instead of inferring success from call duration.
Choose the destination and caller ID deliberately
For a small set of destinations, clear descriptions can distinguish which team handles each request. In Dasha, an agent can have several transfer destinations, with the language model selecting the route from the conversation.
When your own system must decide the destination at transfer time, we support webhook-routed transfers. They require your webhook and add the time taken by that request. Keep the recipient briefing, caller hold, and failure behavior in the handoff design alongside that routing decision.
Caller ID also affects the recipient's workflow. In Dasha, the person sees the agent's number by default, or the original caller's number when configured. Choose the presented number to suit how the team recognizes transferred calls and handles return calls. The briefing still needs to explain why the call is arriving.
Measure the handoff beyond “transfer started”
Separate an attempted transfer, an answered destination, a connected caller, and a business outcome. Collapsing them into one success event hides where calls stop progressing.
Use consistent definitions:
| Measure | Definition | What it helps diagnose |
|---|---|---|
| Transfer rate | Calls with a transfer attempt divided by calls in the defined reporting population. | Whether the agent is handing off more or fewer calls, broken down by reason. |
| Destination answer rate | Answered destination attempts divided by all destination attempts. | Whether destinations are reachable. Separate automated answers where observable. |
| Caller connection rate | Attempts that connect the caller to the recipient divided by all attempts. | Whether answered attempts become actual handoffs. |
| Time to answer | Elapsed time from starting the destination call to its answer. | Recipient reachability, separate from briefing time. |
| Caller hold duration | Elapsed time from placing the caller on hold until they join or leave the handoff. | The full wait, including unsuccessful attempts. |
| Post-transfer outcome | The receiving team's recorded resolution, sales next step, or other defined result. | Whether the handoff achieved its purpose. |
Keep call-level and attempt-level counts distinct when a call has more than one attempt. Include unanswered attempts and callers who leave in the hold-duration view; otherwise the report describes only people who stayed.
Transfer hold time is also different from the initial queue wait. Our average wait time guide explains that earlier delay and its reporting boundaries.
A warm-transfer example on Dasha
For a support handoff, configure the transfer condition around a request that needs the support team's judgment. Use a conversation-generated briefing to pass along the issue, actions attempted, and unresolved request. Choose whether recording and speech recognition continue, whether the agent resumes after an unsuccessful connection, and whether it can resume after the person disconnects.
For a repetitive handoff with little variation, use a fixed recipient briefing instead. For direct routing without a briefing, use a cold transfer.
Our voice AI agent platform supports these handoff patterns for teams building their own agents. The warm-transfer configuration provides the setup details for recipient briefings and recovery behavior.
Frequently asked questions
Is a warm transfer the same as an attended transfer?
Often, yes. Phone systems commonly use warm, attended, or consultative for a handoff with a recipient briefing, and cold or blind for one without it. The labels and exact connection behavior vary by system.
Can an AI voice agent do a warm transfer?
Yes. The AI can call the recipient, deliver a fixed or conversation-generated briefing, and connect the caller afterward. In Dasha, both briefing approaches are available. The handoff also needs defined behavior when a person cannot be reached.
Is a transferred call still recorded?
It depends on the platform and configuration. In Dasha, recording can continue during a warm transfer when enabled. Speech recognition is a separate option that can also remain active.
What happens if nobody answers a warm transfer?
The configured failure behavior controls the next step. In Dasha, the agent can resume its conversation with the caller or end the call. A failed warm transfer does not imply automatic cold-transfer fallback.
Does a warm transfer mean the caller never repeats anything?
No. The briefing gives the recipient context to continue the conversation. The person may still need clarification or information the AI did not collect. A useful briefing preserves established facts and unresolved questions without promising that every follow-up question will disappear.
Give the next person the context to act and the caller a clear recovery path. Build your first agent with Dasha and define the handoff around the people taking your calls.
