A virtual receptionist is judged on one thing: whether the caller reaches someone who can actually help, first time. Most routing fails because the menu is built around the organisation rather than around what callers want — and the customer is asked to know your departmental structure in order to be helped by it.
This guide covers the four routing decisions, why org-chart menus fail, how to route on intent, where routing breaks, and what to measure.
The four routing decisions
Every inbound call needs four questions answered, in this order.
| # | Question | Source |
|---|---|---|
| 1 | Who is this? | Caller ID matched against the CRM and DMS |
| 2 | What do they want? | What they say, in their own words |
| 3 | Who can help? | Skill and availability, not department name |
| 4 | Are they there now? | Live presence, not a schedule |
Most systems answer 2 and 3 and skip 1 and 4, which produces the two most common complaints: being asked who you are when the store already knows, and being transferred to someone who is not there.
1. Who is this?
A matched caller ID should change the entire call. A known service customer calling at 4pm is probably asking about their vehicle. A known sales customer two days after a test drive is probably calling about that. Opening with "Hi Dana — calling about the CR-V in service?" resolves most calls in one exchange.
Not matching is a wasted integration. The data exists in the DMS and CRM; the question is whether the phone system can see it.
2. What do they want?
In their words, not from a menu. "I want to know if my car's ready" is a complete intent and does not need to be translated into option four.
3. Who can help?
By skill and availability, not by department name. The caller does not know whether their question belongs to service, parts or the warranty administrator, and asking them to choose is asking them to do a job they cannot do.
4. Are they there now?
Transferring to someone who is not at their desk is the single most common routing failure, and it is entirely avoidable with presence information. A routing decision made from a schedule rather than from live status produces a transfer into a voicemail box — which is where missed calls come from.
Why do org-chart menus fail?
Because they ask the caller to model your business.
Two menus, same store
Org-chart menu Intent menu "Press 1 for Sales" "Are you calling about a car you own, or one you are looking at?" "Press 2 for Service" "Press 3 for Parts" Then: "Is it about a repair, an appointment, or something else?" "Press 4 for Finance" "Press 5 for Body Shop" "Press 6 for Administration" "Press 7 to repeat" The left column is correct about the business and useless to a caller who does not know whether a warranty question is service, finance or administration.
The right column asks two questions a caller can always answer, and derives the department from the answers. It is also shorter to listen to, which is the other reason callers abandon menus.
Two options, then narrow. Phone is a terrible medium for lists, and every additional option sheds callers before they choose.
Where does routing break?
1. No presence check. Transferring to a desk nobody is at.
2. No fallback when the target is unavailable. The call needs a second destination, not a voicemail box.
3. Caller ID not matched. The store asks a customer it already knows who they are.
4. Too many options. Covered above, and it is the most measurable fix.
5. Misroutes recorded as answered. A call that reached the wrong department and was abandoned shows as handled. This is why first-time-right has to be measured separately from answer rate.
6. No path back. A caller who routes wrong should be able to get back without hanging up and calling again — and the menu abandonment data shows how many never do. The opening itself is covered in the first ten seconds.
7. Routing by rotation rather than availability. The same pattern that breaks lead routing, applied to the phone.
What does good routing look like?
Four properties:
Short. Two choices at a time, three levels maximum.
Informed. Caller ID matched, and the opening reflects it.
Live. Availability checked before transferring, with a named fallback.
Recoverable. A way back from a wrong turn without redialling.
A system with all four resolves the large majority of calls in one transfer. One missing presence checking will produce a steady rate of transfers into empty desks regardless of how good the rest is.
What should you measure?
| Metric | How to compute | What it catches |
|---|---|---|
| First-time-right rate | Calls resolved without a second transfer ÷ total | The headline |
| Transfers per call | Average | Should be at or near one |
| Transfer-to-voicemail rate | Transfers landing in voicemail ÷ transfers | The presence-check failure |
| Menu abandonment by level | Hung up, per menu level | Where the list is too long |
| Caller ID match rate | Matched ÷ calls from known numbers | Whether the integration is working |
| Misroute by intent | Wrong destination, split by what they wanted | Which intents the menu mishandles |
Row three is the one that embarrasses most systems and the one that is easiest to fix. Row six tells you exactly which menu branch to rewrite, and it is the difference between redesigning the whole tree and changing one question.
Frequently asked questions
What makes dealership call routing fail?
Menus built around the organisation rather than around what callers want. A customer with a warranty question does not know whether that belongs to service, finance or administration, so asking them to choose a department is asking them to do a job they cannot do.
How many options should a phone menu offer?
Two at a time, three levels at most. Phone is a poor medium for lists and every additional option sheds callers before they choose, which shows up as menu abandonment rather than as a routing failure.
Should the system know who is calling?
Yes, when the number matches a customer record. Opening with the customer's name and a reasonable guess at their reason for calling resolves many calls in a single exchange, and asking a known customer to identify themselves signals that the integration is superficial.
What is the most common routing failure?
Transferring to someone who is not at their desk. It is entirely avoidable with live presence information, and routing from a schedule rather than from current status produces a steady stream of transfers into voicemail boxes.
Why measure first-time-right separately from answer rate?
Because a call that reached the wrong department and was then abandoned records as answered. Answer rate says the phone was picked up; first-time-right says the caller got to someone who could help, and only the second one describes the customer's experience.
What should happen when the right person is unavailable?
A named fallback destination rather than a voicemail box, and a way for the caller to get back to the start without hanging up and redialling. Both are configuration decisions rather than technology ones, and both are commonly missing.
How do you decide which menu branch to fix?
Measure misroutes split by what the caller actually wanted. That identifies the specific intents the current menu mishandles, which usually means rewriting one question rather than redesigning the whole tree.
Does intent-based routing require AI?
Not necessarily — even a two-question structure phrased in customer language outperforms a seven-option departmental list. What AI adds is handling the answer in the caller's own words rather than requiring them to choose from offered options, which shortens the call further.
Conclusion
- Four decisions: who is this, what do they want, who can help, are they there now.
- Most systems skip the first and the last, which produces the two most common complaints.
- Route on intent, not on your org chart. The caller cannot classify their own question.
- Two options at a time, three levels maximum.
- Measure first-time-right, not answer rate. A misroute records as a handled call.
Last updated: