Skip to main content

​
Description

Use Warm Handoff to Human Agent when the assistant should transfer the caller to a person and brief that person privately before merging the calls. Good fits:
  • Transfer qualified callers to sales, support, claims, or bookings teams
  • Escalate calls that need a human decision
  • Connect callers to a configured routing endpoint — a team, queue, or direct line — while preserving context from the conversation

​
What Happens

  1. The tool dials the human agent at the selected routing endpoint.
  2. It checks for voicemail. If voicemail is detected, the handoff fails.
  3. It privately speaks a short summary to the human (the caller does not hear this).
  4. It merges the caller and the human together.
  5. The assistant speaks the Merge Message so both parties know the handoff has happened.
The steps above describe a warm transfer. In a cold transfer, the tool dials the endpoint and connects the caller as soon as it answers, without the private briefing or a merge message. You choose between the two with the Transfer Mode input. If the handoff fails, the assistant can speak a Failure Message and continue the flow. The tool also records why it failed in the {{handoff.*}} variables, so the flow can respond differently to a busy queue and a number that rejected the call outright — see Variables this tool writes. Web calls can be handed off too. The assistant dials the human on one of your team’s phone numbers and joins them to the browser caller, converting the audio between web and phone quality automatically. The number to dial from is worked out once at the start of the call — the script’s number first, then the team default, then any number on the team. If none of those is usable, the handoff fails on the Otherwise condition rather than dialling with a broken caller ID. Out-of-hours handling is not a setting on this tool. Whether the handoff can run outside business hours is governed by the schedule attached to the routing endpoint you dial — see Routing Endpoints and Schedules.

​
Manual Inputs

​
Warm Handoff - Agent Name

The name or label of the person or team being connected — Sarah from claims, Claims Team, Property Manager, Support. Used in logs, transcript labels, and the private summary. Accepts literal text or a {{...}} variable (type / in the field to insert one). Use a name the caller would understand.

​
Routing Endpoint

The dial destination. Rather than typing a raw phone number, you select a routing endpoint — one of the destinations your team has set up under Numbers & Routing. The endpoint you pick supplies two things:
  • the number the tool dials, and
  • the open-hours schedule that decides whether the handoff can run right now.
Because the schedule travels with the endpoint, you set business hours once on the endpoint and every step that dials it inherits them — there is no phone-number field on this tool and no separate hours setting. See Routing Endpoints for how endpoints are configured, and Schedules for how their open hours are defined.

​
Transfer Mode

How the transfer happens. Choose one:
  • Warm — the assistant plays hold music to the caller, dials the endpoint, optionally waits for the human to answer, speaks a private summary to them, then merges the two calls and speaks the Merge Message so both parties know the handoff has happened. The assistant then goes silent.
  • Cold — the assistant connects the caller to the endpoint as soon as it answers, with no private briefing and no merge message.
Warm is the usual choice when the human benefits from context. Use cold for straight transfers where no briefing is needed. Merge Message is required when Transfer Mode is warm.

​
Warm Handoff - Merge Message

Spoken after the caller and human are connected in a warm transfer. Both parties hear this, so keep it short and do not include the private summary here. Accepts literal text or {{...}} variables (type / to insert one). Cold transfers do not use this message.
  • Thanks for waiting. I've got Sarah on the line now.
  • I've connected you with our claims team. They can help from here.

​
Handoff Initiated Message

Optional message spoken to the caller (only) before dialling starts, to set expectations before hold music begins. It plays uninterruptibly — the caller cannot barge in over it — so keep it short and avoid promising success.
  • One moment, I'll try connecting you now.
  • Sure, I'll see if someone is available.

​
Warm Handoff - Failure Message

Spoken if the handoff cannot be completed and the caller is still on the line. Make it a useful recovery line, and avoid saying the call is ending unless the flow will actually end.
  • I wasn't able to connect you just now, so I'll keep helping here.
  • The team is not available at the moment, but I can continue taking the details.

​
Warm Handoff - Hold Music

The audio the caller hears while the tool dials the endpoint and prepares the handoff. The dropdown offers:
  • Jazz lounge 1
  • Jazz lounge 2
  • Jingle 1
  • Rhythm 1
  • Rhythm 2
  • Slow latin
Use calmer music for longer expected waits, lighter sounds when handoffs are usually quick.

​
Warm Handoff - Wait For User

