You know the experience. You ring a business with a simple question, a recorded voice lists six options, none of which match, and you press the one that sounds least wrong. Two more layers later you are on hold for the department that cannot help, and you are asked to start again.
Phone menus were designed to route calls efficiently for the business. They rarely feel efficient for the caller. The core problem is that a menu makes the customer do the sorting: they have to work out which of your internal categories their problem belongs to before anyone listens.
Conversational assistants approach intake the other way round. This piece looks at the IVR vs chatbot question honestly, including where a plain phone menu is still the right tool. One clarification first: SpideyChat is a website assistant. It does not answer phone calls, so the comparison here is between channels, not between two products we sell.
Why rigid menus annoy people
The frustration is not random. It comes from a few specific design problems:
- Your categories, not theirs: "Press 2 for accounts" means nothing to someone whose question is "why was I charged twice?"
- No way to say 'both': a caller with a delivery problem and a billing question has to pick one and hope.
- Memory load: listening to a list of options and holding them in your head is harder than reading them.
- Dead ends: a wrong choice often means hanging up and starting over.
- Hiding the human: menus that bury or remove "speak to someone" tell callers the business would rather not talk to them.
None of these are failures of the technology. They are the natural result of forcing open-ended human problems through a fixed tree.
What conversational intake does differently
A conversational assistant starts with an open question and works out the category itself. Compare the same problem through each route.
A typical phone menu:
Recording: For new bookings, press 1. For existing bookings, press 2. For billing, press 3. For all other enquiries, press 4.
Caller presses 2.
Recording: To change a booking, press 1. To cancel, press 2. To hear your booking details, press 3.
Caller wanted to ask if parking is available at their appointment. Presses 0. Holds.
The same need, typed into a website assistant:
Visitor: I've got an appointment Thursday, is there parking nearby?
Assistant: There's a free car park behind the building, entrance on Mill Lane, and two disabled bays by the front door. Is there anything else about Thursday I can help with?
Nobody had to choose a category. The assistant searched the business's own content, found the parking information and answered. If that information did not exist, a well-built assistant would say so and offer to pass the question to the team rather than make something up.
The same approach works for triage. Instead of "press 9 for emergencies", the assistant can ask what has happened and pick out urgent cases from the description. Urgent vs routine enquiry triage goes through how to set those rules sensibly.
What each channel is actually good for
Phone menus are not all bad. A two-option menu that separates "emergency call-out" from "everything else" is quick and clear. The trouble starts when menus try to answer questions instead of routing calls.
| Job | Short phone menu | Website assistant |
|---|---|---|
| Routing to the right department | Good, if options are few | Good |
| Answering factual questions | Poor | Good, from your content |
| Handling problems that span categories | Poor | Good |
| Collecting details before a callback | Awkward | Good |
| Genuine emergencies | Good, straight to a person | Should direct to phone or emergency number |
| Customers who prefer to talk | The only option | Not suitable |
| Out-of-hours questions | Usually a voicemail | Answers any time |
| Multiple languages | Needs recorded menus per language | Replies in the visitor's language |
The row about emergencies matters. For anything involving safety, health or immediate risk, a person on the phone or the emergency services is the right destination, and a website assistant should say that plainly rather than try to handle it.
Using both to shorten the menu
The most practical change for most businesses is not replacing the phone system. It is removing the reasons people call about routine things.
- Look at the menu options callers choose most, and listen to a sample of those calls.
- Pick out the calls that are factual questions: hours, parking, prices, what to bring, which areas you cover.
- Make sure those answers are written clearly on your website.
- Put a website assistant on the pages where those questions arise, so visitors get answers before they think to ring.
- After a month, remove or merge menu options that are now rarely used.
- Keep a quick route to a person on the phone, always.
Your phone line then handles fewer, more complicated calls, which is what your staff are best at. The comparison between website and phone receptionists covers how customers tend to divide between the two channels.
A realistic view of the limits
A website assistant will not help someone who is driving, someone who does not use the internet comfortably or someone who simply wants to hear a voice. Those customers will keep ringing, and they deserve a phone experience that does not make them press seven buttons.
Equally, an assistant is only as useful as the content behind it. If your site does not say where to park, neither will the assistant.
Conversational intake also brings a responsibility menus do not have. A menu cannot say anything wrong, because it barely says anything at all. An assistant answers in full sentences, so it needs clear boundaries: answer from your own content, admit when it does not know, and pass anything risky to a person. Check a sample of its conversations every week, particularly at the start, and look at the questions it logged as unanswered. Those are usually the same gaps callers were ringing about.
Finally, menus are cheap to leave alone and assistants are not. Your prices and hours change, and the assistant's content has to change with them.
Your next move
Call your own business from a mobile this week, as a customer would, and time how long it takes to reach an answer to a simple question. Then ask the same question on your website.
If either experience is slow, fix the slower one first. For the website side, the live demo shows how conversational intake feels from the visitor's end, and the glossary explains terms like grounding and handover if you are briefing a colleague.