Why Menus Existed at All
It is worth being fair to the phone menu, because it was not a bad idea. It was a good solution to a real constraint, and understanding that constraint is what tells you whether it still applies to you.
In the era of physical lines, answering capacity was scarce. A business had a fixed number of lines and a fixed number of people who could pick them up. If eight people rang at once and you had three lines, five heard an engaged tone. In that world, sorting callers into buckets before a human touched them was genuinely efficient — it meant the scarce resource was spent on the right conversation.
The constraint has gone, and the response to it has not
On a cloud platform there is no fixed line count. Ten simultaneous callers can all be answered on the first ring. Answering is no longer the scarce thing — attention is. But the menu was designed to ration answering, so it goes on rationing a resource that is now effectively free, while consuming the one that is not. That is the whole argument in two sentences, and everything below is detail.
The second reason menus persisted is more mundane: until very recently the only alternative was a person, and a person is expensive and unavailable at 9pm. A menu was the only thing that scaled. That is no longer true either.
The Four Things That Break
These are structural rather than cosmetic. You cannot fix them by re-recording the greeting or reordering the options, which is why menu improvement projects deliver so little.
| Failure | What it looks like | Why a better menu does not fix it |
|---|---|---|
| 1. It asks the caller to do your filing | Options are named after your departments. The caller has to work out which internal team owns their problem | Callers do not know your structure and should not have to. They are not ringing "accounts" — they are ringing because an invoice looks wrong. No wording fixes the mismatch |
| 2. It is linear and unskippable | You must hear options one, two and three to reach four, every time, at the speed of the recording | The repeat caller who knows they want option four still waits through the whole list. Speed is capped by the medium, not by the caller |
| 3. It cannot handle the unanticipated | Anything that is not one of the five options has nowhere to go. So people press whatever seems closest | A menu can only contain what you thought of. Callers then arrive at the wrong team, who transfer them, and the wait restarts |
| 4. It collects what it cannot use | "Please enter your account number" — then a person asks for it again | This is the single most reliably infuriating thing a phone system does, and it happens because the menu and the person are not connected |
The mis-route is the expensive failure, not the wait
Everyone focuses on how long the menu takes. The larger cost is failure three: a caller who presses the closest-looking option and reaches the wrong team has now consumed two people's time and is further from an answer than when they started. That call does not appear in your reporting as a failure. It appears as two answered calls, which looks like productivity.
The Statistics Nobody Should Quote
If you search this topic you will immediately meet a set of very confident numbers. Roughly three quarters of customers are frustrated by phone menus. Two thirds abandon within ninety seconds. A third of those never ring back.
We are not going to use them, and it is worth explaining why, because it affects how you should read every other article on this subject.
| What you will find | What is actually behind it |
|---|---|
| The same percentages repeated across dozens of pages | Almost all of them are published by companies selling AI voice agents, and cite each other rather than a study |
| No named survey, sample size, year or country | Which means the figure cannot be checked, and may not describe an Australian business at all |
| Numbers that are suspiciously round and suspiciously convenient | They are being used as marketing, and they are aimed at you |
We are arguing against menus and we still will not use those numbers
It would be easy and effective to quote them. The reason not to is simple: if the case against phone menus depended on unverifiable statistics, it would be a weak case. It does not. The structural argument above stands on its own, and the figures that matter for your decision are the ones from your own system — which are far more persuasive to a sceptical colleague than anything from a vendor blog, including this one.
Where verifiable Australian data does exist, it is worth having. ACXPA's 2026 self-reported figures put Australian voice abandonment at an average of 9% and a median of 5% — a gap indicating that a minority of operations with very poor abandonment are dragging the average well above typical. On speed of answer, ACXPA's 2026 Best Practice Report showed enormous sector variation, with utilities slowest at a 227-second average and banking and finance carrying the highest median at 79 seconds. And on resolution, ACXPA's Australian Call Centre Rankings put banking at roughly 32% first contact resolution in the first quarter of 2026. None of those are menu statistics — but they tell you what the surrounding reality looks like.
Measuring Your Own Menu Instead
Four numbers, all of which a current platform can produce, and which together tell you exactly what your menu is costing you. If your provider cannot produce them, that is itself worth knowing.
1. Drop-off per node
How many callers hang up while the menu is playing, broken down by which prompt they were hearing. This is the single most damning number available and almost nobody has ever looked at it.
2. Zero-out rate
The share of callers who bail out to an operator rather than choosing an option. A high rate means your menu is not a routing tool, it is an obstacle people have learned to route around.
3. Mis-route rate
Calls transferred within the first sixty seconds of being answered. Those are people who picked the wrong option — which means the menu actively sent them the wrong way.
4. Time to first human word
From answer to an actual person speaking. Time the recording with a stopwatch if you have to. Most businesses are surprised, and a few are appalled.
Then do the thing nobody does
Ring your own main number from an outside mobile, as a customer, at 9am on a Monday. Time it. Take the path a confused first-time caller would take. This costs nothing, takes four minutes, and has changed more minds than any report — because the experience of sitting through your own menu is qualitatively different from reading about it.
What Actually Replaces It
The replacement is not a shorter menu or a smarter tree. It is a different interaction model entirely.
| Menu | Conversational answering | |
|---|---|---|
| Opening question | "Please listen carefully to the following five options" | "What can I help you with?" |
| Who does the translating | The caller, into your org chart | The system, into your routing |
| Unanticipated request | Nowhere to go. Press whatever is closest | Understood, then answered or routed |
| Repeat caller | Same wait, every time | Says it in four words and is done |
| Simple questions (hours, address, parking) | Occupies a menu option and often a person | Answered outright. The call ends satisfied without touching anyone |
| Information capture | Collected, then re-asked by a human | Captured and passed through with the call |
| Ten callers at once | All hear the same recording, then queue | All answered and handled in parallel |
| Out of hours | Menu, then voicemail | Books the appointment |
The important row is the second one. A menu makes the caller do the classification work; conversational answering does it for them. Everything else follows from that inversion — and it is why this is not an incremental improvement to the same product.
One rule carries over, and it matters more than ever
Anyone who asks for a person gets one — immediately, unconditionally, without being asked to explain why. The old menu equivalent was pressing zero, and businesses that hid the zero option are exactly the ones customers complain about. Do not repeat that mistake in a new medium. Counter-intuitively, an easy exit reduces how often people take it, because being trapped is what makes people fight the system.
Six Things a Menu Structurally Cannot Do
Answer a question
A menu can only move a call. It cannot tell someone you close at four on Saturdays — the highest-volume, lowest-value question most businesses receive, and one that never needs a person at all.
Book an appointment
Checking real availability and writing into the diary is beyond a keypress tree by definition. This is where most of the measurable value of the change actually sits.
Recognise urgency
A menu treats "water is coming through the ceiling" and "I have a billing question" identically, because it cannot hear either. Conversational routing can escalate the first one immediately.
Pass context forward
A menu selection is one digit. A conversation produces the name, the address, the job, the urgency — arriving with the call so nobody asks twice.
Handle the vague
"I spoke to someone yesterday about the thing at the Newcastle site" has no keypress. It is also how people genuinely talk.
Tell you what people want
A menu reports which buttons were pressed. Transcripts report what customers actually said — which is the best product and service research your business generates, and a menu throws all of it away.
That last one is underrated. Every day people ring and tell you what confused them, what a competitor quoted, and what they could not find on your website. A keypress captures none of it. AI transcription and CRM notes covers what that data becomes once you keep it.
The Accessibility Problem Menus Create
This rarely appears in overseas guides and it matters in Australia, because it affects a category of caller who is quietly being disconnected from menus that look perfectly fine to everyone else.
Callers using the National Relay Service communicate through a relay officer, which adds substantial time to every turn of a conversation. A menu that allows the standard few seconds for a keypress does not allow enough time for a relay-mediated response.
| What the menu does | What the relay caller experiences |
|---|---|
| Plays options, waits ~5 seconds, repeats once, then disconnects | The relay officer is still conveying option two when the timeout fires. The call ends |
| Reports the call as "abandoned" | The caller did not abandon anything. They were cut off by a timer |
| Shows nothing wrong in testing | Because nobody tests through the relay service |
Two fixes, one better than the other
If you are keeping a menu: lengthen your timeouts substantially and allow repeats, and never treat a slow response as no response. If you are replacing it: conversational answering removes the timed-keypress problem at its root, because there is no countdown to fail — though the same principle applies, so make sure a pause is treated as thinking rather than as silence.
Getting Off a Menu in a Fortnight
The mistake is trying to replicate every branch of the existing tree. You are not migrating the menu — you are replacing what it was for.
| Stage | What happens | Why |
|---|---|---|
| Days 1–3 | Pull a month of data: which options were pressed, how often, and how many of those calls were transferred again within a minute | The transfers tell you which menu branches were actively wrong. Usually one or two options carry most of the mis-routes |
| Days 1–3 | Separately, tally what people actually ask for at the point a human picks up | This list rarely matches the menu. The gap between them is the whole problem, made visible |
| Days 4–5 | Write the answers to the ten most common questions, in the words you would actually say | This is the configuration. A writing job for whoever knows the business, not a technical one |
| Days 4–5 | Write the escalation rules — what is urgent, who it goes to, what triggers an instant transfer to a person | Build the human path before the automated one, always |
| Days 6–8 | Connect the diary if you book appointments. Set durations, buffers and what must never be booked | Booking is where the measurable return concentrates |
| Days 9–10 | Test badly on purpose. Mumble, interrupt, ask something odd, demand a person three seconds in, and test through the National Relay Service | Test the awkward paths, not the designed ones |
| Day 11 | Go live after hours only. The menu still runs during business hours | Lowest-risk launch available — after hours you are competing with voicemail |
| Week 3 | Read every transcript, fix the three worst answers, then extend into business hours | Extend on evidence, never on schedule |
| Week 4 | Retire the menu. Keep a recording of it if you are sentimental | Nobody has ever asked for it back |
4
Numbers to measure first
10
Answers to write
1
Category live first
0
Menu branches worth copying
When You Should Keep Your Menu
An honest page has to include this. There are three situations where a short menu is still the right answer, and one where it is genuinely required.
| Situation | Why the menu wins |
|---|---|
| You genuinely have exactly two destinations | "Sales or service" with low volume is fast, predictable and costs nothing to run. Replacing it buys very little |
| Very low call volume | Under about ten calls a day the configuration effort outweighs the benefit. A good greeting and a missed-call text will serve you better |
| A legally scripted disclosure | Where a specific statement must be played to every caller verbatim, a recording is the right instrument. Play it, then hand to a conversation |
| A hard emergency path | Keep a deterministic route to a human for emergencies. Not because AI cannot recognise urgency, but because this path should not depend on anything understanding anything |
And a caution about the transition itself
The failure mode is replacing a menu people had learned to defeat with an assistant they cannot get out of. If your callers have spent years pressing zero immediately, they will try the equivalent on day one — and what happens next determines whether they accept the change. Make the human path obvious and instant, or you will have made things worse while believing you modernised them.
The summary
Menus solved a scarcity problem that no longer exists, and they solved it by making the caller do your classification work. Measure four things about your own menu, ring it yourself once, and then decide — the decision usually makes itself at that point. And if your volume is small and your structure is simple, keeping a two-option menu is a perfectly respectable answer that nobody should talk you out of.
Related reading: what AI answering actually means if you are starting from scratch, which calls are worth automating for the categorisation method, and the contact centre metrics that matter for the reporting that proves any of this worked.