Controls whether the assistant waits for the human side to speak before giving the private summary.
  • false — normal handoffs; the assistant proceeds after the voicemail check.
  • true — wait for the human to answer or say something first. Useful for shared lines, reception queues, or team phones where you want to confirm someone is present.

​
Warm Handoff - Wait For User Message

Optional target phrase for the human side, used with Wait For User. The match is semantic, so minor wording differences still pass. Leave blank if any human speech should trigger the summary.
  • Hello, this is support.
  • Claims team speaking.

​
Warm Handoff - Summary Inputs

Extra instructions or context for the private summary spoken to the human before merge. Use it to tell the summary what details matter. Do not put caller-facing text here — this summary is for the human agent. Accepts literal text and {{...}} variable references (type / to insert one).
  • Include the customer's name, reason for calling, and requested appointment time.
  • Caller name: {{contact.full_name}}. Claim: {{custom.claim_id}}.
Any {{...}} variables are resolved to their current values before the summary is generated.

​
Warm Handoff - Timeout

Optional timeout, in seconds, for how long to wait for the human side to speak before the private summary. Used mainly with Wait For User. Leave blank to use the tool’s default behaviour.

​
Failure Override - Return to Last Step

Controls recovery behaviour after a failed handoff. Use false when the flow can continue from the current step. Use true when the caller should be sent back to the previous step or a retry path. This does not make the handoff more likely to succeed.

​
Manual Outputs

​
Conditions

​
Success (true)

The handoff completed and the call was transferred to the human.

​
Failure (false)

The handoff was skipped or failed — the routing endpoint was outside its scheduled hours, voicemail detected, no answer, request failure, timeout, or telephony error.

​
Variables this tool writes

Every handoff attempt records its outcome in the {{handoff.*}} variables. Later steps can read them to work out what happened, instead of guessing from a single true-or-false result. The whole last.* group is overwritten on every attempt, so it always describes the most recent one and never mixes values from two attempts.

​
What {{handoff.last.status}} can be

​
Branching on the outcome

Route the tool’s own Otherwise condition to a recovery step, then use a condition on {{handoff.last.status}} to decide what the assistant says. This is what lets a script stop telling every caller “we’re experiencing a high volume of calls” when the real problem is a dead number.
Treat an empty or unfamiliar status the same way you treat timeout, so an unexpected value still lands on a sensible line. You can also use {{handoff.attempts}} to stop retrying — for example, only offer a second attempt while {{handoff.attempts}} is less than 2.

​
The two conditions on the step

  • Success (true) — the handoff completed and the caller was transferred. The flow pauses permanently: no later steps run, so never place post-handoff logic on the success route expecting it to execute.
  • Failure (false) — the handoff was skipped or failed. The Failure Message is spoken and the flow continues from the current step; with Failure Override – Return to Last Step set to true, the caller is sent back to the previous step instead. Read {{handoff.last.status}} here to find out why.
For how variable references work across scripts and tools, see Variables.

​
Example Usage

In the app you pick the Routing Endpoint from your team’s configured endpoints; the examples below show the endpoint’s name in that field, not a phone number. Simple sales handoff (warm):
Support handoff that waits for a greeting (warm):
Reception handoff — business-hours gating comes from the routing endpoint’s schedule, not a tool input:
Cold transfer — connect straight through with no briefing (no Merge Message needed):

​
Common Issues

  • The handoff never starts — check the routing endpoint’s schedule and that all required inputs are set.
  • Returns false after dialling — read {{handoff.last.status}} on the failure route to see whether it rang out, was engaged, was rejected, or hit voicemail.
  • Every failure sounds the same to the caller — branch the failure route on {{handoff.last.status}} so the assistant says something that matches what actually happened.
  • Callers wait too long — reduce the Timeout or turn off Wait For User.
  • The human hears too little context — improve Summary Inputs.
  • The caller hears information meant only for the human — move it out of Warm Merge Message and into Summary Inputs.

​
Best Practices

  1. Keep caller-facing messages short
  2. Use Wait For User only when it solves a real routing problem
  3. Use Summary Inputs to highlight details a human must know immediately
  4. Set business hours on the routing endpoint’s schedule when dialling a human outside hours would create a bad experience
  5. Test each destination end to end — including voicemail, no-answer, and after-hours behaviour

​
Next Steps