Voice AI bot in the contact center: where the dialogue breaks
A first-line conversation most often breaks not on a complex question, but at a handoff. A caller waits in the queue for 40–60 seconds, hears "your call is important," and hangs up — this is a typical missed contact that no one will see in a quality report.
A voice AI bot connected after the voice menu removes part of the load, but it does not shift the peak of missed calls.
Worse is a break during transfer to an operator. The bot has found out the essence of the question, but passes up "client is checking on a request" — and the operator starts the dialogue from scratch, even though the context already sits in Bitrix24.
The caller repeats what they dictated twice, incoming call handling time grows, and the share of repeat contacts within 24 hours reaches a third.
For a department head, this looks like a growing number of contacts with an unchanged staff: repeats fall into the same queue.
First-line automation that counts only "share of dialogues closed by the bot" distorts the picture — a repeat call after an unsuccessful transfer passes as a new contact, and the metric becomes more optimistic than reality.
A separate category of losses is silence at the moment of transfer. A pause of 5–8 seconds without feedback is read by the caller as a dropped call; they start speaking again or call back a second time.
Below we look at how this is closed: where to place speech recognition, what necessarily goes to CRM along with the call, and how to calculate the closure metric without double counting.
What changes after implementation: measurable effects
Before implementation, the bottleneck of the call center is human throughput: during peak hours the queue grows, at night the line is silent, and the quality of handling depends on who picked up the phone.
The robot takes over the repetitive part of the flow, and the effect is calculated from the call log.
Response time
The robot answers on the first or second ring around the clock: queue waiting drops from tens of seconds to a few, and at night — from "no one answered" to the standard. The telephony loop on FreeSWITCH holds calls without degradation while operators are busy.
Share of automated contacts
Typical reasons — request status, appointment booking, address confirmation — are closed without a human: 6-8 contacts out of 10. The rest go to an operator with a transcript and dialogue context, not from scratch.
Operator workload relief
Operators stop being the first filter and take on complex cases. Repetitive conversations leave their day, the workload evens out: peak hours no longer require overtime and temporary shifts.
Peak loads
Line capacity grows through channels, not hiring: the robot absorbs the surge, queues the call, and calls back when a line becomes free. The share of lost calls during peak drops to a statistical error.
A vanished class of failures
Abandoned calls, "call back later," and requests lost outside working hours are gone. The robot follows one scenario and records in the accounting system exactly what it says into the phone — there are no more discrepancies between script and conversation.
Implementation options: cloud, on-premises loop, hybrid
The placement of the voice bot determines not only launch speed, but also where the conversation recording and transcript text physically end up.
Before choosing a scheme, we calculate the load profile: peak number of simultaneous channels, share of calls with long speech, recording retention depth, and acceptable response delay.
These figures determine whether the solution can withstand a seasonal surge without degrading recognition quality.
Three schemes cover almost all scenarios — from a quick launch to a loop that never leaves the customer's perimeter.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud voice bot | Launch needed within weeks, traffic is uneven, peaks are several times above average | Recordings and transcripts go to an external loop, explicit data processing agreements are required |
| On-premises loop | Speech is sensitive data, GPU capacity and an in-house operations department are available | Long launch cycle, capacity is fixed — equipment reserve is needed for peaks |
| Hybrid scheme | Data control is needed for recordings, but scaling for peaks is external | Harder to connect the two parts, a separate synchronization and monitoring loop is required |
The key question is one: can voice data leave the perimeter. If yes — a cloud voice bot provides a quick start and channel scaling without purchasing capacity. If no — we calculate the on-premises loop based on peak load.
The hybrid scheme takes a compromise: recognition and storage stay inside, while heavy short-term tasks are moved outside.
Implementation stages: from call audit to handover to operation
Implementing a voice bot is not "turned it on and it works," but a sequence of steps where each ends with an artifact that can be checked before moving to the next.
The order matters: first we count real data, then we design the dialogue, and only then do we connect telephony.
- Call audit. We export recordings for a representative period, label them by contact type, and calculate what share of scenarios repeats — usually these are the ones that go to the bot, while rare ones stay with people.
- Scenario map. We build a dialogue tree: utterances, transition conditions, mandatory clarifications, and escalation points to an operator where the bot does not try to guess.
- Telephony integration. We connect to the existing PBX and number, configure routing, transfer to a live operator, recording, and storage of conversations according to your rules.
- Recognition and response setup. We add dictionaries of terms and names, work through pauses, interruptions, and background noise — this determines how many calls are closed without a human.
- Testing on real traffic. First shadow mode: the bot listens to calls and suggests an answer without talking to the caller. We review discrepancies with the operator before launch.
- Pilot operation. We enable it on a portion of calls, monitor the share closed without an operator, the frequency of incorrect recognitions, and time to response.
- Go-live. We hand over access, regulations, dashboards, and a rollback plan, then continue training on new recordings according to an agreed cycle.
What we hand over to the customer: scenarios, integrations, regulations
A voice bot stays in production exactly as long as the customer's team can manage it without us.
Therefore, the end of the project is not a demo call, but a package of artifacts: for each one it is clear what to change for a new customer wording, where to look during a failure, and who is responsible for the edit.
- Dialogue map — all branches with forks and dead-end responses: you can see where each utterance leads and where the bot asks an extra clarifying question. Logic is edited from it without rebuilding the model.
- Integration scheme — connection to telephony, the accounting system, and the operator queue: what data goes both ways, where the failure points are, and what happens when an adjacent system is unavailable.
- Escalation regulation — conditions and moment for transferring a call to a live operator, the composition of the card before pickup, and the bot's behavior if no operators are free.
- Access rights and roles — who changes scenarios, who only listens to recordings and exports statistics, how access is granted and revoked when an employee leaves.
- Operator instructions — how to accept a transferred dialogue, what to do with uncertain recognition, and how to mark a bot error so it enters retraining.
- Set of reference dialogues — scenarios with expected bot behavior: every update is run against them before release, so editing one branch does not break neighboring ones.
- Support regulation — how phrases and dictionaries are updated, how often recognition quality is checked, and by what metrics it is decided that a scenario needs rework.
Documentation remains in your perimeter and is updated together with the bot — the solution does not turn into a "black box" that can only be switched off.
Case study: AI on the contact center first line
The pilot was launched in one department, where the share of typical contacts exceeded 70%: appointment booking and rescheduling, request status, reminders.
The voice bot answered the call first, conducted the dialogue according to the regulation, and transferred only cases with exceptions and complaints to an operator.
The telephony was not changed — the integration was assembled through the standard interfaces of the Asterisk platform.
In the first weeks, the bot worked in backup mode: the operator heard the dialogue and could intervene, and discrepancies were reviewed every morning.
It turned out that with noise on the line the bot starts asking again — we added a clarifying question and a recognition confidence threshold below which the call immediately goes to a human.
Metrics before and after
| Indicator | Before pilot | After |
|---|---|---|
| Contacts closed without an operator | — | 62% |
| Time to first response | 40–50 seconds | 2–4 seconds |
| Missed calls during peak | 18% | less than 2% |
| Average operator conversation duration | 4 minutes | 6 minutes — only complex topics |
| Operators in peak shift | 12 | 8 |
The peak shift is now covered by fewer operators, and the freed-up time went to complex contacts. The share of customers who ask for an operator themselves holds at around 5% and does not grow — this was the main criterion that the bot is not annoying.
Feedback from the department head
"Previously we covered peak with overtime and still lost calls. Now the first line handles the load with a standard shift, and operators deal with those who really need a human."
How does a scripted dialogue differ from a generative response?
A scripted dialogue is a state graph: for each caller response, a transition and the next utterance are predefined. Behavior is deterministic: heard "yes" — we go to confirmation; silence — we ask again and return to the fork.
Predictability is absolute, so the script takes on customer identification and collection of mandatory fields.
A generative response is assembled by the model on the fly based on the conversation context. It handles atypical wording — the caller speaks out of order, dictates a number with pauses, asks off-script — and maintains natural intonation.
The price is variability: the same input produces different answers, and the risk of error cannot be reproduced and fixed by editing one branch.
The cost of an error differs in nature. In a script, a failure is local: you can see at which step the transition did not work, and the fix takes minutes.
In generative mode, an error can be semantic — the bot confidently states an incorrect condition — and such cases are the most expensive in a call center.
Therefore, we assemble a mixed mode: generation is responsible for understanding free speech and clarifying questions, while critical actions — request confirmation, stating conditions, recording consent — go through a scripted graph with rigid transitions.
Below the recognition confidence threshold, the bot does not guess but transfers the conversation to an operator.
We set the boundary not by eye: for each step we determine what is more important — coverage or accuracy — and choose the mode accordingly. Predictability remains where an error is costly, and generation — where flexibility is needed.
Frequently asked questions before the pilot: load, delays, integrations
Before the start, the customer checks the same nodes: peak load, pauses in the dialogue, speech recognition quality, and the fate of recordings. We explain how each is addressed technically.
What will happen to the line during a seasonal surge?
The number of simultaneous dialogues is limited not by the server, but by channel throughput. We calculate the profile based on peak hours and build in a reserve; when it is exhausted, the call goes to a queue with a callback rather than being dropped.
Will the caller hear a delay in the response?
The response is synthesized in a stream, so the pause between the question and the start of the answer stays within the bounds of a live conversation. There is a separate threshold for interruption: the bot falls silent and listens to the end.
How accurate is speech recognition?
On a noisy line and with a strong accent, accuracy drops — this is a limit of the technology, not an implementation defect. That is why the scenario includes re-asking and confirmation of key data: number, date, order details.
Where are recordings and transcripts stored?
Audio and contact cards are stored in your perimeter, with encryption in transit and at rest. Retention period and depth are set by policy: recordings can be anonymized and stored only as text.
How does the bot transfer the dialogue to an operator?
Transfer follows rules: the caller asks for a human, the scenario goes beyond its scope, a negative signal triggers. The operator receives the call with a transcript and collected data, so they do not ask again from scratch.
Let's discuss the task: we'll analyze the call flow and come back with a plan
To come back with an estimate and a plan, rather than general words, we need a little from you: recordings of 20-30 real calls, access to a test number on your telephony, and a list of scenarios the bot should close on its own. This is enough to estimate the scope of work and give timelines.
- We analyze the call flow: we count the share of typical contacts, dialogue length, peak hours, and at which step calls are currently lost.
- We agree on scenarios: what the bot closes on its own, where it transfers to a live operator, and what data it must collect before transfer.
- We fix the implementation plan: stages, responsible parties on both sides, and points where it is possible to stop without losses.
- We estimate the scope of work: how many scenarios will be in the first version, what integration with telephony and the accounting system is needed, and where the risks are for speech recognition quality.
- We launch a pilot on one number and a limited group of scenarios — comparing the result with the current call center indicators.
- We set up handover to operation: dialogue quality control, edit regulations, and the procedure for retraining on new wording.
- We hand over documentation: routing scheme, rules for transfer to an operator, and instructions for shift administrators.
Describe the task — channel, approximate number of contacts, what hurts the most. We will come back with an implementation plan, scope estimate, and pilot composition.