Call Transfers

Call transfers hand the live call off to a human or another endpoint. You configure them with the call transfer action, which decides where the call goes, how it gets there, and what the recipient hears when they answer.

Types of Transfers

Synthflow supports four transfer types. The right one depends on where the call needs to land and how the destination is decided.

The settings that control how the transfer behaves once a destination is chosen, such as transfer modes, office hours, hold music, and timing, apply to every transfer type and are documented in the sections that follow.

Phone Number Transfers

Phone number transfers (or TEL), route the call to a standard phone number in E.164 format. The same action works across any telephony connection, since the destination is just a number.

SIP Transfers

SIP transfers route the call to a SIP URI such as a PBX, softphone, or SIP trunk. They are the right choice when TEL handling is not supported by your carrier or when you need to attach metadata to the transfer leg via custom X-headers. They work with any SIP-compatible endpoint, including Asterisk-based PBX systems such as FreePBX.

For prerequisites, setup, custom X-headers, supported URI formats, and security, see the dedicated SIP transfers page in the Telephony section. For broader telephony context, see our available SIP integrations, how to direct SIP dialing, and how to forward calls to a SIP trunk.

Dynamic Transfers

Dynamic transfers resolve the destination at call time from a value that is either injected by a pre-call webhook before the call starts, or returned by a custom action during the call. Use them when the right destination depends on caller input, real-time CRM lookups, or scheduling logic.

How it works

The custom action returns one or more candidate destinations, the agent picks the right one based on the conversation, and the transfer action reads the chosen value via template syntax ({results.data.phone_number}) or a bare variable name (phone_number). The system detects this pattern and configures the transfer as dynamic, extracting and normalizing the phone number at runtime.

The walkthrough below illustrates this flow with a customer support routing example.

1
{
2
  "customer_id": "{customer_id}",
3
  "issue_type": "{issue_type}"
4
}

1
[
2
  {
3
    "phone_number": "+14155552345",
4
    "agent_name": "Sarah Johnson",
5
    "department": "Technical Support",
6
    "specialty": "billing",
7
    "available": true
8
  },
9
  {
10
    "phone_number": "+14155556789",
11
    "agent_name": "Mike Chen",
12
    "department": "Technical Support",
13
    "specialty": "account_access",
14
    "available": true
15
  }
16
]

Use cases

Handling failures

Your custom action can handle failures gracefully by returning multiple potential destinations, ordered by priority:

1
[
2
  {
3
    "phone_number": "+14155551234",
4
    "agent_name": "Primary Agent",
5
    "priority": 1
6
  },
7
  {
8
    "phone_number": "+14155555678",
9
    "agent_name": "Backup Agent",
10
    "priority": 2
11
  },
12
  {
13
    "phone_number": "+14155559999",
14
    "agent_name": "Overflow Queue",
15
    "priority": 3
16
  }
17
]

The agent attempts transfers in priority order if earlier attempts fail.

• Return an available flag on each destination so the agent knows which ones are reachable.
• Order destinations by priority for retry behavior.
• Use a warm mode so the agent can retry on transfer-failed-timeout instead of dropping the call.
• Handle the empty-results case in the agent’s prompt (offer to take a message, schedule a callback, or transfer to a general queue). The standard transfer outcome states still apply.

Phone book Transfers

Phone books let you manage multiple potential transfer destinations from one place. The agent picks a destination based on the conditions you configure, so you can change targets without modifying every transfer action that uses them. A phone book can hold up to 50 numbers.

To create one, add each phone number along with the transfer condition that should route to it (for example, “caller asks for billing”).

Transfer Settings

The Transfer Settings tab controls how the handoff feels to the recipient and the caller, and how the transfer recovers when something goes wrong. These settings apply to every transfer type.

Transfer Modes

The controls available for each mode:

Preserve Original Caller ID

Shows the original caller’s number to the recipient instead of the Synthflow agent’s number.

Human Detection

Waits for a live human to answer before playing the whisper message or summary, so the briefing doesn’t reach voicemail, an IVR, or empty air. The Human Detection Timeout (30 seconds to 30 minutes) sets how long the AI waits; if no human is detected in that time, the fallback behavior is triggered.

Summary Prompt

Controls how the AI summarizes the conversation for the recipient. Auto generates the summary automatically. Custom lets you define a prompt that guides what the summary covers, for example account numbers, issue categories, or caller sentiment.

Recipient Message

The short whisper text the recipient hears before being connected. Supports variables.

Call Screening

Let the recipient ask questions and accept or decline the call before connecting.

Continue recording after the transfer

Keeps recording the call after the handoff. Off by default.

Stage messages and timing

These fields shape what the caller hears during the handoff:

• “Trying to reach the recipient” message plays while the AI is dialing the recipient. Use it to set expectations and keep the caller engaged during the wait.
• “Recipient answered” message plays once the recipient has picked up and is ready to be connected. Keep it brief: the caller is about to be bridged through.
• “Recipient failed/declined to answer” message plays if the recipient doesn’t pick up, is unavailable, or declines (see transfer outcome states). Use it to offer alternatives like continuing the conversation or trying again later.
• Pre-Message Pause and Post-Message Pause are silence buffers before and after each stage message. Default 1 second each.

Human Availability

The Human Availability schedule restricts transfers to specific days, time ranges, and timezones. When disabled, transfers are attempted at any time. When enabled, you set per-day availability hours, pick a timezone, and provide a “Human not available” message that the agent uses when a caller asks to be transferred outside of those hours, for example “There is no-one available to take your call at the moment. Please try again later.”

Use this when your destination is staffed during business hours only, or when out-of-hours calls should fall back to a message instead of a transfer attempt.

Background Music

Background music plays while the call is being transferred so the caller hears something other than silence. Toggle Enable Background Music in the action settings and pick a music type from the available options (Classical, Ambient, Modern Jazz). You can preview each option before saving.

Advanced Settings

The Advanced Settings tab fine-tunes timing and DTMF behavior.

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.

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

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, for example apologize, take a message, try an alternate destination, or schedule a callback.

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.

FAQ