Voice AI bot in reminders: where the outbound calling scenario breaks
The task of “reminding about debt” sounds like a single line in a demo. In real outbound calling, it falls apart: the subscriber interrupts on the first sentence, asks “what amount is this about,” goes into denial, and an answering machine or relative picks up.
A robot without speech recognition, speaker diarization, and interruption handling loses the thread — it either repeats a memorized text or ends the call midway, and the subscriber calls back with a complaint.
The second point of failure is operators. Dialing, greeting, identity verification, and clarifying the amount consume almost the entire shift, and only a few reach complex cases — disputes over charges, restructuring.
Hence burnout from repetitive touches and turnover in the pool. FZ-230 adds restrictions as well: the frequency and time of touches for overdue debt are regulated, and keeping within these limits manually, spread across shifts, is impossible.
The third is recording the debtor’s responses. “I’ll pay by Friday,” a refusal, a request not to call again, the number of another contact person remain in the audio recording and reach the client’s accounting system manually.
If the response is not broken down into fields and the status is not protected from being overwritten, automated debt calling reaches a person who has already made an agreement — and the reminder scenario loses its meaning. We explain how this is addressed.
What changes after implementation: measurable effects of automated calling
Automated calling changes the unit of measurement itself: instead of “how many operators are on the line,” they measure the time to call through the base.
The contact queue is split into scheduled windows, calls go in parallel across dozens of lines, and a base of tens of thousands of numbers is processed in hours rather than weeks. Coverage of the base with reminders no longer depends on how many people showed up for the shift.
The share of automated touches grows because the bot conducts the entire conversation, and the operator connects only in specified scenarios — a dispute over the amount, a request for an installment plan, a complaint.
Attempts are distributed across morning, afternoon, and evening, so a single contact receives a call at different times and does not hit “it’s inconvenient to talk.” In practice, the share of touches reaches 80–90% versus 30–40% with manual calling.
Each response is recorded: the bot recognizes by key phrases that the person promised to pay, gave a wrong number, asked for a callback, or refused, and during the conversation writes the result to the amoCRM card.
Thanks to this, the reduction in repeat calls becomes noticeable: there is no need to call back those who have already given an answer, and disputed cases immediately go to an operator.
A separate metric is completeness of recording. With manual calling, some touches are lost: the operator does not have time to fill out the card, and the base degrades.
With the bot, the result is always recorded, so it is clear how many attempts were required, at what time the connection rate is higher, and where the scenario breaks — this is the basis for restructuring the schedule and priorities of calling.
Voice AI bot options: which mode to choose for the task
The touch mode is chosen not by convenience but by portfolio structure: the shorter the overdue period and the more uniform the reason, the higher the share of conversations handled by automation.
For long terms and disputed cases, the cost of an error in the dialogue is higher, so an operator or a hybrid scheme with transfer to a live line is needed there.
| Option | When it fits | Limitations |
|---|---|---|
| Fully automated calling | Mass segments with a repeating scenario: reminder of the deadline, confirmation of a promised payment, clarification of the reason for delay | Does not sustain the dialogue with non-standard objections — going beyond the scenario requires escalation |
| Hybrid calling | Medium overdue terms, where some conversations require a human and some are handled by the robot | Requires an available operator on the line and well-tuned escalation rules, otherwise waiting time grows |
| Manual calling by operators | Disputed and sensitive cases: debt contests, complaints, installment agreements | The volume of touches is limited by staff, and the format of the conversation depends on the shift and operator fatigue |
The boundary between modes is set by escalation rules: a request to connect to a human, a dispute over the amount, emotional speech, or a repeated question on one point.
When the rules are described, automated calling handles simple touches and records the result, and the operator connects only where the conversation truly requires it.
Implementation stages: from base audit to scenario handover
The work begins with an audit of the base and touch rules: we look at which fields are filled, where there are duplicates and non-working numbers, how debt statuses and consent to contact are marked.
The output is a data map for calling queues and a list of rules: time windows, maximum touch frequency, exits upon unsubscribe or complaint.
- Base and touch rules audit. We consolidate sources into one format, check numbers for validity, and remove duplicates. We record at which debt status and on which day of overdue a call is appropriate.
- Telephony integration scheme. We determine how the bot connects to the operator: number pool, number of simultaneous lines, answering machine detection, distinguishing “no answer,” “busy,” “unavailable.” Separately — behavior during channel failure.
- Scenario setup. We assemble the conversation logic: identification, amount and deadline, response branches — “I’ll pay,” “it’s not me,” “no possibility,” debt dispute. Each branch leads either to recording an agreement or to transfer to an operator.
- Pilot launch of calling. We run the bot on a limited sample and listen to recordings: where it interrupts, where it misunderstood the response, where the wrong branch triggered. We make edits based on facts, not hypotheses.
- Scaling. We expand the sample, configure the queue and priorities, and monitor recognition quality on different communication channels.
- Handover of regulations. We provide scenario descriptions, touch rules, the procedure for edits, and instructions for operators.
Scenarios and touch rules then live by call statistics: the cycle repeats rather than closing with a one-time launch.
What remains with you: configurations, regulations, documentation
After launch, the entire calling logic remains with you as working files and settings, not in correspondence with a contractor. The package below allows your team or another vendor to change scenarios, thresholds, and schedules without our involvement.
- Dialogue scenarios — conversation branches in editable form: bot lines, question wording, answer options, and conditions for transitions between steps. You change the text or order — and publish the new version yourself.
- Escalation rules — under what conditions the conversation goes to an operator: request for a human, dispute over the amount, several unrecognized responses in a row, refusal to continue. Thresholds are set by parameters, not hardcoded.
- Integration scheme — a map of exchange with your accounting system: which fields go to calling, which return, how the call result and debt status are recorded.
- Quality control regulation — how to selectively listen to recordings, which metrics to review (share of connections, consents, escalations), at what frequency, and who is responsible for this.
- Calling documentation — campaign logic, call schedule, frequency and retry limits, explanation of each rule in plain language.
- Accesses and roles — which employees are allowed to change what: texts, thresholds, number lists, start and stop of a campaign.
The handover includes a walkthrough: we show where each parameter is edited and answer your team’s questions. After that, further development of calling does not require contacting us for every edit.
Case study: how operator workload and refusal rate were reduced
Before the pilot, reminders for overdue payments went entirely through operator calling. Part of the base was not reached on the first attempt, and operators’ wording varied, so the share of refusals to pay stayed at the same level regardless of the number of shifts.
How the pilot was built
We did not launch on the entire portfolio: Retail-Credit allocated a segment with a uniform debt profile and split it into control and test groups. Thus the difference in metrics is explained by the conversation scenario, not by the composition of the base.
The voice AI bot conducted the dialogue by intents that cover most situations: a payment promise, clarification of the amount, a request for an installment plan, a callback request.
| Metric | Before pilot | After pilot |
|---|---|---|
| First-attempt connection | 4 out of 10 | 7 out of 10 |
| Share of refusals to pay | 34% | 21% |
| Touches handled without an operator | 0% | 58% |
| Time to payment promise | 2 days | 1 day |
More than half of the touches were handled without an operator: the bot confirmed identity, stated the amount and date, recorded the agreement, and passed complex cases to an employee along with the dialogue history. Operators began working with complaints and restructuring requests, where a human is truly needed.
What the customer confirms
The metrics were verified against an export from the calling system, not internal team reports. The customer confirms: operator workload decreased, and the share of refusals to pay stopped growing — this became the basis for scaling the scenario to the rest of the base.
What to do if you already have telephony and an accounting system deployed?
If telephony and the accounting system are already working, they do not need to be replaced.
The voice AI bot is added as a separate service between the call and accounting: telephony provides the line, the bot conducts the conversation, and the result returns to the accounting system as a regular contact record.
Existing telephony is reused almost entirely — routing, extension numbers, call recording, queues, and dialing rules remain yours. We add a separate dialing route through which the required segment of calls goes to the bot; on Asterisk this is a separate context and queue.
The client sees the same number, and the operator connects only where the bot transfers the dialogue to a human.
Integration with the accounting system is built on its standard interfaces — programmatic exchange, database queries, or event notifications — so changes on the accounting side are usually not required.
The bot reads the amount, deadline, and debt status, and at the end writes a payment promise, refusal reason, or installment request. The record is idempotent: a repeated call does not create a duplicate, and each action is tied to the client identifier.
Three things have to be added: speech recognition, dialogue logic, and result recording.
Connection without replacing systems goes on top of existing infrastructure, so we launch the pilot on one scenario and segment — expansion already depends on the share of dialogues brought to a result.
Technical concerns: speech recognition, delays, integrations
Questions about a voice AI bot usually come down to four topics: whether it can parse live speech, whether it will interrupt, where personal data goes, and how quickly the scenario can be changed. Below are answers to the point, without promises that it “works perfectly.”
There is no single “recognition percentage”: quality depends on the communication channel, noise, speech rate, and the vocabulary of a specific campaign.
Therefore, a safety margin is built into the scenario — confirmation of key data, re-asking, and transfer to an operator where model confidence is low.
How does the bot handle poor connection and background noise?
Speech is recognized in a stream, using intermediate hypotheses, not after the phrase is complete: the bot reacts faster and does not lose meaning during dropouts.
The vocabulary is supplemented with domain terms — amounts, dates, product names that a general-purpose model confuses.
The bot does not “guess” critical fields; it says them aloud and asks for confirmation; after several unsuccessful attempts, the conversation is transferred to an operator.
The acceptance metric is the share of dialogues brought to a confirmed agreement and the number of re-asks per conversation.
How sensitive is the bot to pauses, and can it be interrupted?
The end of an utterance is determined by silence, and the threshold is configurable: for people who speak slowly or are thinking about an answer, the wait increases — otherwise the bot responds into the void and the conversation falls apart.
The opposite situation is also covered: a person can interrupt, and the bot stops playback and listens to the end. The maximum pause duration before a soft prompt and correct termination upon silence are configured separately.
How is debtors’ personal data protected?
Recordings and recognized texts are stored in a dedicated customer environment, not in an external service.
Sensitive fields are masked in logs, access is role-based, every access to a record is logged, and the retention period is set by policy with automatic deletion upon expiry.
If a conversation recording is not needed, the scenario works without it — only the text remains for quality control.
Will the bot need to be rebuilt when the scenario changes?
No. A scenario is a set of branches with conditions and escalation rules; it is versioned, and edits — wording, order of questions, thresholds for transfer to an operator — are made without stopping the service.
A new version can be enabled for part of the numbers and compared with the previous one by the share of confirmed agreements before rolling it out to the entire flow.
Let’s discuss the task: what we need from you and where we start
To come back with an estimate and a work plan rather than general promises, we need a minimum set of inputs.
We start the conversation with the current calling scheme: who gets worked and in what order, which debt statuses you distinguish, and what you consider a successful touch — a payment promise, clarification of the date, or a refusal. This is enough to estimate the scope and propose a dialogue architecture.
- Portfolio snapshot: how many touches per day, share of connections, distribution by overdue terms.
- Conversation scenarios and escalation rules: at what point the voice AI bot transfers the call to an operator, and at what point it correctly ends the dialogue.
- Integration inputs: accounting system, available exchange methods — API, file exchange, or event queue.
- Mode limitations: allowed hours, touch frequency per client, retry rules.
- Recording requirements: conversation recording, transcription, retention period, result labeling.
- Legal framework: consent texts, mandatory phrases, what the bot must not say.
- Acceptance metrics: share of payment promises, accuracy of response recognition, number of false triggers per thousand dialogues.
We start with a pilot on a narrow segment and one scenario: we collect real dialogues, review transcripts, adjust the reply logic, and only then expand to the entire portfolio.
We compare the result with a control group of operators — that way the effect is visible, not just a feeling. Describe the task — we will come back with an estimate and a work plan.