Skip to main content

​
Overview

Endpoints are addressable transfer destinations — a phone number, team member, or SIP URI, joined to a location and department and governed by a schedule. SIP URI destinations, along with any other SIP connection, are set up with the Voxworks team rather than self-serve — see SIP Trunking & BYO Carrier. This page explains the runtime side: how a script gets a live caller to one of those endpoints, what is checked along the way, what happens when a destination is closed, and where the record of every transfer decision ends up. Configuration detail lives on the canonical pages for each feature — Live Handoff, Intent Pathways, and the Warm Handoff tool. Here we join them together.

​
How Scripts Reach Endpoints

There are three ways a script consults or transfers to a routing endpoint during a call: The distinction matters: Live Handoff and the Warm Handoff tool transfer the call to the endpoint’s destination, while an intent pathway only asks the endpoint whether it’s open to decide where in the script to send the caller — often to a step that then transfers, but just as often to a message-taking flow when the team is closed.

​
Fixed and Dynamic Destinations

Everywhere a script references an endpoint, the destination can be fixed or resolved per call:
  • Fixed — pick an endpoint from the picker. The picker lists endpoints by location with a live open/closed status dot, the department and destination, and a shortcut to the Numbers & Routing page. What’s saved is a reference to the endpoint, not its phone number — change the endpoint’s destination or schedule later and every script pointing at it follows automatically.
  • Dynamic — switch the picker to Use variable and supply the endpoint from a variable instead. Type / to insert one — 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 is resolved at the moment of transfer, so one script can serve many destinations.
The Warm Handoff tool’s Routing Endpoint input accepts the same two forms — a picked endpoint or a variable reference. In Live Handoff, the script-level endpoint is the default and each flow can override it (Routing Endpoint (override), which otherwise shows Inherit script endpoint) — see Live Handoff. If a referenced endpoint has since been deleted, the picker warns you: “The selected routing endpoint no longer exists. Pick another one.”

​
The Schedule Check

Every transfer is gated by the endpoint’s effective schedule. An endpoint with no schedule of its own inherits one: endpoint → department default → location default → team default. An endpoint with no schedule anywhere in that chain counts as always open at transfer time, and an endpoint whose Active toggle is off is never a transfer target at all. Times are evaluated in the schedule’s own timezone, including its public-holiday exclusions and date overrides — see Schedules. When the check runs depends on the path:
  • Live Handoff checks availability the moment the caller asks for a human. If the endpoint is closed, no offer is made — the assistant apologises with a natural out-of-hours line (for example “Sorry, none of the team are currently available right now.” — the wording varies between calls), the conversation continues, and handoff offers are suppressed for the rest of the call. If the endpoint is open, the assistant offers and confirms, and availability is checked once more when the transfer actually starts — so a caller who confirms just before closing time is still handled correctly.
  • Intent Pathways check the endpoint’s schedule once, when the trigger fires. Open selects the On schedule branch; closed selects Off schedule (or On schedule when no off branch is set). This is a read-only availability check — nothing is dialled. If the schedule can’t be evaluated, the On schedule branch is used.
  • The Warm Handoff tool checks when its step runs. If the endpoint is closed — or no endpoint is configured — the assistant speaks a built-in out-of-hours line, the step exits on its failure route, and the conversation continues with the AI.
If the schedule data can’t be read at all, transfers fail open: the primary endpoint is dialled rather than the caller being stranded by a lookup problem.

​
What the Caller Experiences

Once a transfer is cleared to go, the endpoint’s destination is dialled — the Warm Handoff tool page covers every input and message in detail. In brief:
  1. An optional Handoff Initiated Message tells the caller what’s happening.
  2. The caller hears your chosen hold music while the destination is dialled.
  3. If the human’s line goes to voicemail, the handoff is treated as failed — the assistant never briefs an answering machine.
  4. In warm mode the assistant privately briefs the team member with a summary of the call (optionally waiting for them to speak first), then merges the two calls and speaks the merge message before going silent. In cold mode the call is transferred immediately without a briefing.
  5. On success the script pauses permanently — the humans take it from here. On failure the assistant speaks the failure message and the conversation continues.

​
Fallbacks

An endpoint can carry a fallback endpoint, forming a chain. When a transfer targets a closed endpoint, the platform walks the chain in order — up to five hops — and dials the first endpoint that is open; loops are detected and stopped. The resolution record notes how many fallback hops were taken. If nothing in the chain is open, the transfer does not start: the caller hears the out-of-hours line and the conversation continues on the failure path, exactly as for a single closed endpoint. A broken endpoint — one whose destination can no longer be dialled, such as a removed team member or a missing number — is flagged in the endpoint picker and on the routing Overview dashboard; a transfer that reaches one fails and follows the same failure path. Fallback chains are not yet configurable in the endpoint form. Speak to the Voxworks team for further custom configuration.

​
Resolution Records

Every transfer that is acted on leaves an audit row. The row is written once the transfer concludes — merged or failed — and records:
  • the endpoint that was resolved, and the schedule that applied
  • the destination that was dialled
  • whether the endpoint was open
  • the fallback depth (0 means the primary endpoint took the call)
  • the call it belongs to, and the location and department the request routed through
Read-only availability checks don’t write rows — an intent pathway picking its branch, or a handoff offer that the caller declines, never appears in the log. And the audit is deliberately non-blocking: a logging problem can never stop a transfer. You’ll see these records in two places under Numbers & Routing:
  • The Overview tab summarises them — Calls routed · 7d, Transferred to endpoint, and Open now stats, a calls-by-location-and-department heatmap, and a Recent resolutions list showing the requested route, resolved destination, and when.
  • The full log, with per-row status, destination, depth, and CSV export, is covered on the Audit log page — currently in beta, available to selected invites only.

​
Custom Routing at the Engine Level

Beyond the three standard paths, Live Handoff and Intent Pathways can each be pointed at a location + department instead of a specific endpoint — the platform picks the highest-priority active endpoint that matches. This isn’t configurable in the app today; it’s set up directly by the Voxworks team. Speak to the Voxworks team for further custom configuration.

​
Next Steps

  • Endpoints — Configure the destinations, priorities, and schedules transfers resolve against
  • Live Handoff — The script-wide “can I speak to a human?” safety net
  • Warm Handoff — Every input and message on the transfer tool itself
  • Audit log — The full resolution log for every routed transfer