Voice broadcast in Bitrix24: where the scenario breaks
Voice broadcast in Bitrix24 launches quickly: upload the contact base, choose a scenario, distribute lines and calling time.
Automated customer calling runs hundreds of calls per hour, but the figure in the report and the real result diverge: some subscribers did not hear even the first word, some conversations went to an answering machine recording. Then the team switches to manual calling by managers, and the cost of contact grows every day.
The first typical failure of the calling scenario is a break at the greeting. The robot got through, started the phrase, and the subscriber hung up or the connection dropped in the first seconds.
The attempt is spent, the card shows the status "connected", and a repeat call according to the settings may no longer go through — the number drops out of the sample, although the client did not refuse the conversation.
Second — triggering of an answering machine. The system takes the operator's voice greeting as the start of a dialogue and speaks the scenario into the void, while in the report it passes as a completed conversation.
The quality of base calling falls: instead of client reaction, noise accumulates in the system, by which it is impossible to plan the next step.
Third — loss of those who answered. The subscriber answered, but did not wait for the operator or got into a queue where the call was dropped due to a time limit.
Such a contact is the most valuable and is lost first, because the queue is built by the order of numbers, not by the fact of answering. We analyze each of these failures using the call log and scenario settings in Bitrix24 — next, how this is resolved.
Effect of putting the broadcast on a flow
The robot calls the base on several lines in parallel and repeats unavailable contacts at another time of day — morning, lunch, evening.
The share of successful connections grows without hiring people: some numbers are not picked up on the first attempt, and a repeat at a time inconvenient for the office pulls it out.
The system goes through a base of several thousand contacts in a shift, not in a week of manual dialing. Each connection is recorded immediately: duration, pressed key, status in the card.
The advancement queue is visible in real time — calling windows are moved, lines are added for the remainder of the base.
When the subscriber is ready to talk, the answer is passed to the operator as a warm transfer — the rule triggers on a key press or a key phrase.
The manager receives a connection with the contact history and does not waste time on mechanical dialing: the sales department's load shifts from dialing to handling objections.
Reporting is built on the same data: the voice broadcast funnel in Bitrix24 shows the share of successful connections, conversion to dialogue, the number passed to the operator, and the reasons for refusals.
By breakdowns, you can see which segments of the base should not be called, and where attempts need to be added.
The transfer rules and reporting breakdowns remain working after launch — they are adjusted for new segments and scenarios without rebuilding the broadcast from scratch.
Calling scenarios: template, personalized, hybrid
The choice of scenario is determined not by the size of the base, but by how much data about the client is in the card by the time of the call and what should happen after the answer.
A template auto-informer and a scenario with recognition of the subscriber's answer solve different tasks, and substituting one for the other gives either extra actions for the client or lost contacts.
Below are four routes that we assemble in a Bitrix24 voice broadcast, with the limitations of each. In practice, most projects arrive at a hybrid: the mass part goes by template, and those who reach a dialogue go by a personalized scenario.
| Variant | When it fits | Limitations |
|---|---|---|
| Template: recorded message, auto-informer | Large base, task — convey a fact: confirmation of a record, payment reminder, change of terms | No recognition of the subscriber's answer: the client's reaction is visible only by the fact of connection and listening to the end |
| With recognition of the subscriber's answer | Need to separate flows — "I confirm", "call back", "don't call again" — and immediately route them to responsible persons | Requires a well-developed answer tree and tests on real recordings: slips of the tongue and background noise cause false triggers |
| Personalized by deal data | Few recipients, but high cost of error: amounts, deadlines, request status are inserted from the card | Need current and filled fields: personalization of the message using empty data sounds worse than a template |
| Hybrid route | Mass calling with subsequent personalization for those who entered the dialogue | Harder to debug: two logics, two sets of checks, end-to-end logging of transitions is required |
Before launch, we run each route on a test sample and look at where the calling scenario breaks: incorrectly recognized answer, empty deal field, break in the middle of the message.
Implementation stages: from audit to handover to operation
Work proceeds in sequential stages: each next one relies on the result of the previous one, so an error in the scenario is visible before the calling goes out to the entire base. At each step, the customer receives a verifiable artifact, not a promise.
- Audit of the contact base and rules. We check duplicates, invalid numbers, consents to data processing, and segments — without this, the broadcast hits junk records and distorts connection statistics.
- Design of answer routes. We lay out all outcomes of the conversation: answered, did not answer, busy, answering machine, key press, refusal. For each — its own action and next step.
- Connection of telephony. We configure the provider, distribute numbers, set limits of simultaneous calls and calling windows so as not to hit the operator's restrictions.
- Assembly of the scenario and test run. We run the dialogue on a test segment: check answer recognition, correctness of branches, and calculate the share of completed conversations before going out to the entire base.
- Link with deal cards. The recording, transcript, call result, and task for the responsible person go into the card, the stage changes based on the outcome of the conversation — data is not transferred manually.
- Team training. We show how to read reports, where to edit the dialogue text, and what to do with non-standard answers.
- Handover to operation. We provide accesses, documentation, and change regulations so that scenario edits do not require us.
After handover, calling scales to new segments without rebuilding: only the selection rules and dialogue text change.
Settings, regulations and instructions for calling
Launching voice calling is not one setting, but a set of documents and rules by which the campaign lives after delivery. We hand them to the customer as a working package, so that scenario edits, new bases, and analysis of results do not require returning to the contractor.
- Scenario scheme — dialogue branches with transition conditions, reaction to "don't call", number of repeats and pauses between attempts.
- Routing rules — distribution of clients by responsible persons, call windows taking into account time zones, limit of attempts per contact per day.
- Calling regulations — who launches the campaign, how the base is approved, in what order duplicates are entered and how refusal is recorded.
- Rules for working with the stop list — how a contact gets there, what is checked before each launch, who has the right to return a number back.
- Instruction for the operator — what to do when transferred to a live person, where to look at the conversation history, where to escalate a disputed case.
- Report templates — share of successful connections and conversations, breakdown by refusal reasons, export of results to the client card.
- Integration map — which fields are filled automatically, where the conversation recording is stored, how the result gets into the funnel.
- Procedure for edits and accesses — who has rights to the scenario, how a test run happens before publishing changes.
Usually the package takes several pages and is reviewed with employees in one meeting: after it, the customer's team adds new scenarios and corrects rules themselves, without waiting for us.
Describe the task — we will return with an estimate and a plan for how the documents will fit into your process.
Case: calling by deals stopped breaking at peak
In the sales department, calling by deals in Bitrix24 went in one stream: the system dialed number after number, and operators managed to handle only part.
At the peak from 11:00 to 13:00, the number of simultaneous attempts hit the line ceiling, and up to 22% of subscribers who answered never waited for a conversation.
These are lost answered subscribers — the most expensive class of losses: contact was made, but the next step on the deal was not taken.
Delays accumulated next: some deals remained without first touch for 6 hours, and repeat calling was not performed at all — attempts were overwritten by the next wave. No one saw the line load, so growth in the number of deals directly turned into growth of losses.
We divided calling into two independent streams — first touch and repeat calling — and put a queue between them.
The queue works as a buffer at peak: attempts do not disappear, but wait for a free operator, priority is given to fresh deals and those who already picked up the phone.
For each stream, we set its own schedule of attempts and limit of simultaneous calls so that the line does not hit the ceiling.
Result by metrics: per shift, with the same composition of operators, approximately twice as many numbers are processed — 400 instead of 180–200.
The share of lost answered calls fell from 22% to 5–6%, the share of deals without first touch — from 18% to 3%, the maximum touch delay was reduced from 6 hours to 40 minutes.
The call outcome and refusal reason are written into the deal card, so repeat calling is built on fact, not on a schedule at random.
How does a calling robot differ from an auto-informer?
An auto-informer is a one-way message: it dials, plays the recorded text, and ends the call. It does not hear the subscriber's answer and does not distinguish who picked up the phone — a person, an answering machine, or voicemail. If the subscriber asks again or asks to call back — for the system this is the same as silence.
A calling robot works differently: it recognizes speech and turns the answer into a branching point of the scenario.
"Yes", "no", "not now", "connect me with a manager" — each recognized intention launches its own branch, not the next paragraph of the recording.
The key difference is not in the voice, but in what happens after the subscriber's answer.
Scenario branching sets the logic: confirmed interest — the robot clarifies details and initiates a connection with an employee; asked for time — records the interval for a repeat call; asked a question — answers according to the script and returns to the fork.
Hence the different scope of application. The auto-informer covers notifications without feedback: a reminder about an appointment, a schedule change, delivery confirmation.
A calling robot is needed where value is in reaction — order confirmation, client return, primary qualification before a manager's call.
The practical selection criterion is the target metric: for the auto-informer it is the share of successful connections and listened messages, for the calling robot — the share of dialogues brought to connection with a live employee.
The second scenario is more difficult to set up: speech recognition, handling interruptions, correct transfer to a human. But it is precisely this that turns calling from a broadcast into a feedback channel.
Technical questions before launching calling
Before the first launch, the same doubts usually surface: is the quality of the number base enough, what to do with answering machines, how to take into account the subscriber's refusal, and will the result get into the deal card. We address them point by point.
What to do if the number base is "dirty"?
We normalize the format, cut out duplicates and invalid numbers, and mark those already called in previous campaigns. The remainder is labeled by source — deals from the funnel, form requests, uploaded lists.
How does the system distinguish an answering machine from a person?
A short greeting with an even intonation is recognized as an answering machine: the scenario does not go beyond the introduction. Such a call gets a separate outcome, and a repeat call is scheduled for another time, not the same hour.
How is the subscriber's refusal of calling processed?
The request "don't call again" puts the number into the stop list automatically, and the rule applies in all future campaigns, not only the current one. Service numbers are blocked separately, until manual review.
Can the scenario be changed independently?
Yes. The texts of replies, questions, and transition logic are separate from the integration code, so edits are made in the interface and applied to the next launch. Before publication, the scenario is run on a test number.
Does the calling result get into the deal card?
After the call, the CRM records the outcome — connected, refusal, answering machine — the conversation recording, and answers to key questions. The manager sees this in the card and deal history, not in a separate report.
Let's discuss the task: we will return with an estimate and plan
To make the conversation substantive, send what you have now: a contact export, a draft scenario, and calling rules — whether as a table or text.
From them, it is clear which fields are needed for substitution into replies, where in the card to record the status, and how many attempts per subscriber to plan.
We return with an estimate and a work plan in the following composition:
- Scheme of calling flows: from loading the list and filtering out duplicates with the black list to recording the result in the Bitrix24 card and closing the task.
- Scenarios with forks — what the system says when the phone is picked up, answering machine, busy, and refusal, and at what moment the operator connects to the conversation.
- Composition of work: line connection, call schedule taking into account time zones, reply templates, employee access rights.
- Reporting: which indicators we collect — share of successful connections, average duration, distribution of refusals — and where they are exported.
- Stages with an effort estimate and dependencies: what we do first, what requires your data or approvals.
- Responsible persons on both sides and approval points for scenarios and lists.
- Procedure for handover to operation: employee training, instruction for editing scenarios, regulations for improvements, and control of the first runs.
Describe the calling task — we will return with an estimate, a work plan, and clear areas of responsibility.