TL;DR: A phone menu makes the caller do the routing. It asks a person who is describing a problem to first translate that problem into your org chart, then press a number for it. A voice agent inverts that: the caller says the thing in their own words and the routing happens on your side, invisibly. That is the whole difference, and it is bigger than it sounds, because the menu was never really telling you what people wanted. The keypad still wins for identifiers, noisy lines and anything that must be deterministic, so the right build is usually not a replacement, it is speech on the front with DTMF kept underneath. Do not port your existing menu tree into a prompt. The tree is the artefact you are trying to get rid of.
Every business I have taken a voice agent live for already had something answering the phone. Sometimes it was voicemail. More often it was a menu: press 1 for sales, press 2 for accounts, press 3 for everything else, and a loop back to the top when nobody pressed anything. The menu is the thing the agent is actually replacing, and almost nobody talks about it, because the interesting comparison in this space is always agent versus human. Agent versus keypad is the comparison most clients are really making.
I have built production agents for UK hospitals, vet clinics, estate agents and car garages at Fortell AI, and for a US product at Tested Media where calls land in GoHighLevel. In nearly all of them there was a menu in the way first. Here is what actually changes when it goes, what should stay, and the migration mistake I see most.
A menu asks the caller to be the router
An IVR is your internal structure, read out loud, at the worst possible moment. The caller has a problem in their head, phrased the way they would phrase it to a person, and the menu asks them to map it onto departments whose boundaries they do not know. Is a payment I was charged twice a sales question or an accounts question? Is my dog eating something he should not have an appointment or an emergency? The caller guesses.
Two things follow from that guess. The first is misrouting, which you pay for twice, once in the caller's time and once in the transfer. The second is that a large share of callers stop guessing and press 0, or press nothing, or press the first option because it came first. Every menu I have seen the data behind has one option carrying far more traffic than the business expected, and it is nearly always option one.
A voice agent removes the translation step. The caller says "I think I was charged twice last month" and the routing decision happens behind the call, against a map you control, in language you can change on a Tuesday afternoon without re-recording anything. The caller never learns your org chart, which is the correct outcome, because it was never their job to.
The menu was hiding your call data
This is the part clients underestimate. A phone menu produces one data point per call: which key was pressed. That is not what the caller wanted, it is what the caller settled for, and the two differ in a way no report will ever show you.
An agent produces the actual request, in the caller's words, on every call. The first month of transcripts on almost every build has turned up at least one high volume request nobody mentioned during scoping. At a garage it was people ringing to ask whether their car was ready, which was never a menu option anywhere. At a clinic it was callers trying to change an appointment they had already changed once.
That is the argument I make when someone tells me their menu is fine. The menu is not fine, it is silent. It cannot tell you what it is failing at, because it only records the compromise. Once the numbers you report are per intent rather than per keypress, the picture usually redraws the roadmap.
Where press 1 still genuinely wins
I am not selling the idea that the keypad is dead. There are four places it is still the better mechanism, and I keep all four.
Identifiers. Account numbers, booking references, postcodes and card digits do not survive speech recognition reliably, and accents make it worse in a very specific way: the failures cluster on identifiers rather than on conversation. Eight digits typed are eight digits. Eight digits spoken are a confirmation loop. Ask for them on the keypad and stop fighting it.
Noise. A caller standing next to a lift, in a workshop, or on a motorway can press a key when the agent cannot hear a word. Any branch that must complete under bad conditions deserves a DTMF path, and background noise attacks the turn taking layer first, long before it attacks comprehension.
Determinism where it matters. Anything with a legal or safety consequence should not depend on a language model classifying a sentence. If a caller must confirm consent, opt out, or reach an urgent line, a key press is an unambiguous event with a timestamp.
Repeat callers with muscle memory. Your highest frequency callers have already memorised 2 then 1 then 4 and they mash it through the greeting. Taking that away is a downgrade for the people who ring you most. Accept the digits anyway, even while the agent is speaking, and route them straight through.
Do not port the tree into the prompt
The most common migration mistake is treating the menu as the specification. Someone sends me the IVR script and asks for an agent that does exactly that, in a nicer voice. What you get is a menu with extra latency: an agent that says "I can help with sales, accounts or support, which is it?" and then behaves like a tree anyway.
The menu is not a specification, it is a compromise made with a constrained input device. Build from what people say, not from your departments. This is the same principle that makes a hospital switchboard a routing problem built from caller language rather than the org chart, and it applies to a six person garage just as much.
The practical version: take fifty recent calls, write down each caller's opening sentence verbatim, and cluster those sentences. That cluster list is your real intent map. Your menu options will appear in it, usually fewer of them than you expected, plus two or three things that were never on the menu and account for a surprising amount of volume.
Then pick the destination for each cluster, and keep the existing extension list. That part of the old system is real work already done and worth preserving: the numbers, the hours, the after hours branch, who covers what on a Saturday.
The failure modes swap, they do not disappear
A menu fails by looping. No input, repeat the options, no input, repeat, then hang up or dump to voicemail. Callers know this loop and they hate it.
An agent's equivalent failure is the clarification loop: it did not catch the request, asks again, still does not catch it, asks again in slightly different words. It is worse than the menu loop because it sounds like it is nearly working, so the caller keeps trying.
The fix is a hard cap. Two failed attempts to understand, or two consecutive no inputs, and the call goes to a person or takes a callback, with the agent saying plainly that it is doing so. Never a third attempt. That sits alongside the rest of the escalation design, and the cap matters more than the wording of the retries.
One more thing the menu gave you for free: instant interruption. Pressing 4 over the greeting cut it off immediately. An agent has to earn that with barge in that actually works, and if it does not, every caller who used to skip the menu now waits through a sentence. That is a real regression to test for before go live, not a detail.
The cost shape is different, not just the number
A menu is a flat cost. It deflects calls at zero marginal price whether it deflects them well or badly, which is exactly why bad menus survive for years.
An agent costs per minute of conversation, so a call it handles well is a call you paid for. The economics still work comfortably, and I have written the full cost breakdown I quote from separately, but the shape of the decision changes: with a menu you optimise for deflection, with an agent you optimise for resolution. Those pull in opposite directions. A menu that dumps 60 percent of callers into voicemail looks cheap and is losing you work. An agent that resolves 60 percent of calls costs real money per call and is the better buy.
How I would migrate, in order
- Export the menu's own numbers first, so you have a before. Volume per option, abandon rate, how many callers press 0.
- Cluster fifty real opening sentences into an intent map, ignoring the current tree.
- Build the agent for the top three intents only. Everything else escalates to a human from day one.
- Keep DTMF underneath: digits for identifiers, a key for the urgent branch, and 0 for a person, accepted at any point in the call.
- Put the agent on the overflow or after hours line first, not the main number, and watch whole calls for the first two weeks.
- Compare like for like: resolution rate against the menu's abandon rate, not against a demo.
- Add the fourth and fifth intents from what the transcripts show, which will not be what you predicted.
The menu was a workaround for the keypad being the only input a phone had. That constraint is gone. What survives is the part of the menu that was never about input at all: knowing where a call should end up, and making sure it gets there. Build that from how people actually ask, keep the keypad for the things fingers do better than voices, and cap the failure loops so nobody is ever stuck talking to something that is not listening.
I build production AI voice agents and the telephony, automation and CRM layer behind them for founders across the US, UK and Europe, including the migrations where half the old phone system was worth keeping. More about my work here, or book a call.