IVR (Interactive Voice Response)
How an IVR works
An IVR answers the call, plays a prompt, reads the digit the caller presses, and follows the branch attached to it.
The call reaches the IVR on a pilot number, over the public switched telephone network (PSTN) or over a SIP trunk from the calling platform. The IVR answers and plays a prompt, an audio file uploaded as WAV or MP3. The caller presses a key, and that key emits two simultaneous tones, one low and one high frequency. The number one, for example, produces a 697 Hz tone and a 1209 Hz tone at the same time. The IVR detects the pair, resolves it to a digit, and looks up the branch mapped to that digit in the call flow.
A branch does one of four things. It plays another menu, one level down. It plays an audio message and hangs up, which is how after-hours and closure announcements work. It transfers the call to an extension, an operator group, a queue, an external number or voicemail. Or it collects more digits, which is how dial-in by extension works: the caller types the number and skips the menu entirely.
A branch can also use the digits it collects. A caller types an identifier on the keypad, a script queries the system that holds the record, and the IVR plays back the answer as audio. This is the part of an IVR that needs an integration behind it, and it is scoped as a project, not configured in a menu.
IVR vs conversational IVR: what is the difference?
An IVR listens for a digit. A conversational IVR listens for a sentence.
An IVR works from a fixed list. Every destination the caller can reach has a digit attached to it, and the caller’s job is to map their problem onto that list. Anything not on the list has no path, which is why the escape option to a person matters so much.
A conversational IVR removes the list. It opens with a broad prompt, transcribes what the caller says with speech recognition, and classifies the request against intents rather than digits. The caller describes the problem in their own words and the system picks the destination.
The consequence is about what each one can absorb. An IVR is faster than speech for a caller who already knows which digit they want, and it stays predictable: the same key always leads to the same place. But every new service means a new option, and a menu only holds three to five before callers stop retaining it. A conversational IVR has no ceiling of that kind, and handles requests nobody wrote an option for. It also introduces a failure mode an IVR does not have: a request understood as the wrong intent, which the caller cannot correct by pressing zero.
So the choice follows the shape of your inbound calls. A short, stable set of destinations is a menu. A long tail of requests you cannot list in advance is a conversation.
What an IVR is used for
Two groups, split by one question: does the flow only need to know destinations, or does it also need to read digits the caller types?
Destinations only.
- Department, site or service selection, with each digit mapped to one destination
- Language selection, where a digit sends the call down a language-specific branch
- After-hours, holiday and unplanned closure announcements
- Overflow to a queue or an operator group when the first destination does not answer
- Dial-in by extension, where the caller types the number instead of using the menu
- Multi-level flows, where a branch opens another IVR service
With digits read into a business system.
- Caller identification, collected on the keypad and passed to the agent before the call is answered
- Status enquiries: order, shipment, ticket, account
- Confirmation and cancellation, where a digit writes back to the record
The second group is a category capability, not a menu setting. It exists only where the IVR is integrated with the system that holds the answer, and that integration is the part of an IVR deployment that gets underestimated.
What affects the quality of an IVR menu
Five things, all decided at design time: how deep the menu goes, what happens when nothing is pressed, whether a person is reachable, how many calls fit at once, and whether the menu follows the clock.
They all point at the same failure. A caller listening to five options has to hold the list in memory, decide which one owns their problem, and commit before the prompt ends, with nothing in the prompt telling them what sits behind each option. When the guess is wrong, they land somewhere that cannot help, wait, get transferred, or hang up and redial.
Menu depth is the number of levels a caller passes before reaching a destination. Each level adds prompts to listen to and one more chance to pick wrong. Three to five options per level is the usual working limit, with the most requested service first.
No-input and no-match timeouts are what the IVR does when the caller presses nothing, or presses a digit with no branch attached. Both need a named destination. Without one, the call ends in silence and counts as abandoned.
The escape option is the branch that reaches a person, conventionally zero. A menu without one turns every unlisted problem into a hang-up.
Concurrent channels is how many calls the IVR can hold at the same time. Past that limit an overflow behaviour decides what the next caller hears, and if none is configured, the caller hears nothing useful.
Time-based behaviour is the rule that swaps the active menu by business hours, holidays and unplanned closures. Without it, an 8pm caller works through the daytime menu to reach a department that went home.