> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Live Handoff (Warm Transfer)

> Live Handoff is a script-wide safety net: when a caller asks for a human, the assistant offers a warm transfer to a routing endpoint, checks the endpoint's availability, and connects the caller with a private briefing first. This page covers the full settings section and what happens on the call.

## What is Live Handoff?

Live Handoff lets a caller reach a human at any point in a call. You don't place it at a particular step — once it's enabled, the assistant listens for a request to speak to a person ("can I talk to someone?", "put me through to a human") on every conversation step it's active on. When it hears one, it offers to transfer, confirms the caller wants it, and then warm-transfers the call to a [routing endpoint](/routing/endpoints) — with hold music for the caller and a private briefing for the team member before the two are connected.

Live Handoff is configured per script under:

**Scripts → *(your script)* → Settings → Live Handoff**

The section is a card described as "Configure handoff defaults, flow overrides, and availability windows".

Live Handoff is the right tool when a transfer can be requested *anywhere*. When a *specific step* in your flow should transfer the caller — "let me put you through to bookings now" — place the [Warm Handoff tool](/tools/warm-handoff) at that step instead. And when the caller should simply end up at a different part of the *same script*, with nothing dialled, use [Intent Pathways](/scripts/intent-pathways).

***

## What happens on a call

1. **The caller asks for a human.** On each caller turn, the assistant checks whether the caller has asked to speak to a person. This only happens on steps where Live Handoff is active (see [Flow & step overrides](#flow--step-overrides)).
2. **Availability is checked.** The configured routing endpoint is resolved through its [schedule](/routing/schedules) at that moment. If it's closed, the assistant apologises with a natural out-of-hours line — for example *"Sorry, none of the team are currently available right now."* — the conversation continues, and handoff offers are suppressed for the rest of the call. Live Handoff needs a routing endpoint configured to do anything — without one, a request for a human isn't acted on.
3. **The assistant offers, then confirms.** If the endpoint is open, the assistant offers the transfer in its own words — for example *"Sure, I can try connecting you with someone now if you like?"* (the phrasing varies between calls). It then listens for the caller's reply, judged on meaning rather than exact wording. A yes — or a few seconds of silence — starts the transfer; a no resumes the conversation exactly where it left off.
4. **The transfer runs.** The caller hears your chosen hold music while the endpoint's destination is dialled. The assistant privately briefs the team member with a summary of the call, then merges the two and bows out. The full transfer experience — staging, briefing, merge, and what each party hears — is described on [Transferring calls](/routing/transferring-calls). A connected transfer gets a fresh 30-minute time allowance, so a long human conversation is never cut short by the script's Max Call Duration.
5. **If the transfer fails** — no answer, busy, or the team member's voicemail picks up (which the assistant detects before the caller hears it) — the assistant speaks your Failure Message and the conversation returns to the step the caller left off at.

If a Live Handoff request and an [intent pathway](/scripts/intent-pathways) trigger on the same caller turn, Live Handoff wins — a live "get me a human" always beats a pathway redirect.

***

## Turning it on

The top bar of the Live Handoff section holds the master switch and the hold audio:

| Setting      | Description                                                                                                                  | Default                                     |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| Live Handoff | Master switch. When off, every card below is greyed out and no handoff offers are made on calls.                             | Off                                         |
| Hold Music   | What the caller hears while the transfer is dialling ("Select hold music"). Choose from the platform's hold-music catalogue. | A jazz lounge track plays if none is chosen |

***

## Destination

The **Destination** card carries a single field: **Routing Endpoint**. This is where the caller goes — and it also decides *when* they can go. A routing endpoint bundles a destination (a team member, phone number, or SIP address), an availability schedule, and a fallback, all managed on the [Numbers & Routing page](/routing/endpoints). SIP destinations are set up with the Voxworks team, not self-serve — see [SIP Trunking & BYO Carrier](/numbers/sip-trunking).

* The picker lists your endpoints sorted by location, each row showing the endpoint name, its department and destination, and a live status dot — green for open, grey for closed. Selecting an endpoint shows it with its location and department alongside.
* Each row has an open-link icon that jumps straight to that endpoint on the Numbers & Routing page.
* If you have no endpoints yet, the field reads *"No routing endpoints configured yet. Create one on the Numbers & Routing page."*
* If a selected endpoint is later deleted, a warning appears: *"The selected routing endpoint no longer exists. Pick another one."* If the endpoint has a configuration problem, the picker flags it and notes that transfers will follow the endpoint's fallback.

**Use variable** — below the picker, this toggle swaps the fixed endpoint for a variable expression, so the destination can differ per call. Type `/` to insert a variable — for example a custom variable field such as `{{custom.clinic.endpoint_id}}` (string — e.g. `3f6c2c1a-8b0d-4e2f-9a41-6c7d5e8f9a01`) that holds the right endpoint for the caller's clinic. The value must resolve to a routing endpoint; **Use literal** switches back to the picker.

***

## Warm transfer messaging

The **Warm transfer messaging** card sets what each party hears. It's laid out in two columns — **Contact** (the caller) and **Team Member** (the human being dialled) — with **Failed** and **Connected** outcome messages beneath. Every message field supports variables: type `/` to insert one, such as `{{contact.first_name}}` (string — e.g. `Jane`).

| Setting                         | Description                                                                                                                                                                                                   | Default                                                                                           |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Transfer Initiated Message      | Spoken to the caller just before dialling begins. Spoken in full — the caller can't interrupt it — so keep it brief.                                                                                          | A natural built-in line, varied between calls — e.g. *"One moment, I'll try connecting you now."* |
| Introduction Message            | Extra instructions and details to include in the private briefing the assistant gives the team member before the caller is merged — e.g. the caller's name and what they need. The caller does not hear this. | The assistant builds its own summary of the call                                                  |
| Wait for team member to accept? | When on, the assistant holds the briefing until the team member speaks first — useful when transfers land on a general line and you want a person, not a greeting machine, before handing over.               | Off                                                                                               |
| Timeout (sec)                   | How long to wait for the team member's acceptance before treating the transfer as failed. Only editable when the wait toggle is on; leave it blank to wait as long as it takes.                               | Blank                                                                                             |
| Call Acceptance Message         | A phrase the team member says to accept the call — matched on meaning, not exact wording, so keep it short and distinctive. Blank means any response from the team member counts as acceptance.               | Blank — any response accepts                                                                      |
| Failure Message                 | Spoken to the caller when the transfer fails after dialling — no answer, busy, or voicemail. The conversation then continues with the assistant.                                                              | *"I wasn't able to transfer you just now, so I'll keep helping here."*                            |
| Post-merge Message              | What the assistant says once the caller and team member are both on the line, before it leaves them to it.                                                                                                    | Empty — e.g. *"Ok I'll leave it with you two from here."*                                         |

The Failure Message covers failures *after* dialling starts. A closed endpoint never dials at all — the caller hears the built-in out-of-hours line instead (see [Out-of-hours handling](#out-of-hours-handling)).

***

## Flow & step overrides

The **Flow & step overrides** card fine-tunes where Live Handoff is active: *"Each flow inherits the script destination above. Enable a flow and pick which of its steps may trigger a handoff."*

Every flow in the script — the main flow, the pre-call flow, and any child flows — appears as a collapsible row. The row header shows the flow's current state at a glance:

* **Enabled / Disabled / Inherited** — whether the flow has its own setting or follows the script-level switch.
* A step count such as `3/12 steps` — how many of the flow's steps have handoff attached.
* An endpoint marker when the flow overrides the script destination.

Each row has its own switch, and expanding it reveals:

| Setting                     | Description                                                                                                                                                                                         | Default                 |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| Routing Endpoint (override) | A different destination for handoffs triggered in this flow — e.g. billing questions to the accounts line while everything else goes to reception. **Inherit script endpoint** clears the override. | Inherit script endpoint |
| Steps with handoff          | Which of the flow's steps can trigger a handoff, via the **Select handoff steps** picker. **Attach to all** ticks every step at once.                                                               | None selected           |

Settings resolve top-down: the script level sets the defaults, a flow can override them, and a step selection is the most specific of all. Anything you leave blank at a lower level inherits from the level above, so a flow that only overrides the endpoint still uses the script's messages and hold music. Handoff offers are made on conversation steps — tool steps run their own configuration and are not affected by these overrides.

***

## Out-of-hours handling

Availability comes entirely from the routing endpoint's [schedule](/routing/schedules) — there is no separate hours setting on the script. That keeps hours in one place: change the schedule on the Numbers & Routing page and every script transferring to that endpoint follows suit. The status dot in the endpoint picker always shows whether the endpoint is open right now.

When a caller asks for a human while the endpoint is closed:

* The assistant explains naturally — *"Sorry, the team is not available right now."* (the wording varies between calls) — and carries on helping.
* Handoff offers are switched off for the rest of that call, so the assistant doesn't repeatedly offer a transfer it can't complete.
* Availability is re-checked at the moment the transfer actually starts, so a caller confirmed just before closing time is still handled correctly.

If out-of-hours callers should get more than an apology — a message taken, or a different closing flow — pair Live Handoff with an [intent pathway](/scripts/intent-pathways) whose off-schedule branch routes them to a message-taking part of your script.

***

## Next Steps

* [Endpoints](/routing/endpoints) — create the transfer destinations Live Handoff dials, grouped by location and department.
* [Schedules](/routing/schedules) — the business-hours definitions that decide when an endpoint is open.
* [Transferring calls](/routing/transferring-calls) — the full runtime story of a warm transfer, from hold music to merge.
* [Warm Handoff tool](/tools/warm-handoff) — transfer at a specific step of your flow, with per-step control over every message.