AI auto-dialing: where the manual notification scheme breaks
While the customer base numbers in the hundreds, manual calling relies on enthusiasm: an operator takes a list, dials number after number, and marks the result in a spreadsheet.
As soon as a limited-time promotion comes up, the scheme breaks — customer notification must fit within the window, not stretch over weeks.
The bottleneck is not the number of operators, but the load profile. Promotion notification comes in a wave: in the first hours, peak line load is needed, then the flow drops almost to zero.
Keeping a permanent staff for the peak is pointless, and quickly hiring people won't work: while new operators are being brought up to speed, the promotion window is already closing.
The second problem is data quality. The operator records the call outcome subjectively (“didn't answer,” “call back later”), and repeat attempts go in blind. Part of the base drops out of calling entirely: busy numbers, inconvenient time, refusal halfway through the script.
The result is coverage below plan and no statistics on the promotion: there is no way to count how many customers actually learned about the terms.
AI auto-dialing removes this dependency: automated promotion calling distributes the base by time on its own, repeats missed calls, and carries notification through to the end of the window. Below, we break down how this works and what exactly is removed from the manual scheme.
What AI auto-dialing delivers: speed, coverage, retention
Speed: the base goes into calling within a shift, not a week
The number of simultaneous lines is not tied to the size of the operator shift, so several thousand numbers are processed in hours.
The attempt schedule is set in the scenario: the system calls within the window when the subscriber is more likely to pick up, and does not hold the line during long rings.
Coverage: reaching numbers that were usually postponed
An operator manages around a hundred dialogues per shift, and the “hottest” contacts are first in the queue, while the rest is postponed. Auto-dialing goes through the entire base, including evening hours and weekends, and automatically queues unavailable numbers for retry.
Every touchpoint — call status, response, and interest in the promotion — is recorded in amoCRM, so coverage is visible in numbers.
Recognition accuracy: the dialogue does not fall apart in noise
Speech is recognized in a stream, accounting for pauses and interruptions, so short answers such as “yes,” “not now,” “what are the terms” are not lost. If confidence is low, the system asks again with a neutral wording instead of cutting off the conversation.
Retention and offloading: the operator connects only to complex cases
Standard promotion notification is handled by auto-dialing, and those who asked a question about the terms or objected are transferred to operators — already with collected context.
The customer receives a reminder about the promotion or expiration while interest is still alive, and part of the base returns to purchase.
System operating modes: comparison of approaches
Outbound promotion calling is built in two basic modes, and the choice is determined not by the size of the base but by the source of the reason for the call.
In batch mode, the list is assembled in advance by segment, the campaign runs in windows during permitted hours, and it is processed by parallel lines.
In streaming mode, the call is initiated by an event — promotion start, customer status change in CRM, approaching deadline — and goes into dialing immediately while the message remains relevant.
On top of both modes, adaptive dialogue is enabled: the system chooses the next utterance based on the subscriber's actual response, not a rigid branch.
Calling scenarios set the framework, offers, and permissible clarifications, rather than verbatim text, so branching and refusal handling must be tested.
| Mode | When it fits | Limitations |
|---|---|---|
| Batch mode | Mass notification by a pre-assembled segment, calls during permitted hours, predictable load | The list becomes outdated by the time of dialing, response reaction is delayed |
| Streaming mode | Event-based notification when timing matters: promotion started, application stalled, deadline expiring | Requires a stable event channel and peak control — a spike turns into a queue and abandonments |
| Combined | Batch base plus trigger follow-ups for those who did not answer | Harder to debug: two dialing logics need to be separated so the subscriber does not receive two calls in a row |
In practice, the combined option is chosen: batch mode covers the main volume, streaming handles follow-ups and reaction to events, and adaptive dialogue is responsible for conversation quality in both.
Implementation stages: from audit to handover to support
Implementing AI auto-dialing is not installing ready-made software, but a sequence of stages with a verifiable result at each.
The order cannot be changed: a scenario written before a telephony audit runs into operator limits, and CRM integration without debugged dialing logic breeds duplicates.
- Telephony audit. We review numbering, the limit of simultaneous lines, channel quality, recording operation, and carrier rules. The output is a connection scheme and the maximum calling speed above which the share of hangups grows.
- Scenario setup. We build the conversation logic: promotion notification, answers to typical questions, conditions for transfer to a live operator. Separately, we record what the system must not say — promises, deadlines, personal terms.
- CRM integration. We link the call to the customer card: statuses, tags, conversation recording, prohibition of repeat calling for the same promotion. Without this, the base becomes clogged with duplicates, and opt-outs become more numerous than responses.
- Calling testing. A run on a controlled sample: we look at the share of recognized responses, false triggers, accuracy of meaning transfer, and correctness of branching. We fix discrepancies before launching on the entire base.
- Pilot and calibration. We launch on a limited segment, compare actual line load and dialogue quality with the calculated ones. Based on the results, we adjust the calling pace and wording.
- Solution handover. We hand over documentation on scenarios and integrations, edit regulations, access, and support instructions. After that, the system can be developed in-house or with us.
Handover package: configurations, scenarios, regulations
Handover is not a folder with files, but a working system: each artifact is versioned, resides on your side, and allows you to launch calling, edit scenarios, and connect new segments without our involvement. Below is what exactly is included in the package and why each document is needed.
- Dialogue scenarios — conversation branches for each promotion: utterances, conditions for transfer to an operator, refusal handling, repeat attempts, and call stop rules to avoid calling again.
- Integration scheme — how the system is connected to the contact base, CRM, and telephony: exchange points, export formats, and behavior when the source is unavailable.
- Access policies — roles and visibility scopes, restrictions on exporting numbers and results, action logging: you can see who and when changed a scenario or sample.
- Update regulation — the procedure for edits, a run on a limited part of the base before launching on the full list, and rollback to the previous version if conversation quality dropped.
- Support regulation — who responds to failures, within what timeframes, and how changes are transferred between your team and ours.
- Documentation — description of variables, call statuses, error codes, and typical support requests.
- Operator instructions — how to review disputed calls, where to view the campaign summary, and how to export the report on promotion results.
The package is assembled so that the internal team can run calling on its own. If the volume of promotions grows or the data source changes — describe the task, and we will return with an estimate and a refinement plan.
Case study: notifying a loyalty base during peak hours
Before
A retail chain with a loyalty base of about 400 thousand numbers: promotions are short, and the notification window is the first 24 hours after launch. Calling was done from operator workstations, in two streams, and on peak evenings the channels hit the line limit.
Part of the base received a call when the promotion period was already expiring, and the full pass took about three days — the money for the promotion was spent, but information did not reach up to half of the recipients.
What was changed
We built auto-dialing on telephony connected to amoCRM: a queue by segment priority, call windows taking time zones into account, a limit on the number of parallel lines, interval-based retries, and answering machine detection so as not to waste an attempt on a mechanical voice.
A separate policy is not to call again those who have already confirmed participation, and to instantly close the number across all promotions after a “do not call again” request.
What was achieved
| Metric | Before | After |
|---|---|---|
| Calls connected in the first 24 hours | 18% | 64% |
| Full pass of the base | ~3 days | 9 hours |
| Unsubscribes from the mailing | grew from promotion to promotion | below 2% |
Peak load stopped being a bottleneck: the call flow is leveled by the schedule, and operators connect only to those dialogues where a human is needed.
The share of promotion participants who made a purchase in the first two days tripled — because the base learns about the offer while it is still relevant.
How does streaming mode differ from batch mode?
The difference between the modes is where the decision about the next utterance is made.
In streaming mode, recognition, response selection, and synthesis run continuously within a single connection: the system hears a phrase and immediately voices a reaction, and the delay fits within the natural pause of the conversation.
In batch mode, the scenario and utterances are prepared in advance, calling goes in waves through the uploaded list, and response analysis and repeat attempts are launched after the wave is completed. Branching is built in before the start — the dialogue is not restructured on the fly.
In terms of load, the modes behave in opposite ways. Streaming maintains an even number of simultaneous conversations and requires reserve capacity for the peak number of lines: if the response is late, the subscriber hears a pause and hangs up.
Batch forgives peaks, the queue is processed according to schedule, but each wave relies on pre-prepared text.
Streaming mode is sensitive to the channel: the stream that a synthesis engine like Yandex SpeechKit delivers in portions breaks when the connection drops, so the connection is reserved and monitored separately. For batch, a wave interruption is not critical — unprocessed numbers simply go into the next one.
For promotion notification, a combination is usually used: dialing and mass runs through the base are done in batch, in windows, while a subscriber's follow-up question goes into a streaming branch with a response at conversation pace.
Technical concerns: delays, accuracy, integrations
Concerns around auto-dialing usually come down to four points: whether the system manages to respond at the pace of live speech, how accurately it understands the subscriber's answer, how it integrates with current telephony, and what happens to conversation recordings. We address each.
Will the subscriber hear a pause before the response?
The chain “recognize — select a response — voice it” fits within the natural pause of the conversation. If the phrase is long and needs more time to comprehend, the system gives a short confirming utterance — no silence occurs. The pause pace is configured for the scenario.
How accurately are promotion names and names recognized?
We add promotion, product, and brand names to the domain dictionary — without it, the model does not hear them. When confidence is low, the system asks again or transfers the call to an operator rather than guessing. The share of repeat questions is visible in the report for each scenario.
How does calling connect to our telephony?
Through the standard trunk of your PBX or its software interface: numbers, routing, and carrier limits remain yours. The voice menu and operator queues continue to work as before. If lines are rented from us, numbering is agreed separately.
What about data security and load?
We store recordings and transcripts in your environment or ours with access separation and a retention period according to your regulation. Load grows by adding lines: the scenario and contact base do not change, only the number of simultaneous calls increases.
Let's discuss the task: we'll select a mode and estimate the load
Tell us whom and for what purpose you need to call — by the base of past purchases, by promotion applications, or by a segment that hasn't opened mailings for a long time. The mode depends on this: scheduled calling, event reaction, or follow-up retry after 24 hours.
Then we will return with a load estimate — how many simultaneous lines to maintain, what dialing pace your carrier can handle, and how to distribute calls across time zones so as not to wake people at night.
- selecting a calling mode for the task: by base, by trigger, or mixed, with retry rules and filtering out busy numbers;
- a dialogue scenario with branches for “not interested,” “call back later,” answering machine, and transfer to an operator when the system is not sure of the answer;
- load estimate: peak dialing speed, number of lines, carrier limits, and behavior when the carrier side fails;
- a staged implementation plan — from connecting the base and linking with your accounting system to test runs on a small sample;
- a pilot launch on one segment with listening to recordings and refining wording before going to full volume;
- rules for handling refusals, maintaining a “do not call” list, and reporting on calls connected and those who reached the promotion.
To discuss the task concretely, a couple of paragraphs are enough: the size of the base, the purpose of the call, and what is already configured in telephony.
In response, we will send a load estimate, an implementation plan, and the composition of the pilot launch — along with what will be needed from your side.