Voice AI bot instead of a touch-tone menu: where the scenario breaks
The touch-tone menu was designed for push-button phones and the logic of “choose from five options.” Today, a caller listens to the greeting and options tree for 40–70 seconds, keeps the item numbers in mind, and still ends up in the wrong place: the wording in the menu does not match how a person describes their task.
The longer the tree, the higher the share of those who listened to the end — but never pressed a single digit.
The main losses are concentrated on the inbound line. Call drops occur even before connecting to an operator: the caller hangs up at the third nesting level, not understanding which item applies to their case.
A separate category is stalled branches, where the call hangs waiting for a keypress, and the person is silent because they didn’t hear the option or got distracted. In total, this produces a noticeable share of contacts that never reach an agent.
Contact routing suffers after connection as well.
The touch-tone menu has only one classification axis — the selected digit — so false transfers to an operator come in a stream: the client presses “other” to avoid listening to the rest of the menu and occupies a live line with a trivial question.
The speech scenario does not participate in this scheme at all — it comes down to a set of prompts, not to parsing the caller’s wording.
Rigid binding to keys deprives the inbound line of flexibility: adding a new scenario is possible only by re-recording the voice greeting, and understanding exactly where people drop off is almost impossible, because the logs show the selected item but not the reason for leaving.
We look at how this is solved by a voice bot that accepts free-form speech and bases routing on the meaning of what is said.
What changes after moving the line to a voice bot
Before the line is moved, a caller goes through the touch-tone menu: they don’t remember which digit is responsible for the needed service, make a mistake at the second level, and drop the call before even reaching the queue.
The voice bot accepts the goal in words — “check request status,” “reschedule a visit,” “connect me with a technician” — and immediately launches the needed scenario.
The shifts after this are measured by metrics taken from the same telephony: automation rate, operator workload, waiting time, line availability.
Automation rate. For typical scenarios — informational questions, statuses, confirmations, rescheduling — 60–70% of contacts are resolved without an operator.
The rest is not a refusal but a deliberate transfer to a human who has already received the recognized intent and conversation context.
Operator workload. The first line stops acting as a filter: the operator does not spend the first minutes clarifying the goal but immediately conducts a substantive conversation.
During peak hours, this is the difference between a queue and handling the flow — the workload levels out instead of rising in a step.
Waiting time. Routing is based on the goal, group skill, and current load, so connection to a specialized agent happens on the first transfer, not after wandering through menu levels.
We separately measure the share of abandoned calls before connection — it falls along with menu depth.
Line availability during peak hours. The bot holds parallel calls and does not return “busy”: if no operators are free, it stays on the line, completes the request, queues it, or resolves it itself.
We connect the speech layer to your telephony — from Asterisk to a cloud PBX — without changing the number or making breaking changes.
Dialogue modes: comparison of approaches and limitations
Before choosing where the bot fits into the voice scenario, it is worth separating the levels: speech recognition, dialogue logic, and transfer of the call to a human. The dialogue mode determines how many steps the client goes through on their own and where an operator connects.
Below are working configurations that we build on telephony platforms such as Avaya: they differ not by the “intelligence” of the model but by the cost of an error and the depth of integration with the CRM system.
| Mode | When it fits | Limitations |
|---|---|---|
| Full menu replacement | Same-type contacts: balance, request status, appointment, cancellation | Complex wording is recognized with errors; an emergency exit to a human is needed |
| Hybrid scheme | Menu for short paths; the bot intercepts everything that didn’t match an item | Synchronization of two logics is needed, otherwise the client explains the problem twice |
| Bot only at the entry point | Classification of the contact and routing to the right group | Does not remove operator workload, only reduces the number of transfers |
| Free dialogue | Appointment booking, consultations with branches and clarifications | Sensitive to noise and industry terminology; takes longer to configure |
| Fast escalation to an operator | Peak loads, complex products, strict response times | The gain at the entry is lost if transfer rules are configured too broadly |
The limitations of a mode are not a verdict but a set of parameters: the recognition confidence threshold, the number of clarification prompts, trigger phrases for escalation, and the rule for passing context along with the call.
We log every transfer to an operator, so it is clear which wordings the bot failed to parse and what is worth additionally training.
How implementation proceeds: from call audit to handover
The order of work here is not a formality: each next step relies on data from the previous one.
If you design the dialogue scheme immediately without auditing recordings, the bot resolves 10–15% of the flow instead of half — simply because the branches are built for invented questions, not for how people actually call.
- Contact audit: we export recordings, label them by topic, calculate shares — how many calls are resolved without an operator and where people hang up in the touch-tone menu. The output is a list of topics with automation potential and those that should not be given to the bot.
- Dialogue scheme: we build branches for the real wordings from the audit, separately describing behavior when there is no understanding and escalation to an operator with context transfer.
- Configuration and connection: we connect the bot to telephony and the CRM system, and configure recognition for your vocabulary — service names, SKUs, names.
- Test run: we run the scheme on recordings from the audit and on scenarios with interference — poor connection, interruptions, dialect. We fix it before going live with real calls.
- Testing on real traffic: we enable it on part of the flow, compare with a control group of operators, and manually review disputed dialogues. We expand the share only with stable metrics.
- Acceptance: we fix the criteria — the share of dialogues without an operator, the share of erroneous transfers, time to answer. We check on a sample together with your team, not by our own reporting.
- Handover to support: we provide documentation on branches, change regulations, and a monitoring panel, and train your team to change scenarios and wordings independently.
Documentation, dialogue schemes, and handover regulations
Handing over a voice bot is not only a working service but also a set of artifacts by which your team can independently maintain it. We fix the documentation scope before work starts, and at handover we check that each item is up to date with the current version of the scenario. Below is what the customer receives.
- Dialogue branch scheme — all forks with transition conditions: where the call goes when a phrase is not recognized, during silence, during repeated clarification, and at what depth a human connects. The scheme is maintained in a single format suitable for edits without a developer.
- Escalation rules — triggers for transfer to a live operator: how many failed recognition attempts count as a failure, how emotional language is handled, which topics immediately go to a human, and how the call is queued by priority.
- Recognition and routing settings — dictionaries of terms, product and job titles, confidence thresholds at which the bot asks again instead of acting at random, rules for distribution by operator skills, and a working hours calendar.
- Operator instructions — what the employee sees when a call is transferred: speech transcription, already collected data, attempt history; how to accept the conversation, how to return it to the bot, and how to mark the reason for manual intervention.
- Change regulations — the procedure for editing the scenario: who approves a new branch, in which environment it is tested on recordings of real calls, and how rollback to the previous version is performed if the edit worsened the result.
- Contact log and reporting — labeling of call completion reasons, the share of routes resolved by the bot without an operator, a list of phrases that are most often not recognized — the basis for planned improvements to the dictionary and branches.
Documentation is updated together with the scenario: an edit not reflected in the scheme and regulations does not pass acceptance. This way the solution remains manageable by your own forces, not only by our team.
Case study: reduced drops on the inbound line and relieved operators
Before the project, the inbound line relied on a four-level touch-tone tree. Analysis of recordings showed: 18% of calls dropped right in the menu — the caller did not wait for the fourth level and did not understand which digit to press.
Average time to a live specialist was 3 minutes 40 seconds; during peak hours the queue reached 11 minutes, and some of those calls were lost entirely.
What was restructured
The touch-tone tree was replaced with a single open question: the caller states the reason for the contact by voice, the model determines the intent and guides them along the right branch.
Six scenarios were retained that cover most contacts — request status, blocking, service activation, plan change, payment, complaint.
Each branch ends either with an automatic resolution or with transfer to an operator with already collected context: contact type, contract number, history. The operator does not ask again — they immediately work on the substance.
Metrics before and after
- Drops on the inbound line: 18% → 4%
- Time to specialist: 3:40 → 0:50
- Share of contacts resolved without an operator: 0% → 62%
- Operator workload at peak: minus one third
Conversations and requests are stored in Bitrix24: the operator sees the contact history before picking up the phone, and the line manager sees a report on the share of automatic resolutions.
Drops are no longer a bottleneck: the line handles peak load without expanding the shift, and the freed-up operator time went to complex cases where automation still yields to humans.
What to do if the menu is already working and cannot be broken?
A working menu is not technical debt but an active service loop: the number is printed on business cards, in advertising, and in contracts, and a direct replacement will result in lost calls during peak hours.
Therefore, the speech layer is placed on top of the tree, not instead of it, and as a first step we move into it only those branches where the scenario is predictable.
The entry point remains the same: the call comes to the same number, but the bot now answers it.
It recognizes the intent and, if confidence is above the set threshold, conducts the dialogue itself; if below, it transfers control to the existing menu branch, and the caller continues pressing the same keys as before.
The phased transition relies on parallel operation of two loops. Routing rules divide the traffic: first, a narrow group of scenarios goes through the speech layer — request status, appointment, balance check — while the rest goes to the familiar branches. We increase the share of calls as support resolves issues with wording and dialogue logic.
The fallback route remains after launch: old branches are not deleted but remain as an emergency path.
Switching between the bot and the menu is a setting on a running system, without a release or line interruption: if a scenario gets in the way, it is disabled for the needed group, and the next call follows the previous scheme.
Zero-downtime migration follows as a consequence: started conversations are completed according to the logic with which they began, while new ones follow the new conditions.
Rollback remains a single setting, and the share of dialogues resolved without an operator shows which branch the speech layer is ready to take over entirely.
Technical doubts: recognition, noise, and interruptions
Doubts before launching a voice bot are usually engineering-related: how recognition holds up on a noisy line, what happens during interruptions, where personal data is stored, and how the bot’s response gets into the CRM system.
How does recognition behave with noise, accents, and fast speech?
The stream is sliced into short frames: noise reduction removes constant background, echo cancellation removes the reflection of the bot’s own voice, and automatic gain control levels out quiet utterances. The model is tuned for the telephone band, not studio recording.
A dictionary is assembled for the task — names of services, cities, codes — and request numbers and amounts are recognized character by character.
During configuration, we run recordings of real calls and calculate the share of correct answers for critical fields, not the average across the dialogue.
The caller interrupts or is silent — what does the bot do?
The utterance end detector distinguishes a pause for breath from the end of a phrase, so the bot does not cut into the middle of an answer. When interrupted, it falls silent and listens, without finishing its prepared line.
For silence, a waiting time and a rule for transfer to an operator are set — the dialogue does not hang.
Where are conversation recordings and personal data stored?
Recordings and transcripts remain in the customer’s agreed environment, access is role-based, and the retention period is set by policy. Card numbers, confirmation codes, and other sensitive fragments are masked before recording. For individual scenarios, recording can be disabled.
How does the bot integrate with the CRM system?
Exchange goes through a software interface: the caller is identified by number, the bot checks the contact status, creates a request, and writes the conversation result to the card.
If the system is unavailable, the bot logs the contact and transfers it to an operator — the caller does not hear an error and is not left without an answer.
Let’s discuss the task: what data is needed for an estimate
The speed with which we return with an estimate depends not on the volume of the description but on the completeness of the input data.
One conversation and what is already available in the line’s operation are enough — we will analyze the recordings ourselves and show where the voice bot will resolve the contact without an operator and where the conversation will have to be transferred to a human.
- Contact recordings — 20–30 real dialogues from different hours and days, including those where the caller hung up or waited for an operator. They reveal the vocabulary, background noise, utterance length, and the share of non-standard wording.
- Routing scheme — which lines and numbers are serviced, by what criterion a call goes to a specific department, and what is considered a correct transfer rather than a lost client.
- Line limitations — how many calls the channel holds simultaneously, whether there is a queue, how telephony behaves under overload, and what happens to a call when a node fails.
- Reference data composition — a list of services, addresses, timeframes, request statuses, and frequent questions that the bot should access. If the reference is maintained as a table, send it as is — we will sort out the format ourselves.
- What changes after the call — appointment booking, request creation, data transfer to the CRM system, sending confirmation to the caller.
- Acceptance criteria — what share of callers the bot helps without an operator, what we consider a recognition failure, and where we return the call in that case.
If some data is missing, it is still worth starting the task discussion: using the recordings and routing scheme, we will reconstruct the rest and return with a project estimate and a stage-by-stage work plan — with a verifiable result at each stage.