Phone routing and fallback

Define the complete call path: what answers first, who can help next, and what happens when nobody is available. Capabilities depend on the company’s phone setup and qualified route.

Start with the answering policy

Configure the business number and publish its intended flow. Supported phone policies can include a keypress menu, ringing team members, an AI agent, a spoken message, or voicemail. Do not assume every route or managed offer supports the same set of steps.

1. Choose the company timezone and open/closed hours.
2. Decide whether the team or AI should answer first.
3. Configure the supported waiting, transfer, or message path at capacity.
4. Give unanswered calls and service errors a clear recorded next step.

Check transfer prerequisites

Configure eligible recipients and publish the agent’s permitted destinations. Team availability, a live carrier leg, and the handoff service all matter. A transfer request is not a completed handoff: human acceptance and a carrier bridge are the completion evidence.

GET /v1/calls/{call_id}/handoff-readiness returns live-call prerequisites and blockers. It requires calls:read, calls:control, and reps:read together. It does not initiate a transfer or guarantee a recipient will answer. An unavailable or expired call can return active: false; historical call existence does not prove a live carrier connection exists.

For a phone-team queue, the published flow must select recipients or queues and the relevant agent. Queue and callback execution services must be enabled; callback availability also depends on the flow’s callback option and the agent’s queue-status capability. See agent readiness.

Waiting and callbacks

Use the queue’s returned state for position announcements. Do not invent a wait time from a general model response. A caller choosing a callback creates the supported saved request; it is not proof the return call has happened.

Configure the fallback that applies when queue or transfer prerequisites are unavailable. A useful recorded message and consented voicemail path can still capture the caller’s request without starting a conversational AI session.

Closed hours and metering

A configured prerecorded closed-hours flow can play a message and collect consented voicemail without opening an AI conversation. Supported waiting, menus, ringing, and human-call time are separate from AI session time.

Under BYO service, Twilio bills the company’s carrier and number charges directly. Published managed Receptionist terms distinguish included or excess AI time, non-AI incoming time, and a connected eligible transfer leg. The accepted offer determines the actual billing treatment; an AI minute must not also be counted as non-AI incoming time.

Review the phone billing guide for the exact rates and restrictions. Public supplied-number acquisition and managed outbound activation are not opened merely by publishing those offers.

Verify the actual route

Before advertising a number, test an open-hours call, a closed-hours call, an AI-capacity fallback, a human answer, an unanswered transfer, voicemail, and immediate redial after hanging up. Confirm the saved call and request records.

An incoming route working does not establish outbound qualification. Review the production checklist separately for each direction.