AI auto-dialing for CSAT and NPS: where feedback collection breaks
The usual feedback collection looks like this: after a visit or closing a request, line employees take on the calling — between shifts, workload, and targets.
A day, sometimes two, passes between contact with the customer and the call, and the person recalls the event from residual impressions. The CSAT survey score turns into an averaged “generally fine” instead of a reaction to a specific episode.
The call reach rate is the first thing that breaks. The call goes out in a single pass, during business hours, to the number from the request, without retries and without considering that the customer is busy.
As a result, the calls reach those who answer more often, and that is either the most loyal part of the base or, conversely, random people.
The sample stops resembling the real customer flow, and any NPS survey based on it produces a number that cannot be extrapolated to the entire service.
The second bottleneck is who asks the questions. When the same employee whose work is being evaluated asks for a rating, the customer activates politeness: high scores despite real dissatisfaction, closed scales without explanations.
The open-ended part — “what exactly went wrong” — is either lost or retold by the employee in their own words, and what reaches the review is already a retelling, not the original wording.
The third is delay. While feedback is collected manually, a day or more passes between a service failure and a signal in reporting. By the time a manager sees the failure, it is already impossible to fix the situation for those customers; there is only post-mortem analysis left. Let’s look at how this is addressed.
What changes after launch: coverage, speed, refusal rate
Automated calling removes the main limitation of manual surveys — selectivity. A voice robot goes through the entire base, not a convenient sample, and the call reach rate stays at 60–70% versus 15–20% for manual attempts during business hours.
A schedule is in effect: a call during the hours when the customer usually answers, a retry in 2–3 hours after an unsuccessful call, separate logic for voicemail and a busy line. Contacts that previously simply were not reached now enter the survey.
The speed of feedback collection is measured in days, not weeks. The survey is launched an hour after delivery or closing the request — the customer still remembers the details and answers more specifically than after a week.
Ratings arrive in the summary as they come in: survey coverage is visible in real time, not in a report for the previous quarter.
The score and the transcript of the answer go into the customer card in Bitrix24. A low rating immediately creates a task for the manager, and the customer is brought back into work before they go to a competitor.
This is the churn reduction mechanic: dissatisfaction is recorded at the stage when it is still cheaper to resolve than to compensate.
After launch, we compare four metrics: call reach rate, median time to first rating, base coverage, and the share of repeat contacts among those who gave a low score. Let’s look at how to calculate these indicators and where to output them.
AI auto-dialing formats: robot, hybrid, and live operator
The three modes differ not in speech quality, but in where a person appears in the dialogue and how much freedom the script retains.
The robot conducts the conversation along a marked-up reply tree: it confidently goes through rating scales and short closed questions, but gets lost where the respondent starts telling a story.
The higher the share of open-ended answers, the earlier a person must be introduced into the scheme.
The choice of survey format is determined by three things: permissible variability of the answer, the cost of an interpretation error, and requirements for personal data processing.
Mass scale-based measurements are handled by the robot; analysis of churn reasons and work with complaints — by a hybrid or a human.
Where the boundaries of the modes lie
| Format | When it fits | Limitations |
|---|---|---|
| Robot calling | Short scale-based surveys, mass samples, repeated measurements on the same base | Holds the script but does not re-ask based on meaning; recognizes open-ended answers with losses, and the share of dropped calls grows against a noisy background |
| Hybrid calling | Mixed surveys: scales plus clarifications, there is a share of respondents who need a human | Requires escalation rules and transfer of dialogue context to the operator — otherwise the human repeats everything from scratch |
| Live operator | Conflicting topics, retention of key customers, legally significant questions | Human factor: different manner of speaking, fatigue by the end of a shift, discrepancies in answer coding |
The modes are not mutually exclusive: the script is one, but the branches within it are different.
Answers go into the same fields, so scales from an automated wave are comparable with hybrid and manual ones — the choice of format changes the depth of the answer, not the basis for comparison.
How implementation proceeds: from base audit to handover
We do not rearrange the order of stages: script development depends on what is actually in the base, and the decision on a full launch depends on the results of a test on part of it.
Below is what the work looks like from the first conversation to the moment when the system calls customers without our involvement.
- Study of the current survey. We look at how ratings are collected now: questionnaires, operator calls, exports from the accounting system. We record at which step the main share of answers is lost and which questions yield contradictory data.
- Contact base audit. We bring numbers to a single format, remove duplicates and outdated records, check consent for calling, mark segments and stop lists. The output is an understanding of which part of the base can be correctly called.
- Dialogue script design. We write out the branches: greeting, rating scale, clarifying questions, response to refusal, transfer to an operator in case of a complaint. Separately — how the system re-asks if an answer is recognized with low confidence.
- Integration setup. We connect telephony and the accounting system: the rating, transcript, and call recording go into the customer card, not a separate file. We configure rules by which a low rating goes to the responsible person immediately.
- Test on part of the base. We launch on a small share of contacts and look at measurable things: call reach rate, share of correctly recognized answers, discrepancy with manual listening of the sample. Here we also refine the wording.
- Handover to operation. We provide access, a regulation for script edits, instructions for operators, and reporting. After that, calling proceeds without us, and changes are made according to the described procedure.
What the client receives: scenarios, access, regulations
We consider the project delivered not at the moment of launching the calling, but when your team itself changes the survey logic, connects new customer segments, and troubleshoots failures without our involvement.
That is why we hand over not “access to a service,” but a package: reproducible configurations, access differentiation, and written regulations according to which you can work and pass tasks within the company.
- Scenario schemes — a branching tree with exit points: refusal to talk, request to call back, automatic transition to the rating question, and call completion conditions.
- Survey scripts — texts of CSAT and NPS questions, variants of re-asking for an unintelligible answer, wording for voicemail and voice mail.
- Integration with the customer base — field mapping, deduplication rules, export schedule, and processing of records without contact data.
- Access policies — roles for listening to recordings, viewing ratings and exports, retention periods, and automatic deletion after expiry.
- Escalation regulation — a low rating or a trigger phrase in the conversation becomes a task for the responsible person, indicating the response time and a template for replying to the customer.
- Documentation — description of scenarios and launch parameters, integration map, instructions for editing scripts and analyzing typical failures.
- Reporting — a set of campaign indicators: call reach rate, rating distribution, refusal reasons, export of raw answers for analytics.
Each artifact undergoes acceptance on your side: we show how to make a change, you repeat it yourself. After that, support becomes optional — the package is self-sufficient.
Case study: customer return after delivery and response growth
The client is a prepared food delivery chain TeploEda: several cities, its own kitchens and couriers.
Ratings were collected via a link in a message after the order, the response rate stayed at 4–6%, and the sample was skewed: mostly those who received a late or wrong order responded.
The average rating stopped describing anything — it was impossible to tell from it whether the kitchen or logistics was at fault.
What we changed and what we got
We switched to voice auto-dialing and launched it in stages: first one city, one scenario, checking transcripts against call recordings.
The call goes out 25 minutes after order closure, a 1–5 rating branches the dialogue: for a low one — immediate transfer to an operator, for a high one — one short question about the reason.
Speech recognition labels the reasons by group (lateness, temperature, completeness, courier), and 87% of dialogues close without a human.
The response rate grew to 34–38%: it is easier for people to answer by voice after delivery than to open a link. NPS rose from 21 to 44 — negative feedback began to be caught the next day, not a week later from email.
Reason labeling showed that two-thirds of complaints were not about the kitchen but about the “kitchen — courier” interface, and this yielded specific changes in routing.
Customer return is the second half of the result. Those who gave 1–3 are called back manually within 24 hours, and the share of repeat orders in this group grew by 18% over six weeks of observation. Automated dialogue analysis maintains this flow without expanding the support department.
What to do if surveys already run through an in-app form?
An in-app feedback form and voice calling do not compete — they capture different groups. The form is filled out by those who got to it themselves: more often these are loyal or severely irritated customers.
The silent majority remains unnoticed, and from one form you measure the same slice for years. A voice survey reaches those who do not open the app but are willing to spend a minute on a conversation.
The main risk when combining channels is duplication.
The customer receives a notification with a form, a call the same day, and a follow-up message a week later: this is no longer “several survey channels” but pressure, after which a rating is given in advance just to get rid of it.
This is removed by a single registry: the in-app survey and the call write the result into one record by customer identifier. Then a frequency rule works — no more than one contact per given interval per person, regardless of channel.
If the customer has already rated the order in the app, they automatically drop out of the calling queue.
The roles of the channels are distributed by situation: the form works at the moment of action, voice reaches those who do not open the app, and repeat calling goes only to non-responders.
The window for a call is immediately after closing the request, while the impression is fresh; a longer interval suits the form.
Contact frequency is set by policy at the level of the entire program, not by an individual scenario: quiet hours, daily and weekly limits, a stop list after refusal of surveys. Then the channels complement each other rather than compete for the same customer.
Technical doubts: recognition, load, integrations
Some objections surface not during the demo but at the script design stage: accuracy of recognizing non-standard answers, load on the line, consents, and connection with accounting systems. Below are four that customer engineering teams most often raise.
What happens if the customer answers off-script?
The speech recognition model is tuned to the domain vocabulary — service names, job titles, product terms. The answer is mapped to the rating scale plus free text, and fragments below the confidence threshold are not recorded by the bot as a rating; instead, it asks again once.
The share of unrecognized answers is recorded as an acceptance metric — quality degradation is visible immediately, not a month later from a corrupted sample.
Will auto-dialing block the work line?
Auto-dialing uses a separate pool of numbers and does not intersect with the incoming support line; the number of simultaneous conversations is limited, and the calling window is set by the customer's region.
The scheduler reduces the pace when the load on the contact center grows and moves the remaining attempts to the next slot instead of finishing them off the same day.
How does auto-dialing coexist with data processing consents?
The export for calling includes the consent flag and date; withdrawal is processed as a stop list, which is updated before each campaign, not once a quarter.
Unsuccessful calls and refusals are written to history — you can see how many attempts have already been made and why the customer is excluded from the list.
Where do the numbers come from and where does the result go?
The list for calling comes from the accounting system by event or schedule; the record is idempotent by customer identifier — a repeated export does not create duplicates. In return, the rating, conversation transcript, and a link to the recording go back into the customer card.
If the system has no programmatic interface, the exchange is via regular exports in an agreed format.
Let's discuss the task: we will build a scenario for your customer flow
To come back with an estimate and launch plan rather than general thoughts, we need a breakdown of your request flow.
Below is what to send in advance and what to clarify in the first conversation: using these inputs, we calculate the load on the lines, the script length, and the scope of work.
- Source and volume of the base: where the numbers come from — CRM, ticketing system, billing — and how many requests per day arrive during peak hours.
- Trigger events: after what a call is appropriate — request closure, delivery, service cancellation, repeat contact.
- Target metrics: CSAT or NPS, how you calculate them now, where you store answers, and what you will compare the result with.
- Texts and survey logic: questions, rating scale, branches to clarifying answers, languages, and regions.
- Constraints: contact consents, allowed calling hours, stop lists, repeat call rules.
- Data return: where to write answers — CRM, reporting, or your system — and which operators see them.
- People and access: the person responsible for acceptance, access to telephony and the base, desired launch timelines.
Using these inputs, we build a dialogue scenario, run it on a limited segment of the base, compare the metrics with the current ones, and only then expand the flow.
Describe the task and send what you already have from the list — we will come back with an estimate, a calling scheme, and a launch plan.