Why AI-IVR breaks on real calls
A demo of AI-IVR sounds convincing: clean signal, announcer-style wording, perfect silence during pauses. A live line looks different — noisy environment, echo, speech over the question, dropout in the middle of a branch. An intelligent voice menu breaks not on vocabulary, but on acoustics and human behavior.
The first class of failures is noise and interruptions. A caller starts speaking before listening to the prompt, and the network cuts off the beginning of the phrase: the menu hears "I'd like to find out" and goes to the wrong branch.
Call routing errors are the most expensive here — the client reaches an operator who cannot resolve the issue and, after a loop, returns to the beginning.
The second class is non-standard wording. People do not say "state the name of the service": they use an everyday word for it, dictate a number in parts, insert hesitations in the middle of a request.
Without allowance for variability, speech recognition on a call either asks to repeat or confidently selects the closest match — and both options irritate more than a regular menu.
The third is lost calls during peak hours. Under load, recognition runs slower, the pause after an answer stretches out, the caller decides they are not being heard, and hangs up.
A dropout in the middle of a branch almost always throws the person back to the main menu, and some callers simply do not call back.
We look at how this is addressed: how to build a scenario for real acoustics, where to set the confidence threshold, and at what point to transfer the conversation to a live operator.
What changes after implementation: measurable effects
The effect is visible not in a presentation, but in telephony reports for the first weeks after launch. The dialogue is recorded step by step: recognized request, selected scenario branch, transfer to an operator or completion without one.
Therefore, every figure can be checked against the call recording — amoCRM and similar panels provide such slices as a standard export.
- Share of automated requests — on a typical flow, more than half of calls are closed without an operator: balance, request status, terms, service appointment.
- Operator workload — during peak hours the line stops backing up: routine requests are taken off people, leaving them to handle complex topics.
- Queue wait time — drops because only those who actually need a person reach an operator, not every caller in a row.
- Repeat calls — decrease severalfold: the client gets an answer or a booking in a single contact, instead of calling back to clarify.
- Data completeness — the request card is filled in automatically, topics are not lost, and no anonymous calls remain.
This should be viewed by comparing slices before and after launch on the same number: this eliminates seasonality and shows what share shifted specifically because of the voice scenario, and not because of an advertising campaign or a change of operators.
Voice scenario operating modes: comparison of approaches
An outbound calling scenario and an inbound line solve different tasks: on an inbound flow, the caller needs to be retained and led to the goal; on an outbound one, the system must recognize an answering machine, wait for a live answer, and call back within a convenient window.
The chosen dialogue mode directly determines what can be automated at all and where transfer to an operator is unavoidable. This is the first thing we fix before assembling the scenario.
| Mode | When it fits | Limitations |
|---|---|---|
| Button menu | Short survey, order confirmation, payment, appointment booking | The client does not know the tree by heart, makes a mistake at the third level, and some calls end in a hang-up |
| Free speech | Data collection, answers to frequent questions, clarification of details | Depends on recording quality and dialect; without topic boundaries, the system confidently answers the wrong question |
| Hybrid: speech, menu, and operator | Primary mode for sales and service | Harder to test — checks must cover transitions between branches, not individual answers |
| Full automation | Mass outbound calling, surveys, notifications | There is no person on the line: if recognition fails, the request is lost, and a separate callback branch is needed |
The hybrid scheme covers most tasks: typical questions and confirmations go to free speech, complex ones go to an operator according to escalation rules.
Transfer to an operator can happen with loss of context or with the full dialogue history passed into the workspace — these are different scenarios, and they are chosen for a specific line.
We build automation limitations in at the start: emotional and disputed requests should not be recognized at any cost; a fallback branch is more reliable and cheaper to support.
How we implement AI-IVR: stages of engineering work
AI-IVR implementation begins not with recording a greeting but with analyzing call recordings: we look at what requests actually come into the line, what share of them are typical, and at what step the client hangs up. The dialogue scheme and what should not be automated depend on this picture.
- Analysis of call recordings. We label conversations by request types and count how many are closed by script, how many require access to systems, and how many go to an operator.
- Dialogue scheme design. Branches, decision points, sets of wordings the bot must understand, and the boundaries of what is permissible — what it has no right to promise the client.
- Scenario setup. We assemble the greeting, clarifying questions and answers, and connect reference data on services and request statuses.
- Escalation to an operator. We define transfer rules: low-confidence recognition, repeated question, request to connect to a person, emotional speech. Plus routing to the right group and transfer of dialogue context.
- Adaptation of speech recognition to the subject area. We load a dictionary of terms, service names, and addresses, and test on recordings with poor connection and background noise.
- Test run and pilot. We call the line through the scenarios, measure the share of correct recognitions, transfers to an operator, and dialogue length until resolution, then put the bot on part of the traffic and configure thresholds.
- Handover of support regulations. We provide instructions: how phrases are edited, scenarios added, where to view call logs, and who updates the dictionary after service changes.
This keeps the line manageable: changes are made according to regulations, not by rebuilding from scratch.
What you receive: configurations and regulations
We deliver the project not as a menu demonstration but as a working package: everything that describes AI-IVR behavior remains in your repository and works without our involvement.
The handover scope is below; using these documents, your team can change the scenario without reconstructing the history of correspondence.
- Scenario map — dialogue tree with branches, exit points to an operator, and escalation conditions. With it, the logic can be reconstructed in an hour, rather than from call recordings.
- Telephony documentation — number routing, channel pool, mapping scenarios to groups, recording storage. A separate section — what to do when changing PBX or adding a number.
- Change regulations — who formulates an edit, where a new phrase is tested, what checks are mandatory before rollout, and how to roll back to the previous scenario version.
- Access rights to settings — role matrix: editing lines, viewing transcripts and metrics, managing integration keys. Separately — access to personal data from recordings.
- Set of test cases — reference phrases with expected answers, including noise, interruptions, and poor connection. Run in full after every edit: it shows what has not broken.
- Recognition dictionaries — pronunciation of names, abbreviations, and Latin script, order numbers as digits. This is where the voice menu makes mistakes most often.
- Analytics instruction — export of transcripts, share of successful scenarios, call drop-off points: improvement decisions are made based on data, not by ear.
We hand over the package in your version control system, and go through each section together with the engineer who led the project. After that, your team makes edits independently — if you need support on our side, we will discuss the format.
Case study: how the share of missed calls was reduced
Failure point: evening peak
A delivery service took orders and status questions on one line.
During the evening peak, the queue reached 40 seconds, and every fourth caller hung up — while more than half of the calls were of the same type: "where is the order," "change the address." A missed call did not disappear: the client called back, and the load doubled exactly during the hours when operators were busiest.
The failure hit the busiest hours hardest: some orders went to other providers, and repeat requests consumed operators' time instead of generating new sales.
What we changed
The first processing layer became AI-IVR: a voice assistant answers the call, recognizes speech, and closes typical scenarios — order status, address change, time rescheduling — without an operator.
The remaining requests go to an operator with a transcript and context, so the conversation does not start from scratch.
For peaks, we configured separate behavior: when the queue overflows, a callback is offered instead of waiting on the line. Request distribution was rebuilt by topic rather than order of arrival — simple questions no longer wait in line behind complex ones.
Result in metrics
- missed calls: 26% → 4%;
- requests closed without an operator: 61%;
- time to first answer: 38 → 5 seconds;
- repeat calls about the same issue: halved.
The same operators handle the evening load without expanding staff, and new scenarios are added to the menu without rebuilding the line.
How free speech differs from a button menu
A button menu does not analyze speech — it registers the tone of key presses, so its recognition accuracy is absolute: the client either pressed the digit or did not.
The price is a rigid structure: the scenario is laid out by levels in advance, and the person listens through the tree to the desired branch.
Free speech works differently: the stream is converted to text, then the intent is extracted from the phrase.
Recognition accuracy depends on recording quality, accent, and industry terms, but complex client wording — "reschedule delivery to the day after tomorrow, same address" — is parsed as one intent, not as four menu steps.
Call handling speed changes ambiguously.
In a menu, the client spends time listening to levels, but the action is performed immediately after pressing; in a speech dialogue, recognition is added, but three or four intermediate levels are removed — on a non-standard request the conversation is shorter, on a typical one the menu wins.
| Option | When it fits | Limitations |
|---|---|---|
| Button menu | 3-5 unambiguous branches: balance, request status, connection to an operator | The client listens to the whole tree; a non-standard request hits a dead end |
| Free speech recognition | Wide variation in wording, long service names, request numbers | Needs examples of real requests and regular additional labeling of wordings |
| Hybrid | Critical actions are confirmed by selection, the rest by speech | Harder to design transitions between modes |
Scenario support diverges the most. A new branch in a button menu means re-recording the audio tree and rebuilding logic, where an edit affects neighboring levels.
In a speech scenario, wordings are added to the intent description and do not break the entire structure, so changes are made more often and tested on recordings of real calls. Hence the practical conclusion: hybrid — speech for complex wording, buttons for critical actions.
Common technical doubts before launch
Before launch, the client's engineers ask approximately the same set of questions: how the system behaves on a real line, what will happen to integration, and whether it can be rolled back. We answer directly — without promising that it "understands everything."
What to do about noise on the line?
At the input, we apply noise suppression, echo cancellation, and a speech detector — only the speech segment goes to recognition, not pauses and hum. We configure the activation threshold on the client's recordings: in a noisy room, the error rate levels out with a clean line.
What if clients have a strong accent or unclear diction?
A standard model loses a noticeable portion of phrases on such traffic. We fine-tune it on the client's recordings and adjust the language model to the domain — service names, SKUs, names. When confidence is low, the system does not guess but transfers the call to an operator.
How does the voice menu connect to business systems?
Through exchange interfaces: request, order, status — by client identifier. Requests are idempotent, with timeouts; if the system is unavailable, the dialogue does not break, and the data is queued for later writing.
Can we return to the old scheme?
Yes. Routing switches to the classic menu with one rule; the number and scenario remain in place. The rollback takes minutes and does not require reissuing the line.
How do we test the solution before launch?
We run the client's anonymized recordings through the scenarios and provide a report: share of successfully recognized phrases, calls handled without an operator, response time.
What to discuss with us before project start
The timeline and scope of AI-IVR work depend not on the number of phrases in the menu, but on how call routing is structured and how many systems participate in the answer. Therefore, we first collect inputs — and based on them, we return with a work plan and project estimate.
What is needed from the client at this step:
- Dialogue scenario: what types of requests go to the menu, where calls are currently lost, and what a successful conversation looks like from greeting to connection with an operator.
- Telephony inputs: platform, routing scheme, numbers and queues, concurrent channel limit, access to conversation recordings.
- Sound quality: how conversations are recorded, whether there is echo, noise, or dropouts — on a poor channel the bot asks again more often, and this is included in the plan.
- Domain dictionary: service names, SKUs, addresses, rare surnames — we add them to recognition in advance to avoid generating unnecessary clarifications.
- Integrations: CRM, billing, ticketing system, knowledge base — what the bot reads at the input and what it records as a result of the call.
- Escalation rules: conditions for transfer to a live operator, behavior when recognition fails, what the bot says outside working hours.
- Acceptance criteria: share of calls closed without an operator, recognition accuracy on a test set, acceptable response time.
We handle some points ourselves: we analyze conversation recordings, extract frequent wordings, and assemble a draft scenario. Then we send work stages with order, team composition, and timelines, and bring disputed points into a separate review.