Quick answer: Yes — you can replace a classic press-and-listen IVR menu with an AI voice agent without breaking your callers, but only if you do it in phases and measure containment at every step. Catalog what your menu actually resolves (call recordings and transcripts), run an AI pilot as a shadow option behind the existing menu, move the top intents across first, and keep the DTMF path as the deep fallback until the agent's contained-call share is provably better. The migration succeeds on cataloging, not on model quality.
A DTMF menu tree worked when callers had no choice. Today most callers know what they want before they dial, and a menu that asks them to press 1 for billing and 2 for hours is a tax on their patience — every navigation step is a chance to press 0, hang up, or misroute. An AI voice agent skips the menu entirely: it listens to "I want to change my appointment" and routes or resolves on the first utterance. This guide walks the migration arc — why containment degrades on menus, how to phase the cutover, what to catalog first, which shipped hooks to use, and what to watch so your callers never notice the change except that it got faster.
Why classic DTMF IVR degrades containment
Containment — the share of calls your automated system resolves without a human — is the metric every migration should be graded on. A DTMF menu has a structural ceiling: the caller has to already know which bucket their need falls into, and every menu layer multiplies abandonment, misrouting, and zero-for-agent escapes. The failure modes are consistent:
- Menu drift. Real call reasons drift faster than the tree gets edited. The menu says billing, hours, and appointments; callers are asking about the outage, the refund policy that changed last quarter, and the thing marketing just launched.
- Deep trees shed callers. Each layer of "press 3, then press 2" is another abandonment point. Callers who reach the end after four layers arrive at the agent more frustrated than they started.
- Misroutes compound. An ambiguous press-1 guess sends the caller to the wrong queue, where the human agent has to cold-transfer them — one wrong keypress becomes two touchpoints and an annoyed customer.
- No speech path, no path forward. A pure DTMF menu cannot accept "I need to reschedule" — every intent the tree never anticipated becomes an operator call.
An AI voice agent closes that gap by listening instead of presenting options: callers who used to opt out of a rigid menu to reach a person now get the first conversation carried by the voice layer itself, and only the escalations reach a human. Orbit's AI voice agents run listening → reasoning → speaking on a fully streamed path against a published ~1.1-second-per-turn latency target (methodology on the latency benchmark page), so the natural-language front end does not pay the price in awkward pauses that would give callers a reason to abandon mid-call.
Note the operating promise: containment improves only if the agent actually resolves the calls your menu used to misroute or shed. Measure contained-call share — not model demos — as the migration gate.
Catalog before you migrate: intents, routing map, escalation contract
The phase before touching a call flow is the one most teams skip, and it is the one that decides whether the migration works. The goal is an honest map of what your current IVR actually handles — not what the menu designer intended, but what callers say, where they end up, and what a human could do about it.
Call the call recordings and transcripts first. Most IVR platforms record every leg; pull the last 60–90 days and read what callers actually asked for. Group the transcripts into intents — billing inquiry, hours lookup, appointment scheduling, payment status, outage report, and so on — and rank by frequency. The top five or ten intents are the pilot list; anything rarer stays on the menu until later. If you skip this step, you will deploy an agent great at "hours and locations" while your callers actually phoned about refunds.
Map every menu node to an outcome. For each node in the DTMF tree, write down where it goes — a queue, a voicemail, an announcement, an agent, a hang-up — and which queue, which hold policy, which wrap-up code. That map is your routing contract for the AI pilot: the agent must route to the same queues with the same semantics, or containment numbers across systems will not be comparable.
Lock the escalation contract. Before any live traffic touches the agent, decide what "hand off to a human" means: which queue, which skills filter, what context the agent passes, and what the human should see on screen — a call summary and the caller's verified intent vs. just "AI transfer." This is a tenant-controlled routing rule in Orbit's contact center, and pinning it before the pilot keeps handoffs from becoming a second migration.
The output of the catalog is a prioritised intent list, a route-per-intent map, and a handoff contract agreed by the operations owner. Everything afterwards is a phased rollout against that checklist.
Phase the migration: shadow, top-intents, sunset
The migration has three gates. Each one produces evidence before it earns more traffic.
- Shadow the agent behind the menu. Keep the existing DTMF menu live and add the AI agent as a new option — "describe what you need in a few words" — while pressing 1–9 still works. Run it on real traffic for at least two weeks. This gives you side-by-side containment: the menu keeps its baseline and the agent earns its scoreboard. On Orbit the same visual IVR builder and the AI voice agent live on one call path and one queue, so the menu and the agent can coexist rather than requiring a forklift.
- Shift the top intents first. When the pilot data shows the agent resolves the top intents at least as well as the menu, promote it to the front of the call flow for those intents. "For billing, hours, and appointments, describe your need" — and let everything else fall through to the menu. Order matters: top-intent-first maximizes contained calls while minimizing the blast radius; moving a rare intent first buys you little and risks the unknown.
- Sunset the menu one branch at a time. As each intent clears its gate, retire the corresponding menu branch so callers no longer navigate it. Keep the DTMF fallback deep in the flow — some callers prefer keypresses, regulators often require a non-AI escape path, and an outage on the AI path should degrade to a menu, not a hang-up. The menu never fully disappears; it shrinks to the long tail.
Each gate is graded on contained-call share and handoff context quality, not on model demos or marketing checklists. If the agent's containment on an intent is worse, the menu branch stays live for that intent — the phases are evidence-driven, not date-driven.
Which shipped Orbit hooks to use
Orbit ships the migration plumbing as product, not as a consulting project. The hooks used in a menu→agent migration map to shipped capabilities:
- AI voice agents. The no-code agent builder with API access on the fully streamed AI voice agents path — the pilot that shadows the menu and the eventual destination for top intents.
- Visual IVR builder. The same drag-and-drop menu canvas hosts the DTMF fallback, the shadow option, and whatever long-tail menu branches survive after the agent takes the top intents — one flow, not two systems.
- Contact center. Escalations land in the same contact center your human agents already work in, ACD skills-based queues, SLA targets, and wrap-up codes included — the escalation contract is a routing rule, not a bolt-on.
- SMS / WhatsApp fallback. A caller the agent cannot resolve — or a noisy mobile line that forces a DTMF escape — can be guided to messaging (SMS, WhatsApp, email) on the same account, so the fallback is a channel shift rather than a lost call.
- Programmable voice and SIP trunking. Bring-your-own-carrier SIP keeps numbers and carrier while layering the new flow on top; the programmable voice API lets developers author the same flow in code when the visual canvas is too coarse.
The migration succeeds when each of those hooks does the phase's job — agent for the intent, builder for the fallback, contact center for the handoff, messaging for the channel shift — without inventing new infrastructure.
Frequently asked questions
Do I have to rip out my existing IVR to use an AI voice agent?
No. The migration pattern that works is to run the AI agent as a new menu option alongside the existing DTMF tree, then let the top intents gravitate to the agent while the menu keeps the long tail. On Orbit the visual IVR builder and the AI voice agent share one call path and one queue, so a shadow pilot does not require replacing anything — it requires adding an option and measuring it.
How do I know which intents to migrate first?
Rank by what callers actually say, not by what the menu designer intended. Pull the last 60–90 days of call recordings and transcripts, group them into intents, and order by frequency — those top intents are the pilot list. Reading real transcripts is the cheapest way to avoid an agent that is brilliant at "hours and locations" while your callers actually phoned about refunds.
What does "containment" mean and how do I measure it?
Containment is the share of calls your automated system resolves without handing to a human. Measure it as contained-call share per intent per flow: for each intent the agent handles, what fraction of matching calls end resolved by the agent vs. escalate or abandon. Grade each migration gate on that number, side by side with the menu, and never promote an intent until the agent's number is at least the menu's.
Should the DTMF menu ever fully disappear?
No. Keep the DTMF path as the deep fallback even after the agent handles the top intents: some callers prefer keypresses, some regulatory contexts require a non-AI escape path, and an AI-path outage should degrade to a menu rather than a hang-up. The menu shrinks to the long tail; it does not vanish.
What happens when the AI agent reaches its limit?
The caller escalates into the contact center the same way a menu escalation would — but warm. The agent hands off into the same ACD queues your human agents already work in, with a call summary and the verified intent attached, so the specialist starts with context instead of "how can I help you." The fallback contract — which queue, which skills filter, what context — is pinned before the pilot goes live.
Can I keep my phone numbers and carrier while migrating?
Yes. Orbit supports SIP trunk bring-your-own-carrier: point your existing trunk at Orbit, keep your numbers, and layer the AI agent and the new flow on top without migrating your carrier. If you do migrate termination onto Orbit, calls route on Devotel's own wholesale softswitch across 500+ carriers — the same carrier-of-record path the IVR product already uses.
Where to go next
The phased playbook above generalises cleanly: catalog, shadow, top-intents, sunset. If you are on RingCentral's per-seat phone plans with the AI receptionist as a separately-quoted add-on, the same three gates work — the only difference is that on Orbit the visual IVR builder, the AI voice agent, and the contact center are one platform on one pay-as-you-go bill, so the migration is a routing project, not a vendor replacement.
- Read the IVR product overview for the visual builder, DTMF + spoken-intent menus, and AI agent handoff.
- See the Orbit vs RingCentral comparison for the commercial and capability contrast.
- Compare the automated-answering field in the best automated answering services 2026 guide.
- Extend the migrated agent to messaging with WhatsApp AI agents: voice and messaging on one platform — one agent that answers WhatsApp chats and takes calls with the customer history intact across both.
- Check pricing — one pay-as-you-go bill across the voice agent, the menu, the queues, and messaging. For the all-in cost model behind that bill — the four per-minute components and the cost-per-resolved-conversation ROI framework a migration business case is graded on — see AI voice agent pricing in 2026.
Published 24 August 2026.