Quick answer: A good IVR is shallow, explicit, and failover-complete. Keep menus to one or two levels with at most four or five branches per level — every extra level multiplies misroutes and caller handling time. Write DTMF prompts for keypad answers and speech prompts for natural answers; never reuse one script for both. Draw overflow, out-of-hours, and carrier-failover edges on every route before it ships, not after the first incident. Place the recording-consent prompt before the first recorded leg, not buried after the menu. And if "press 1 to connect" is your anti-screening gate, design it so Apple's Live Voicemail screening still passes the call through — the iOS call screening post covers that change. Every pattern below maps to a node or surface in the Orbit flow builder at Voice → IVR Builder (`/voice/ivr-builder`) and the Flows workspace (`/flows`), so each design rule has a concrete place to implement it.
1. Shallow and explicit menus beat deep trees — the handling-time math
A menu's cost is measured in seconds and misroutes. Every level of a menu tree adds a prompt the caller must listen to (five to ten seconds), a decision, and a chance of a wrong digit. A three-level tree with a six-second prompt per level spends 18 to 30 seconds on navigation before the queue even starts ringing; a two-level tree spends 12 to 15. Callers abandon in that gap, and the ones who stay misroute at each layer — deep trees trade containment for abandonment.
The design rules that survive contact with real traffic:
- Two levels max, four to five branches each. Twenty to twenty-five reachable leaves from two explicit layers beats five from three buried ones. Anything deeper is a second IVR, not part of this one.
- The most-called branch goes first. Callers hear prompts in order; branch one being the 60%-of-traffic intent is the single largest listening-time saving you can make.
- Every branch names where it ends before it asks for input. "For billing, press 2" taught in that order survives; "Press 2. [pause] For billing" gets callers pressing anything.
- A wrong digit re-prompts once, then falls through to capture. The third invalid input should route to a human or voicemail, not replay the menu a third time.
Where this lives in Orbit: each menu level is a menu node on the IVR Builder canvas; the re-prompt-once rule is a no-input or invalid edge you draw to a capture terminal, and the publish guardrail refuses to ship a route whose branches do not all end on a terminal — the shallow-tree discipline is enforced at publish time, not reviewed after.
2. Prompt wording per capture mode — DTMF versus speech
DTMF and speech collection answer different questions, and a prompt written for one fails on the other.
DTMF prompts ask for a digit. The caller's job is to press a key, so the prompt must name the key and the destination in that order: "For billing, press 2." Keep the digit set closed (1 through 4, not 1 through 9 with gaps), say each digit's destination once, and end the prompt. Long DTMF prompts get barge-in cuts; the destination must survive the caller interrupting.
Speech prompts ask for a sentence. The caller's job is to describe their need, so the prompt invites exactly that: "Tell me what you're calling about — say billing, appointments, or anything else." Do not say "press or say" — the dual-mode prompt collects worse on both modes, because keypad-callers hesitate and speech-callers guess the keywords backward. Where a speech node fronts a digit-menu backup (the NLU-routing explainer's front-door pattern), the speech prompt runs first and the digit menu is the fallback wording, never a merged sentence.
On the Orbit canvas these are two distinct node types — a DTMF-input node collects digits with timeout and finish-key settings, a speech-input node collects the utterance for the intent layer — and the localized prompt variants on each mean the wording discipline holds across languages, not just in the English baseline.
3. Failover branches — overflow, out-of-hours, and SIP failover
A route with no failure edges is a route that fails blind. Three failover classes belong on every production route, and all three match surfaces Orbit already ships:
- Queue overflow. A queue node's overflow destination fires when the max-wait cap or queue limit trips. Point it at a callback offer during staffed hours and voicemail outside them; the queue drops no caller. A live-queue position announcement plus a callback offer converts most would-be abandonments.
- Out-of-hours. A time-check node splits the route on business hours and the caller's timezone; the after-hours edge goes to voicemail with an email-notification address, or to the after-hours AI-agent leg if you run one. What it must never do: replay the daytime menu to a caller who cannot reach the daytime queue.
- Carrier failover. Test failover branches the way the sandbox feet-on-the-ground environment expects you to — the sandbox re-routes calls on the same builder logic you publish to production, so an overflow or time-check you validated there runs the same edge live. The Flows executions surface then shows each branch's failure path in production, which is the difference between a failover you drew and a failover you verified.
4. Recording-consent prompt placement
Recording consent fails in two placements: too late (the first recorded leg already carried speech the caller did not consent to) and absent (recorder on, no prompt anywhere). The placement rule: the consent announcement plays before the first node that can persist audio, which for most flows means at the front of the route — before the queue leg and before any AI-agent leg, both of which record once reached.
The tenant-owned control sits in the dashboard: set the announcement under Settings → Voice, and the per-call consent ledger and withdrawal surface lives at Settings → Compliance → Recording Consent. Two design notes that make the prompt survivable: play it as its own early prompt rather than appended to the greeting (appended, it gets lost in barge-in), and if the policy to record is per-tenant, gate the prompt on the same setting so the caller hears it exactly when the call will actually be recorded — a blanket "may be recorded" on a flow whose recorder is off is a small but real misstatement.
5. AMD-safe "press 1" design that survives iOS screening
Outbound teams use a "press 1 to connect" gate to keep answering machines and screened calls out of agent time. Since iOS 26, Live Voicemail screening plays that gate for the callee before a human ever hears the ring — so the gate's wording and timing now decide whether the call connects at all. The design rules (detailed in the iOS call screening and Live Voicemail post):
- Front the prompt in the first seconds. The screening transcriber gives the call a short window; a gate that speaks at second six never gets answered. Speak the request immediately on answer.
- Keep the action literal and single. "To connect, press 1" survives; multiline greetings-plus-menu lose the screener and the callee sees a truncated transcription on their screen. One sentence, one digit.
- Let the AI-agent leg carry the gate. On Orbit an AMD-classified delivery routes into the gate node before the agent leg rings, so screened and human answers take different early prompts on the same published route.
6. Where each pattern lives in the Orbit flow builder
The map from the five rules above to the shipped surfaces:
- Shallow menu → menu nodes on the IVR Builder canvas, publish-guarded to end on terminals.
- DTMF vs speech prompts → the DTMF-input and speech-input node types, with localized prompt variants per node.
- Overflow and out-of-hours → the queue node's overflow destination and the time-check node's business-hours split, validated in the sandbox environment and audited under Flows → Executions.
- Recording consent → the announcement set under Settings → Voice; the consent ledger at Settings → Compliance → Recording Consent.
- AMD-safe "press 1" → the AMD gate pattern the iOS screening post details, deployed as the first node on the answered leg.
The first-IVR setup walkthrough covers the five-step first build; the IVR Builder surface post walks the canvas itself; the IVR vs AI voice agents decision guide settles what should front the route. This guide is the design discipline those walkthroughs assume.
Frequently asked questions
How many menu levels are too many? Three is the practical ceiling, and two is the goal. Each level costs a five-to-ten-second prompt and a misroute risk; at four-plus levels callers abandon at the tree, and the queue-side analytics read as demand the route never delivered.
Should one prompt serve both speech and digit callers? No. "Press or say" collects worse on both modes. Run the speech prompt first and the digit menu as its fallback wording, the front-door pattern the NLU-routing explainer describes.
Where does the recording-consent announcement go? Before the first recorded leg — effectively at the front of the route, ahead of the queue or AI-agent leg. Set it under Settings → Voice, and the per-call consent trail lands under Settings → Compliance → Recording Consent.
Does "press 1 to connect" still work against iOS screening? Yes, if the prompt speaks inside the first seconds and asks for one digit in one sentence — Live Voicemail transcribes a short gate correctly but truncates a long greeting. The iOS call screening post covers the timing window.
How do I test overflow and out-of-hours branches before production? In the sandbox environment, which runs the same builder logic as production; then confirm the branch actually fired in production under Flows → Executions. A failover branch you never fired is a hope, not a route.