Transfers exist because the person who answers a call is often not the person who should finish it. Routing objects (IVR, hunt groups, queues) decide where a call lands before anyone answers. A transfer is the human-initiated correction after answer: the current party redirects the live call to a colleague, a department, or an external number. Every phone system offers two flavors, and the difference between them is entirely about what happens before the handoff.
Vendors use several names for the same two operations. Blind is also called cold or unattended. Warm is also called attended, consultative, or announced. The mechanics below use blind and warm; map your platform's labels onto them once and the rest follows.
Blind transfer
In a blind transfer, the current party selects a target and releases the call immediately. There is no conversation with the target first. The caller hears hold music or ringback while the new leg is set up, and the transferee's phone simply rings with a call they know nothing about. If the target answers, the two are connected and the transferring party is out of the picture. The whole operation takes a couple of seconds of the transferring party's time.
Blind transfers are fast and fine when the target is a routing object rather than a person: sending a caller back to an IVR menu, into a queue, or to a voicemail box. They are riskier when the target is a human, because the transferee answers cold, the caller must repeat everything they already said, and if the target does not answer, the caller is now stranded on a leg that the transferring party has already left.
Warm transfer
In a warm transfer, the transferring party puts the caller on hold and places a separate consultation call to the target. The two employees speak privately: who is calling, what they need, what has been tried. Then one of three things happens: the transfer is completed and the caller is connected to the target; the target declines and the transferring party takes the caller back; or the target does not answer and the transferring party recovers the caller and offers an alternative.
- Caller is placed on hold (hold music, not silence).
- Transferring party dials the target on a consultation leg.
- Context is passed verbally: name, account, issue, anything sensitive the caller should not have to repeat.
- Complete the transfer (caller and target are bridged, transferring party drops), or take the call back.
The cost is the transferring party's time and the caller's time on hold. The payoff is that the caller never explains twice, the target is never ambushed, and no path leads to a dropped call. That trade is almost always worth it for anything involving an upset customer, money, health, or legal matters.
How transfers work in SIP, briefly
In standards-based SIP, both flavors use the REFER method (RFC 3515, with call-transfer usage detailed in the RFC 5589 family). For a blind transfer, the transferring endpoint sends REFER with the target's address, telling the caller's side of the dialog to place a new call to that target. For a warm transfer, the transferring endpoint first establishes the consultation call, then sends REFER with a Replaces parameter (RFC 3891), which tells the target's phone to replace the consultation leg with the caller's leg, splicing the two together.
Hosted platforms often do not expose raw REFER end to end. A platform acting as a back-to-back user agent can implement the same caller experience by bridging media legs itself: it holds the caller's leg, originates a new leg to the target, and joins them when the transfer completes. The observable behavior is identical; the difference matters mostly when debugging with packet captures or when transferring across systems that must interoperate at the SIP layer.
What the caller experiences
| Moment | Blind transfer | Warm transfer |
|---|---|---|
| At the handoff | Abrupt: 'transferring you now,' then ringback or hold music | Announced: 'let me check with X, one moment,' then hold music |
| Wait | Rings until the target answers, with no guarantee anyone will | On hold during the consultation; the wait is bounded by a person who knows the caller is waiting |
| First words with the new party | Caller re-explains from zero | Target already has the context and greets the caller by name |
| If the target does not answer | Voicemail, endless ringing, or a drop, depending on platform failover rules | The transferring party takes the call back and offers alternatives |
Transfers to external numbers
Transferring to a mobile or another company's number creates a new outbound leg on the PSTN, with consequences the internal case does not have. The caller ID presented on that leg is a configuration decision: pass the original caller's number so the target can call back and recognize the caller, or present the business's number so the target knows it is a transferred work call. Passing the original caller's identity can interact with STIR/SHAKEN attestation, since the platform is asserting a number it does not own. Both legs (caller to platform, platform to external target) also stay up for the duration, which is two billable call paths and two chances for quality problems.
Transfer vs forwarding vs conference
| Operation | When it happens | Who is connected afterward | Typical use |
|---|---|---|---|
| Transfer | During a live, answered call | Caller and the new target; the transferring party leaves | The answering person is not the right person |
| Forwarding | Before answer, by rule (always, busy, no reply) | Caller and the forward-to target; the original target never answered | Routing policy: after-hours, coverage, find-me |
| Conference | During a live call, adding a leg | All three (or more) parties simultaneously; nobody leaves | The caller should hear the specialist directly and the first party stays involved |
Failed transfers: never lose the caller
The cardinal rule of transfer engineering and transfer etiquette is the same rule: the caller must never end up worse off than before the transfer. A blind transfer to a target that does not answer should fall through that target's no-answer handling (voicemail, or better, back to a queue or the operator), never to endless ringing or a disconnect. Platforms differ in what they do with a REFER that fails; test the no-answer case explicitly, including transfers to external numbers where the platform cannot see the far end's state.
- Announce the transfer before doing it, and say what happens if it fails ('if we get disconnected, call this number back').
- Warm-transfer anything sensitive: billing disputes, cancellations, health or legal matters, or any caller who is already frustrated.
- Pass context in the consultation, not just the call: the caller's name, the issue, and what was already tried.
- Blind-transfer only into destinations that handle no-answer well: queues, group voicemail, an IVR, or a hunt group with a proper overflow.
- Do not chain transfers: a caller moved three times has usually been failed twice. If the right owner is unclear, take a message and own the callback.