Skip to main content

​
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 — 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 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.

​
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).
  2. Availability is checked. The configured routing endpoint is resolved through its schedule 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. 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 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:

​
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. SIP destinations are set up with the Voxworks team, not self-serve — see SIP Trunking & BYO Carrier.
  • 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). 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).

​
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: 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 — 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 whose off-schedule branch routes them to a message-taking part of your script.

​
Next Steps

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