What changes after implementation: measurable effect
The effect of voice outreach is measured not by the number of calls launched, but by the share of dialogues that reached the end and provided answers suitable for analysis.
Below are the metrics we capture before and after launch so that the result can be measured rather than taken on faith.
Share of completed interviews
The bot does not cut off the conversation at the first "not a good time to talk": the scenario can reschedule the call to a convenient time and return to the client, and if a phrase is unrecognized, it can ask again without losing the thread of the conversation.
For those who are not ready for a long conversation, there is a short branch of 3-4 questions. Together, this raises the share of completed interviews from a typical 25-35% to 60-75% on the same database and at the same time of day.
Processing speed and team workload
Answers go to markup immediately after the call: customer loyalty index is calculated from completed interviews, the sentiment of open-ended answers is determined by a classification model rather than manually.
The time to a finished report on a survey wave is reduced from days to hours, and the load on operators drops: they only get involved in escalations — clearly negative tone, a request for a live person, or a dispute about a service.
The speed of processing answers no longer depends on sample size: a thousand calls and ten thousand are processed in the same cycle.
Loyalty index and sentiment of answers
The customer loyalty index ceases to be a single averaged number: the report shows distribution by segments, touchpoints, and regions, and negative feedback is tied to a specific stage of service.
The sentiment of open-ended answers is broken down by topics — where customers name the reason for leaving, where they praise a specific service. This provides a basis for the next survey wave: questions are refined based on hot topics rather than guesses.
Methods of collecting voice feedback: comparison
The difference between approaches is not in the recording quality, but in who leads the dialogue and what happens with a non-standard answer. Below are four schemes that are actually chosen between when launching voice surveys.
| Option | When it fits | Limitations |
|---|---|---|
| Live operator | Short samples, complex topics, need for clarification | Scales poorly, interviewer's manner biases answers, quality depends on shift |
| Classic auto-dialer with voice menu | Mass short surveys of 1–3 questions | Tone input confuses, drop-off in the middle, cannot find out the reason for the rating |
| Intelligent dialogue with speech recognition | Open-ended questions, need respondent's wording | Requires a clean channel and tuning to industry lexicon |
| Hybrid outreach | Bot handles the flow, operator handles complex cases | Requires transfer logic and preservation of conversation context |
Recording and automatic transcription
The conversation is recorded in full and goes to transcription: the output is text marked up by utterances and sentiment. This makes it possible to return to a disputed rating and see at which question the respondent began to falter. We store audio separately from text — with its own retention period and access rules.
Survey with transfer to operator
The hybrid scheme starts with the bot: it asks the scale, recognizes speech, and records ratings.
If the person asks again, falls silent, or gives a sharply negative review, the call is transferred to an operator along with the already collected context — the operator does not start the conversation over.
Stages of implementing a voice AI bot
The voice AI bot asks questions in a live voice, and the order of stages here is not accidental: first we analyze what and how we ask, then we teach the bot to speak and hear, and only then release it to customers.
We test recognition on real phrasings, and the trial run goes on part of the database — a mistake costs a dozen calls, not the entire sample.
Audit of current scenarios
- Audit of survey scenarios. We analyze existing questionnaires: we note questions that sound ambiguous in oral speech, long answer options, confusing transitions. The output is a map of questions with a decision on where a short answer is enough and where a scale is needed.
Setting up dialogue and testing on real calls
- Setting up dialogue scenario. We assemble branches, confirmation phrases, reaction to "I don't know" and refusal to answer; we set how many times the bot can ask again before recording "no data."
- Recognition testing. We run recordings of conversations with different diction, pace, and background noise, compare with manual transcription, and adjust the dictionary for specific phrasings.
- Calibration of sentiment assessment. On manually labeled fragments, we clarify what we consider neutral and what is irritation or doubt.
- Trial run on part of the database. The bot calls a small group of contacts, we compare results with a control outreach by operators, and adjust the scenario based on facts.
- Handover of regulations. We provide instructions on editing questions, analyzing disputed answers, and exporting reports, with responsible persons for each operation.
What we hand over: configurations and regulations
We hand over not accesses or a "link to the bot," but a working loop with documentation that the customer's team can use to edit the scenario and handle incidents themselves. Below is what exactly is handed over along with the solution.
Configurations and dialogue schemes
- Dialogue scheme: question branches, exit points, silence timeouts, handling refusals to answer and requests to call back later.
- Configurations of the scenario and phrase sets in a version-controlled repository: editing wording and branching logic does not require a code deployment.
- Rules for calculating NPS and CSAT, logic for re-asking and re-dialing, boundaries of sentiment analysis, and the procedure for labeling disputed answers.
- Separate environments: a test loop with reference dialogues and a production one, where changes go only after a run-through.
Policies for access to recordings
- Role separation: who has access to aggregates, who to transcriptions, who to audio recordings, plus a log of accesses to recordings.
- Retention periods and auto-deletion of recordings, anonymization before export outside the loop.
- Escalation regulations: which answers and sentiment trigger transfer to an operator and within what time the operator must make contact.
- Instructions for operators: how to read the transcription, what to record in the card, how to close negative feedback.
- Survey reports: a dashboard on metric dynamics, methodology for their calculation, and export to the customer's storage.
Case study: customer survey after a service request
A service center surveyed customers after each closed request: repair quality, timelines, engineer politeness. The survey relied on outreach — operators called down the list, recorded the rating, and manually retold open comments.
The sample was biased: they reached those who pick up the phone during working hours, while others fell out of the picture.
Situation before implementation
Outreach stretched over two weeks after the request was closed — by that time customers no longer remembered details and more often refused to talk.
The response rate held at about 14% of closed requests, and this was not a random sample: it mostly included customers without complaints.
Open-ended answers were processed manually, no one calculated sentiment. Systemic causes of dissatisfaction — waiting for a spare part, a repeat visit for the same fault — did not surface in reports: the service manager saw an average score and did not see what stood behind it.
Result by metrics
We deployed a voice AI bot on outbound scenarios: it calls within an hour after the request is closed, asks questions on a scale, and clarifies the reason for a low rating with an open question. Transcriptions and sentiment assessment go to Bitrix24 as a deal card, without manual entry.
- Increase in response rate: 14% → 61% of closed requests, sample bias eliminated — the bot calls even outside working hours.
- Reduction of manual outreach: a line of three operators was freed up completely, manual work remained only for handling escalations.
- Time to survey: two weeks → one hour, the customer rates the request while it's fresh.
- Sentiment on open-ended answers: coverage grew from zero to all comments, topics are grouped automatically.
A side effect that the customer did not include in the task: negative feedback on repeat visits became visible on the second day, not in the quarterly report — engineering teams began to address such cases promptly.
How does an interactive survey differ from auto-dialing?
Auto-dialing is a rigid sequence: the system dials the database, reads questions in a fixed order, accepts a key press or a short answer, and ends the call on timeout. As long as the respondent fits the template, the scheme works.
As soon as they answer "depends on which branch" or start explaining — the answer is either lost or falls into the general "other" category, and noise appears in reporting instead of an assessment.
An interactive survey is built on a dialogue scenario, not on a list of questions.
The voice bot recognizes the meaning of the utterance, not just a key press, holds the context of previous answers, and asks clarifying questions: "What exactly is inconvenient — speed or paperwork?" The branch is chosen based on the answer, so the depth of the interview depends on how much the respondent is willing to tell, not on the length of the questionnaire.
The key part of the scenario is transfer to an operator. Escalation triggers not on everything, but according to rules: low recognition confidence, a confrontational utterance, a direct request to call a person, a repeat of a question.
Then the complex case goes to a live employee with already collected context, rather than being cut off.
For NPS and CSAT, this is the difference between a rating and its cause. With auto-dialing, the share of completed interviews drops on long questionnaires, and open-ended answers are monosyllabic.
With a dialogue bot, there are more conversations brought to completion and more detailed phrasings — sentiment analysis gets material that shows what to fix, not just the final number.
Technical concerns: recognition accuracy and languages
Recognition accuracy is determined not by the model, but by the channel: noise, compression, speech overlap, accent, and dialect.
That is why we do not cite a percentage "out of thin air" — before launch, we run transcription on the customer's real recordings and show the share of correctly recognized words and, more importantly, the share of correctly determined ratings and sentiment.
What to do about noise and poor connection?
The stream is segmented by a speech detector: silence, fragments, and overlap are cut off, and recognition confidence is calculated for each answer.
If it is below the threshold, the bot does not guess for the guest — it asks again once, then marks the answer as unrecognized and sends it for manual review. The share of such recordings is measured separately.
How are multilingual surveys structured?
The language is selected before the first question: by campaign, by number, or by the guest's voice.
The recognition model and sentiment analysis rules are configured for each language separately — they cannot be transferred without testing, as markers of dissatisfaction are expressed differently in different languages. Short insertions in another language are recognized as standard.
How are recordings stored and how is consent obtained?
Consent is voiced at the beginning: the bot reads a notice and records the fact with time; if refused, the conversation ends and data is not saved.
Audio lives in a separate storage for a limited period according to the lifecycle policy, while the transcription, ratings, and metrics remain indefinitely. Withdrawal of consent and export on request are processed from the archive.
Let's discuss the task: where implementation begins
Implementation of a voice AI bot begins not with code, but with analyzing the task: who is calling, why, on what scale, and what is considered a successful call.
A substantive conversation at the start saves weeks of rework — the scenario, branches, and acceptance criteria are fixed before the first number is dialed. We need a minimum from you, the rest we gather ourselves.
- Dialogue scenario: list of questions, order, branches for refusal, re-asking, silence, and connection loss.
- Scales and wording: texts of NPS and CSAT questions, open-ended questions for sentiment analysis, rules for assigning a review to a class.
- Contact source and outreach rules: time windows, number of retries, consents for data processing.
- Integrations at the start: telephony, CRM, or storage where recordings, ratings, and transcriptions are stored.
- Reference sample: several dozen labeled recordings — we calibrate speech recognition and sentiment on them.
- Acceptance metrics: share of completed surveys, share of correctly recognized utterances, accuracy of review classification.
After discussing the task, we return with an estimate of timelines and a draft implementation plan. The first stage of work is a pilot on one segment and one scenario: it shows real quality on your subscribers and does not require costs for access to them. Only after the pilot is accepted do we expand coverage and add new survey branches.
To make the estimate accurate, prepare in advance: a list or export of contacts, agreed-upon question texts, and the contact of the person responsible for acceptance. This is enough to name the set of requirements for launch and the order of work.