Nobody tests a phone menu from the outside. The person who built it knows which key to press, so they press that one; the caller who presses 3 and hears silence hangs up and does not report it. The faults stay in for years, and the only symptom is business you never hear about.
Build it, then break it
New work goes to whoever can quote it, existing jobs go to the office, and an emergency reaches somebody at any hour.
Your menu stays in your browser. Nothing is uploaded.
What is wrong with it
- Worth knowing“After hours” has no 0. Callers press it anyway when they want a person.
Be the caller
Press the keys as a caller would. Leave it alone to see what happens when nobody presses anything.
- HearsThanks for calling. For a quote on new work, press 1. For a job already booked in, press 2. For accounts, press 3. To speak to anyone, press 0.
- Still listening.
The menu a caller hears
Write it as it will be read aloud. The check compares the keys named here against the keys that work.
Keys
Write it as it will be read aloud. The check compares the keys named here against the keys that work.
Keys
→ Menu: afterhours
Take it away
The diagram is yours to publish, under CC BY 4.0. The plan opens again here; nothing is kept on our side.
What goes wrong, and why callers never tell you
Every row below is a real check, run against a template that is broken on purpose. Load that template in the tool above and you will see exactly this list. The page is generated from the checker rather than describing it, so it cannot advertise something the code does not do.
| How bad | What it found |
|---|---|
| Breaks the call | Pressing 3 in “Main menu” leads nowhere. The caller hears silence. |
| Breaks the call | “Main menu” does nothing when a caller presses nothing. Somebody on a car speaker, or on a rotary phone, is stuck there. |
| Breaks the call | The queue on option 1 in “Main menu” has nowhere to send a caller nobody picks up. They wait until they give up. |
| Breaks the call | The greeting for “Main menu” tells the caller about 6, and nothing happens when they press it. |
| Worth fixing | 7 works in “Main menu” but the greeting never mentions it, so only somebody who already knows will press it. |
| Worth fixing | “Main menu” offers 6 choices. Past about 5, callers stop holding them in mind and press whatever came last. |
| Worth knowing | “Main menu” has no 0. Callers press it anyway when they want a person. |
| Breaks the call | Every path out of “Support” leads back into a menu. A caller who arrives can never reach a person or a mailbox. |
| Worth fixing | Nothing points at “Old campaign line”. No caller can reach it. |
| Breaks the call | Nothing happens to a caller who rings outside opening hours. |
| Worth knowing | There is no holiday path, so a statutory holiday will be answered as an ordinary open day. |
The two script checks are the ones worth having and the ones nothing else runs. A greeting and a menu are edited by different people at different times, and when they disagree the caller is the only one who finds out.
How it works underneath
A phone menu is a directed graph: each key is an edge, each destination is a node, and a caller is a walk through it. Most of the faults are properties of that graph rather than of any one screen, which is why they survive a careful read-through. An option with no destination is an edge to nowhere. A menu whose every exit leads back into a menu is a component with no way out, and the check has to walk the whole graph to see it, because a submenu pointing back at a main menu that does have real endings is perfectly fine.
Two checks are not graph properties at all, and they are the ones we would keep if we could only keep two. The first reads the digits your greeting names and compares them with the keys that actually work, in either direction: a script that promises a 4 nothing answers, and a working 7 the script never mentions. The second estimates how long the greeting takes to read, at about two and a half words a second, because a caller who has waited twenty seconds to hear the options starts pressing 0.
The simulator is a plain walk over the same structure. It has no timers and no telephony: pressing a key follows an edge, waiting takes the timeout edge, and an unrecognised key counts against the attempt limit before taking the invalid path. When it stops on a node with nowhere to go it says so, which is the same condition the dead-end check reports statically. Two routes to the same finding is deliberate, because one of them will be the one you happen to look at.
None of it leaves your browser. There is no endpoint behind this page, no account, and no copy of your menu anywhere but the tab you have open.
What you take away
A script to record. Every prompt in reading order, with the keys and destinations printed beside them, so whoever reads them into a microphone can see what each one is promising.
A diagram. An SVG of the whole menu, with anything that leads nowhere marked in red. It is yours to publish under CC BY 4.0: put it in a post, a handover document or a training deck.
The plan itself. A small JSON file that opens again here. It lives on your machine; there is no account and nothing is kept on our side.
Questions
What is a dead end in a phone menu?
A key the caller can press that leads nowhere. They press 3 for accounts, the line goes quiet, and nothing happens until they hang up. It is the most common fault in a phone menu because it is invisible from the inside: the person who built it never presses 3, and the caller who does has no way to tell you.
What happens if a caller presses nothing at all?
That depends on whether you gave the menu a timeout path, and a surprising number of menus have not. Somebody driving, somebody on a speaker, somebody on an old handset that sends no tone at all: they hear the options, press nothing, and wait. If there is no timeout destination they wait in silence. Setting one is the single highest-value fix on this page.
How many options should a phone menu have?
About five at the most, and fewer is better. Past five, callers stop holding the list in mind and press whatever they heard last, which sends them to the wrong place and costs you the transfer anyway. If you need more than five, the answer is usually a second menu behind one option rather than a longer first one.
Why does the tool compare my script to my keys?
Because they drift apart, and nothing else catches it. Somebody adds a department and updates the menu but not the recording, or re-records the greeting from an old draft. The result is a greeting that says press 4 for deliveries when 4 does nothing, or a working option nobody is told about. Both are invisible until a caller hits one.
Does this connect to my phone system?
No. This is a plan, not a deployment. Nothing here reaches a phone network, places a call or changes a live line, and the waiting times you set are the ones you typed rather than anything measured. What you take away is a script to record, a diagram to share and a file you can open again.
Do you keep my menu?
No. Everything runs in your browser: the templates ship with the page, your edits stay in the tab, and the files you download are written on your own machine. There is no endpoint behind this page, so there is nothing for us to keep even if we wanted it.
Once the plan is right
A plan is not a phone line. Somewhere it has to become a menu that answers, with hours behind it and a version you can change on a Tuesday without ringing anybody. That is the part a phone system does, and it is worth being able to edit yourself.