Call Transfers | Synthflow

Call transfers allow your AI agent to seamlessly hand off conversations to a human when needed. In Synthflow, these handoffs are managed using the call transfer action.

Synthflow supports four transfer types, each suited to different use cases:

Transfer Type	Format	Best For
TEL (Phone Number)	E.164 format (e.g., `+14155551234`)	Direct transfers to mobile or landline numbers
SIP	SIP URI (e.g., `sip:user@domain.com`)	Transfers to PBX systems, softphones, or SIP trunks
Dynamic	Runtime-determined	Transfers where the destination is fetched during the call
Phonebook	Managed list	Multiple destinations with conditional routing

TEL (Phone Number) Transfers

Use TEL transfers for direct handoffs to a phone number in E.164 format. This is the default transfer option in Synthflow, ideal for routing calls to mobile phones, landlines, or call center queues.

TEL URI transfers are confirmed to work with Twilio and Telnyx. If you’re using a different carrier or a self-hosted PBX, TEL URI handling may not be supported. In that case, use a SIP transfer instead, as SIP URIs are more universally supported across carriers and PBX platforms.

Key features:

Supports warm and cold (blind) transfer modes
Configurable timeout and transfer messages
Optional background music during transfer

Learn more about phone number transfers

SIP Transfers

Use SIP transfers when routing calls to SIP-compatible endpoints such as PBX systems, SIP phones, or softphones. SIP transfers use a SIP URI format instead of a phone number.

Key features:

Works with any SIP-compatible endpoint (Asterisk, FreePBX, etc.)
Supports warm and cold transfer modes
Context preservation with conversation summaries

Learn more about SIP transfers

Dynamic Transfers

Use dynamic transfers when the destination number isn’t known in advance. Your agent can fetch the target number during the call using a custom action or a pre-call webhook, enabling flexible routing based on caller input, business logic, or real-time data.

Key features:

Fetch phone numbers from CRM systems or APIs during the call
Route to on-call staff based on schedules
Location-based or tier-based routing

Learn more about dynamic transfers

Phonebook Transfers

For scenarios where you have multiple potential transfer destinations, use phonebooks to manage them in one place. A phonebook allows your agent to transfer to different numbers based on conditions, all from a single action.

Key features:

Centralized management of transfer destinations
Conditional routing based on caller input or context
Easy updates without modifying agent configuration

Learn more about phonebooks

Transfer Modes

All transfer types support the following modes:

Mode	Description	Caller ID Shown	SIP Method
Blind (Cold)	Transfer immediately without speaking to the recipient	Original caller’s number	SIP REFER
Warm (Message)	Play a private whisper message to the recipient before connecting	Synthflow agent’s number	SIP INVITE
Warm (Summary)	Provide an AI-generated conversation summary to the recipient	Synthflow agent’s number	SIP INVITE

The whisper message in warm transfers is heard only by the receiving agent, not the caller. This allows you to provide context like “Incoming call about a billing dispute” before the agent accepts.

Human Detection

When using warm transfers, enable Human Detection to ensure the whisper message or summary is only delivered once a live human answers. This prevents the briefing from playing to voicemail, IVR queues, or empty air.

You can configure a Human Detection Timeout to control how long the AI waits for a live human before treating the transfer as failed.

Feature Comparison

Feature	Blind (Cold)	Warm (Message)	Warm (Summary)
Recipient hears context	No	Yes (custom message)	Yes (AI summary)
Caller ID passthrough	Yes	No	No
Hold music for caller	Yes	Yes	Yes
Human detection	No	Yes	Yes
Retry on failure	No	Yes	Yes

Caller ID Behavior

How caller ID is displayed depends on the transfer mode and your telephony provider:

Blind (cold) transfers: Use SIP REFER, which passes through the original caller’s number. The receiving party sees who is actually calling.
Warm transfers: Use SIP INVITE to create a new call leg, so the receiving party sees your Synthflow agent’s phone number.

Caller ID passthrough for cold transfers requires your telephony provider to support SIP REFER. Most major providers (Twilio, Telnyx, Vonage) support this, but verify with your provider if you experience issues.

Transfer Outcome States

Every transfer produces one of five outcome states, tracked in your call records and available via the API. Use these states to monitor transfer performance, configure fallback behavior, and debug issues.

Outcome State	Description
`transfer-success`	A live human was detected on the transfer leg and the caller was bridged successfully.
`transfer-failed-timeout`	The transfer target did not answer within the configured timeout period. Covers scenarios where the phone rang with no answer, rang into voicemail (if voicemail detection is not enabled), or queue hold time exceeded the timeout.
`transfer-failed-connection-error`	The transfer could not be initiated or the connection failed at the telephony level. The call never reached the transfer target. Covers invalid or unreachable numbers, SIP REFER rejections, telephony provider errors, SIP DIAL failures, and blocked or out-of-service numbers.
`transfer-cancelled`	The transfer was initiated but cancelled before completion — either by the caller hanging up during hold, or by the system.
`transfer-screening-rejected`	The transfer recipient declined the call during call screening. The AI resumes the conversation with the caller and can attempt a fallback action.

Outcome behavior by transfer mode

How the agent responds to a failed transfer depends on the transfer mode:

Outcome State	Blind Transfer	Warm Transfer
`transfer-failed-timeout`	Call ends	Agent can retry or continue conversation
`transfer-failed-connection-error`	Call ends	Agent informed, can try alternate
`transfer-cancelled`	Call ends	Agent resumes conversation with caller
`transfer-screening-rejected`	N/A (screening requires warm transfer)	Agent resumes conversation, can attempt fallback

Blind transfers cannot recover from failures. If reliability is critical, use warm transfers to allow graceful fallback behavior.

For warm transfers, you can configure fallback behavior:

Timeout duration: How long to wait before the transfer is marked as transfer-failed-timeout
Fallback behavior: What the agent should say or do on any non-success outcome (e.g., apologize, take a message, try an alternate destination, or schedule a callback)

Hold Experience

While the caller waits for the transfer to connect, you can customize their experience:

Hold music: Enable background music during the transfer wait time
Transfer announcement: Optionally announce “Please hold while I transfer you” before the music starts

Configure these options in the transfer action’s settings.

Variables

When you configure a call transfer action, you can type placeholders with angle-bracket names—for example <case_id> or <department>—directly in the fields below. Each distinct name becomes an input variable on that transfer action.

After you attach the transfer to an agent, open it from the agent’s Actions tab and map each input: bind it to a fixed value or to any variable your agent or flow already provides (collected during the call, system fields, pre-call data, another action’s results, and so on).

You can introduce those placeholders here on the transfer action:

Phone number to transfer
SIP URI
Extension
Warm transfer — contextual summary prompt (the instructions the model uses to summarize the call for the person who answers)
SIP header values

Example: On a SIP transfer action, the SIP Headers section sets header X-Reference to <queue_ref>. That defines one input variable named queue_ref. After the same transfer is added to a flow, the Input variables panel lists queue_ref; here it is mapped to data returned by an earlier action result of a custom action, so the receiving side gets a stable correlation id on the SIP leg without hard-coding it in the action template.