Quick answer: A first IVR on Devotel Orbit is five ordered pieces — record the greeting, map the menu digits to destinations, wire the no-input and wrong-digit fallback, point the tree at terminals (a queue, a ring group, voicemail, or an announcement), then add the measurement layer a bare menu never has: post-call CSAT/NPS digit capture, per-call sentiment analytics, and a horizontal ring-all leg that calls every agent in the team at once. The tree itself lives on the Visual Flow canvas under Voice → IVR Builder, and the published tools (IVR intents, the publish guardrail, and the route-first decision guide) decide whether a call even needs a scripted menu.
This walkthrough is for teams standing up their first inbound tree — a migration off a legacy provider's menu, a replacement for an answering machine, or the first front door a growing support line has ever had. It names the parts in the order you build them, the route example they combine into, and the limits of the scripted-tree shape so you do not build past what a fixed menu can express.
How to build your first IVR in five steps
Step 1: Decide that the call belongs on a scripted menu at all
A scripted IVR wins when the answer is fixed and pre-recordable — your hours, your location, a payment status readback, a department transfer. It loses when callers arrive with natural language or unclear categories. The IVR vs AI voice agents vs human handoff routing guide grades the split call type by call type, and the six families of AI voice agents names scripted IVR as the non-AI baseline you route out of — not every inbound call should touch one. Read the decision table first; building the tree second is cheaper than rebuilding it.
Step 2: Record the greeting — the part callers judge
The greeting is the first audio a caller hears and the one piece of an IVR a bad recording cannot hide behind. In the IVR Builder the greeting node takes either text (synthesized at publish) or a hosted HTTPS audio URL for a pre-recorded file. Write it to the length of a breath: who the caller reached, what the menu offers, nothing else. A greeting that runs past about fifteen seconds gets skipped by the digit the caller was already pressing. Every node lives on the canvas the IVR Builder renders as one graph — the flow source of truth.
Step 3: Map the menu — digits to destinations
A menu node declares which DTMF digits branch where. Keep three rules and the tree stays navigable:
- One layer at a time. A first menu should offer two to five options; a caller who hears nine presses the one labeled "everything else" or hangs up.
- Digits are destinations, not topics. Press 1 should reach support, not announce what support covers. The announcement-only branches belong at the leaf, not at the trunk.
- Say the digit before the destination. "For support, press 1" trains callers to wait; "press 1 for support" lets them act while the sentence runs.
The canvas validates the structure on publish — one Start node and every branch ending on a terminal — so a menu that strands a digit or leaves a branch dangling cannot go live with that shape.
Step 4: Wire the fallback logic — the part that saves the call
Fallback logic answers the two failure modes every fixed menu meets: the caller presses nothing, and the caller presses a digit that is not on the menu. The default for both routes to a capture — voicemail or a callback offer — not a dead end. An unmatched input needs a designated owner, or the call drops on the floor. The no-input timeout and the invalid-digit path both terminate on the same destination your "everything else" digit reaches — that is the fallback, and it is a node on the canvas, not an implicit behavior.
Step 5: Point the tree at terminals and light up the measurement layer
A branch is done when it ends on a terminal a caller can reach. On Orbit the terminals are queue members, ring groups, voicemail, announcements, and the callback offer — the same destination set the contact center answers on. With the tree live, three measurement layers separate an Orbit IVR from a bare menu:
- Post-call CSAT / NPS digit capture — the survey plays inside the ended call and records a 1–5 or 0–10 score on the keypad, with sampling and a disposition gate deciding which calls hear it. Author it under Voice → Post-call CSAT or Voice → Post-call NPS; the post-call surveys explainer walks the whole config.
- Sentiment analytics — the recorded-conversation roll-up at
/insights/sentimentscores conversation sentiment into a trend with by-channel and by-agent breakdowns, so menu branches carry a quality read (positive minus negative over labeled conversations) instead of a raw call count. - Horizontal ring-all handling — a menu branch names its destination as a ring group, and a ring group rings every member's device at once (the whole team, not a forward-through sequence). First answer takes the call; nobody queues behind a busy colleague.
A worked three-level route you can copy
A first tree stays small enough to draw on a napkin. The example below is three levels deep, each level named, and it is the whole walkthrough compressed into one shape:
- Level 1 — trunk. The greeting plays ("Thanks for calling — pick a department"). The menu offers press 1 for support, press 2 for sales, press 9 for everything else. The fallback routes no input within the timeout (and a wrong digit) to the same "everything else" node as digit 9.
- Level 2 — branch. Press 1 lands on a sub-menu: press 1 for the order-status announcement (plays the readback), press 2 to reach the support queue, press 0 to return to the trunk. Press 2 from the trunk lands on the sales ring group — a horizontal ring-all leg where every sales device rings at once and the first agent to answer owns the call.
- Level 3 — leaf. Terminals end each branch: the support queue, the sales ring group, and the "everything else" fallback on voicemail capture with a thank-you announcement before the recording starts.
That is the full shape. Three levels, every digit spoken before its destination, one fallback owner for the two failure modes, terminals that are teams and not phones.
The limits: what a scripted tree cannot do
Two limits matter more than any feature list. The first: a fixed menu is a fixed menu. It does not accept natural language, it does not resolve intents it did not pre-record, and the deepest branches shed callers when the category is complicated. When the inbound pattern is "callers explain a shape, not a digit," the routing guide above points at the AI-agent or human-escalation branch instead — same dashboard, same bill — and a scripted tree carries only the traffic a pre-recorded answer can honestly serve. The second: no claim in this walkthrough extends past the shipped builder. The canvas renders the tree as a graph and validates the structure on publish; flows that depend on live provider-side behavior stay out of scope for a menu, and out of this post's claims.
What the end-to-end run buys you
The runbook to a live IVR is dashboard work: record the greeting, map the menu, wire the fallback, point the tree, layer the measurement. No PBX, no SIP config-by-hand, no integration project between "open the account" and "the menu answers." The tree lives next to post-call surveys, sentiment, and ring-all legs, which makes it an inbound front door that measures itself rather than a recorded menu.
Frequently asked questions
Do I need a live flow to record the greeting?
No — the greeting can be plain text (synthesized at publish) or a hosted HTTPS audio URL you upload yourself. The canvas takes either; a first tree often starts on text and swaps in a recorded file once the copy settles.
What does the fallback do when a caller presses nothing?
The no-input node fires after the digit timeout you set, and the invalid-digit node fires after a wrong keypress. Both should route to the same capture — voicemail, a callback offer, or an "everything else" branch — rather than ending the call.
Where do the post-call CSAT/NPS scores land?
The digit scores from the in-call survey feed the survey's own analytics, and the sentiment roll-up at /insights/sentiment adds a quality trend on the recorded conversations. Together they turn "the menu answered" into "the menu answered, and here is how it went."
Can I migrate a tree I built on another provider?
Yes — the five-step rebuild is deliberately a migration shape. Map the old tree's levels onto the canvas, re-record the greeting, re-map the digits, and wire the fallback before pointing terminals. The OpenPhone migration runbook shows the same move end to end.
When should a branch stop being a menu and become an AI agent?
When callers start describing a problem instead of pressing a digit. The IVR vs AI voice agents routing guide has a row for that shape — "I don't know what I want, explain my options" — and it routes to the agent, not the tree. A scripted menu owns the fixed answers and hands everything else off.