Conversational IVR is an interactive voice response system that accepts natural speech instead of keypad presses. A caller says what they want in their own words, and the system recognises the speech, works out the intent, and either resolves the request or routes the call, without walking anyone through a numbered menu.
Last updated: August 2026 By Janhvi Nandwani
The shift is usually described as a customer experience upgrade. It is also a change in what the system is technically made of, and the second framing is the one that explains why these deployments succeed or fail.
What is conversational IVR?
The system handles a phone call using speech as the primary input. Where a traditional system offers a fixed menu tree and waits for a digit, a conversational system takes an open utterance, maps it to an intent, and holds enough context across turns to complete a task.
Three capabilities distinguish it:
- Open input. The caller is not choosing from a list. "I need to change the card on my account" is a valid opening turn.
- Intent resolution over keyword matching. The system distinguishes requests that share vocabulary, such as making a payment and disputing one.
- Context across turns. Information given in turn two is still available in turn five, so the caller is not asked twice.
The term overlaps with "voice AI agent" and "voicebot." The IVR framing usually implies the system occupies the front of a contact centre call flow, with routing and agent handoff as first-class concerns, rather than being a standalone assistant.
How conversational IVR differs from touch-tone IVR
| Touch-tone IVR | Conversational IVR | |
|---|---|---|
| Input | Keypad digits, fixed menu | Open natural speech |
| Interpretation | Digit maps to a branch | Speech recognised, then intent classified |
| Failure mode | Caller cannot find their option | System mishears or misclassifies |
| Recovery | Repeat the menu | Reprompt, disambiguate, or hand off |
| Context | Usually none between steps | Maintained across turns |
| What breaks it | A menu that does not cover the case | Accents, noise, overlapping speech, ambiguity |
The important line in that table is the failure mode. A touch-tone system fails visibly: the caller presses zero and asks for a human. A conversational system fails quietly. It hears something plausible but wrong, proceeds confidently, and the caller only discovers the problem later. That is why testing one is a different job from testing a menu tree.
Why speech and keypad input are handled differently underneath
This distinction predates AI and explains a class of bug teams still hit.
Keypad presses generate DTMF, the dual-tone pairs a phone produces per key. Over a modern voice network those tones are not simply carried inside the audio. RFC 4733, a December 2006 IETF Proposed Standard titled "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", defines a separate telephone-event payload that carries digits as named events rather than as sound, and assigns event codes 0 to 15 to the digits 0-9, star, hash and A-D.
The reason it exists is stated plainly in the document: separate payload formats are needed because "low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition."
Read that in the context of speech input. RFC 4733 is about tones, not speech, and does not make a claim about recognition accuracy. What it establishes is that the telephony path degrades a signal enough to need engineering around, and speech has no equivalent escape hatch: there is no out-of-band channel for a sentence, so every word arrives through the codec.
Speech recognition vendors treat phone audio as its own problem for that reason. Deepgram ships dedicated phonecall variants of its models, documented as "Optimized for low-bandwidth audio phone calls," alongside its general-purpose models. A separate model exists because the same words over a phone line are a harder input, which is why a system that scores well on clean audio can degrade on a real call.
Platform documentation reflects the split. Twilio's <Gather> reference accepts an input attribute of dtmf, speech, or dtmf speech, and notes that when both are configured, "timeout takes precedence for DTMF input and speechTimeout takes precedence for speech." The two input types need separate timing because they fail on different clocks: a digit is instantaneous, while a sentence has pauses inside it that must not be mistaken for the end of a turn.
What the system is built from
Five components, each with its own failure mode.
Speech recognition (ASR) turns audio into text. Accuracy depends on accent, background noise, codec and domain vocabulary. Twilio's documentation notes that its enhanced attribute selects a premium Google STT V1 model and states that for phone conversations "the premium model produces 54% fewer errors compared to the base model," which indicates how much the recognition tier alone can move outcomes.
Natural language understanding maps recognised text to intent and extracts entities such as dates, amounts and account numbers.
Dialogue management decides what happens next: answer, ask a clarifying question, confirm, or hand off. This is where context across turns lives.
Speech synthesis (TTS) produces the reply. Its failure modes are prosody and pacing rather than accuracy.
Telephony carries the call, and contributes latency, jitter, packet loss and the codec constraints above.
A failure anywhere in that chain presents to the caller identically, as the system getting it wrong. Diagnosing which layer caused it is most of the operational work.
Which metrics matter
| Metric | What it tells you |
|---|---|
| Containment rate | Share of calls resolved without an agent |
| Intent recognition accuracy | How often the intent was classified correctly |
| Word error rate | ASR quality on your actual audio, not on clean samples |
| Turn latency at p50 and p90 | How long the caller waits before hearing a reply |
| Interruption handling | Whether the system stops talking when the caller speaks |
| Entity capture accuracy | Whether numbers, dates and names were captured correctly |
| Escalation appropriateness | Whether handoffs happen when they should, and only then |
| Task completion rate | Whether the caller's actual goal was met |
Containment is the metric most often reported and the easiest to game. A system that never offers an agent has excellent containment and terrible outcomes. Read it alongside task completion, or it means nothing.
That no single number stands alone is not a new observation. PARADISE, presented at ACL 1997 by Marilyn Walker, Diane Litman, Candace Kamm and Alicia Abella at AT&T Labs, remains the reference framework for evaluating spoken dialogue agents. Its central move is to treat performance as a composite: "Performance is modeled as a weighted function of a task-based success measure and dialogue-based cost measures, where weights are computed by correlating user satisfaction with performance."
Three parts of that are worth taking literally. Success and cost are separate terms, so a system can succeed expensively and the number will show it. The weights are not chosen by the vendor; they are fitted, using linear regression against measured user satisfaction. And the framework "decouples task requirements from an agent's dialogue behaviors," which is what lets you compare two systems that solve the same problem through different conversations.
The practical translation is that containment, task completion and turn latency should be read as one weighted picture calibrated against what callers actually reported, not as a scoreboard where the flattering number gets quoted.
Where conversational IVR fails
The failures that matter in production are rarely the model being wrong about language.
Endpointing. The system decides the caller has finished when they have only paused. It interrupts, or it waits through silence and feels broken.
Entity capture under noise. Intent is correct, but a digit in an account number is wrong. The call proceeds down a valid path with invalid data.
Confident misclassification. Two intents share vocabulary, the system picks the wrong one, and nothing signals the error until the caller notices.
Handoff losing context. The call transfers and the human agent asks the caller to repeat everything, which erases the benefit of the automation.
Degradation on real audio. The system was tuned on clean recordings and meets accents, speakerphones and background noise in production.
How these systems are tested
Testing a menu tree means walking every branch. Testing a speech-driven system means checking behaviour across an open input space where the same request can be phrased countless ways, and where the same phrasing can produce different outcomes on different runs.
That requires simulated calls rather than scripted click-throughs: synthetic callers that speak, interrupt, hesitate and use varied phrasing against the live system over a real telephony path, with each turn scored. Cekura runs exactly that, and covers the tooling and coverage question in depth in IVR Testing Explained: Types, Tools, and Best Practices. Cekura documents the scripted side, for the deterministic flows a conversational system still contains, in Cekura: Scripted Testing Tool for IVR and Voice Agents, and the handoff case, where an IVR passes a caller to a chat or agent channel, in Ensuring Reliable IVR to Chatbot Journeys.
Repetition is what makes the results trustworthy on a non-deterministic system. Cekura's benchmarks tested six voice orchestration platforms with 59 evaluators across four categories, running each scenario three times and scoring on pass^3, so a scenario counts as passed only when all three runs pass. Retell scored 96.6%, Vapi 94.9%, Pipecat 89.8%, LiveKit 84.7%, Synthflow 81.4% and ElevenLabs 76.3%.
Two caveats travel with those figures wherever they appear. Pass^3 is deliberately harsher than a single-run pass rate, so the two are not comparable. And the language model was held constant at gpt-4.1 at temperature 0 across all six. Speech recognition was pinned to Deepgram nova-3 on Vapi, Synthflow, LiveKit and Pipecat only, because Retell exposes only a coarse mode and ElevenLabs forces its own Scribe, so recognition is an uncontrolled variable on those two. Most of the spread therefore describes orchestration behaviour rather than model choice. Those platforms are voice agent frameworks rather than contact centre IVR products, so the numbers describe the orchestration layer a conversational IVR may be built on, not IVR products themselves.
Frequently asked questions
What is conversational IVR?
Conversational IVR is an interactive voice response system that accepts natural spoken language instead of keypad presses. It recognises what the caller says, classifies the intent, keeps context across turns, and either completes the task or routes the call, without presenting a numbered menu.
What is the difference between conversational IVR and traditional IVR?
Traditional IVR takes keypad digits and maps each one to a fixed branch. Conversational IVR takes open speech, classifies intent, and maintains context between turns. The practical difference is the failure mode: a menu tree fails visibly when the caller cannot find their option, while a conversational system can mishear and proceed confidently down the wrong path.
Is conversational IVR the same as conversational AI?
Not quite. Conversational AI is the broader field covering any natural language interface. Conversational IVR is the application of it to inbound telephony, where call routing, agent handoff and contact centre integration are part of the requirement.
What does DTMF mean, and does conversational IVR still use it?
DTMF is the dual-tone signalling a phone keypad produces. Most conversational systems still accept it, because digits remain the better input for account numbers and confirmations. Twilio's <Gather> accepts dtmf speech for exactly this reason. RFC 4733 carries those digits as named events rather than as audio, because low-rate voice codecs cannot reproduce the tones reliably enough for automatic recognition.
Which metrics measure conversational IVR performance?
Containment rate, intent recognition accuracy, word error rate on real call audio, turn latency at p50 and p90, entity capture accuracy, interruption handling and task completion. Containment should never be read alone, because a system that never offers an agent scores perfectly on it while serving callers badly.
Do the Cekura benchmark numbers apply to IVR products?
Not directly. The pass^3 rates from 96.6% for Retell down to 76.3% for ElevenLabs measure voice agent orchestration platforms, not contact centre IVR products, with the language model held constant at gpt-4.1 at temperature 0, so they describe orchestration behaviour rather than model quality. Pass^3 is also harsher than a single-run pass rate.
Cekura tests conversational IVR with simulated callers over a real telephony path, scoring every turn. Book a demo to see it run against your own call flow.
