Why automatic SMS sending from CRM fails
A lead from a website form lands in Bitrix24 and remains unanswered: the client waits for confirmation, doesn't get it, and goes to those who respond faster.
Automatic SMS sending is not a checkbox in the settings, but a chain of four links: an event in CRM, a trigger rule, a message template, and a sending queue through the gateway.
A break in any of them looks the same — the deal sits in the first stage, and the manager learns about it a day later.
Most often the chain breaks at the input. Lost leads from website forms are a consequence of the rule being tied to a stage or field that is filled by a different scenario, while some forms write data bypassing the funnel.
Unclosed events in CRM accumulate for months, and in reports everything looks fine: statuses are set, but there are no sends.
Next is the queue and data quality.
Message sending limits on the gateway side and in CRM itself cut off part of the flow without a clear error in the log; invalid phone numbers — entered manually, concatenated from two fields, with another country's code — are discarded by validation after they have already been queued.
Duplicates with multiple channels, when a form, messenger, and call create a separate deal for the same person, produce two or three messages in a row, and the remainder goes into the carrier's filters.
Each area is covered at its own level: event logging tied to the deal, keys for duplicate protection, phone number validation against a mask before queuing, and limits with priorities for urgent notifications.
We'll break down exactly what we check during setup and how to make sure that no lead is left unanswered again.
What automatic notifications give customers
Notification automation in Bitrix24 is built on the bundle "trigger in the card — template — sending rule".
The trigger fires on a change of the deal stage, the appearance of a task, or an overdue response; the template inserts the client's name, number, and responsible person's data.
The delivery mark returns to the card, so the manager sees the result without switching to a third-party dashboard.
The main measurable effect is the time to first response to the client. While a lead waits for a free operator, the response stretches to tens of minutes, whereas an automatic confirmation goes out in the first seconds after contact.
The share of missed inquiries drops: night and lunchtime leads no longer remain without a reaction just because the shift is busy with dialogs.
The workload on shift operators decreases due to routine actions — confirmations, reminders, feedback requests. The freed-up time goes to complex cases where a human is needed.
A reminder brings back clients who postponed the decision: the message arrives while the deal is still open, not after they have chosen another contractor.
A separate gain is the transparency of deal statuses. Notifications are saved in the card as events, so you can see at which step the client stopped responding and how many contact attempts there were.
This data is used to set up follow-up scenarios and response times instead of guessing where inquiries are lost.
Connection options: gateway, provider, module
The sending scheme is determined by three things: where the numbers come from, who owns the sender, and what happens to the message if the channel goes down. Below are four configurations that we assemble in practice and the boundaries of their applicability.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection to a provider | One sender, a flow of leads from the website and from the card, a delivery report is needed | Template and retry logic lives outside CRM: changing conditions is a developer's task |
| Own gateway inside the perimeter | Numbers and correspondence must not go to third parties, there are own communication channels | Requires administration, queue monitoring, and updates when the carrier's requirements change |
| Ready-made module in the CRM interface | Quickly enable notifications for deals and tasks, templates are edited by the manager | Few routing conditions, tied to the platform version, weak parsing of sending errors |
| Hybrid scheme with a backup channel | Critical notifications to the client: lead confirmation, readiness, payment | Harder to set up: two channels, priorities, and switching rules need to be maintained |
Separately, it is worth checking scenarios where an option does not fit at all. A mass mailing from a shared number without sender approval simply will not go through the carrier, and receiving replies in a dialog requires a two-way channel, not one-way notifications.
If the process needs both client confirmations and service notifications to managers, one scheme usually does not cover everything: a module is used for notifications, and a direct connection with a status log is used for critical messages.
Describe the task — we will come back with an estimate and a plan for which set to assemble for your process.
How implementation goes: from event audit to handover
Most often, automatic SMS sending breaks not on the gateway side, but because of vague rules: it is unclear which event to send on, what to do with a repeat deal, and how not to send the client two messages in a row.
That is why we start with an audit, not with setup — otherwise templates and routes get reworked twice.
- Audit of business processes and events. We go through funnels, stages, robots, and forms, write out everything that changes the state of a deal or contact, and mark where a notification is actually needed and where it duplicates the manager's work.
- Notification route scheme. We bring events into a table "event → template → recipient → sending condition" and separately describe cases when the message is not sent. We agree on the scheme before setup.
- Templates and variables. We insert fields of the deal, contact, and responsible person, check Cyrillic and text length — this determines whether the message arrives as one segment or splits into parts.
- Duplicate protection. A deduplication rule by number and event plus a short delay before sending, so that canceling a stage does not send false notifications to the client.
- Test sending and delivery check. We run scenarios on test numbers, compare statuses from the carrier's report, set up retry on gateway error, and a log of failed attempts.
- Support regulations after handover. We record who edits templates, how new events are added, and where to view the log — support does not turn into a "remind me how this worked" correspondence.
What remains with you: templates, schemes, regulations
After launch, the entire scenario lives inside your portal: to change the text, add an event, or connect a new carrier, no contractor is needed.
We hand over not access to settings, but a set of configurations and documents that your in-house administrator or a new integrator can work from.
- Event and trigger map. Table "event in CRM → condition → template → recipient → delay". From it you can see why the client received the message right now and what to change to alter the logic.
- Message templates with substitutions. Texts for each deal stage with card fields inserted: name, number, responsible person, date. Behavior with empty fields and long values is described separately.
- Access rules for contact data. Who sees numbers in full, who sees only the fact of sending, how client consent is recorded, and what happens when it is withdrawn.
- Instructions for managers and support. Analysis of common situations: the message did not go out, went out twice, the client replied. What to check and where to look without a developer.
- Sending log and delivery statuses. Status decoding, filters by period and responsible person, export for reconciliation with the carrier.
- Retry regulations. How many times and at what interval we repeat sending, when we mark it as undelivered, and whom we notify.
- Checklist of acceptance scenarios. A set of test deals that is run after any changes — you can check your own changes against it too.
Case study: eliminated lost leads in the sales department
Before implementation, a lead from the website or a messenger got into Bitrix24, but the notification about it went out as one common mailing for all funnel events.
Because of this, managers saw the stage change before the new request itself, some inquiries arrived outside working hours and waited until morning, and different employees called the same client.
What was changed in the event scheme
We separated notifications by event type: separate handlers for lead creation, a missed call, and a change of responsible person.
Each message passes through a queue with duplicate cutoff by lead ID and a 15-minute window — a second send is possible only if there is no delivery confirmation from the carrier. A lead outside the schedule goes to the on-duty person instead of hanging in the general list.
What happened to the metrics
The share of delivered messages grew from 71% to 96%, and the share of duplicates fell from 8% to almost zero: previously the client received up to three identical SMS about one inquiry.
The average response time to a new lead decreased from 40 minutes to 4, including nights and weekends.
For the manager, the main thing changed: lead losses stopped depending on the human factor. The report shows who received the notification and when they replied, and disputed inquiries no longer have to be sorted out manually.
How a transactional notification differs from a mailing
A transactional, or service, notification is a reaction to a client action: the lead is accepted, the order is assembled, the appointment is confirmed, the payment has gone through. A mailing, by contrast, is initiated by us and promotes a product or service.
This is where all requirements diverge — regarding consent, queue priority, template content, and refusal processing.
For service messages, the fact of contact or an active contract is enough: they are part of the service.
For personalized offers, confirmed subscriber consent is required, and it is stored not as a checkbox but as a record — date, source of receipt, and the text that the person saw.
If consent is withdrawn, the marketing flow on that basis stops, while the service flow continues to work.
The queue is also separate: message priority is set by type. Order confirmation overtakes a promotion, and when the channel is overloaded, the mailing goes into deferred mode while the service message is delivered within a minute. Otherwise, the client waits for a code while the system pushes through an advertising block.
Templates with variable data are assembled from card fields: order number, date, address, manager name. Protection against empty substitution is mandatory — if a field is not filled, the message is not sent rather than arriving with "{Name}".
The stop list and unsubscribe close off the marketing contour, but do not block service notifications for an active deal: otherwise the client will not learn about the payment.
We separate these flows in CRM by event types, consents, and templates — then service notifications get through, and marketing does not burn out the database.
Common technical questions about setting up notifications
Before the start, the client's technical department checks exactly what changes in the portal and what remains under its control. We address the doubts that almost always arise.
What happens when the message provider changes?
The connection point is a separate sending handler, so only access credentials and templates change. The logic by which the notification leaves CRM remains the same: before switching, we run test sends and compare statuses.
Can sending be done via multiple channels?
Yes, if routing is defined explicitly: a priority channel, a backup one, and a switching condition on non-delivery. Each channel has its own template and its own status tracking; otherwise some messages will go out in the wrong format.
How can sending time be limited?
The schedule is set at the rule level: working hours, weekends, the client's time zone. Messages from a closed window are not lost but queue up until the nearest allowed interval.
How can I check that a message was delivered?
For each send, we record a status: accepted by the carrier, delivered, error with a code. The data goes into the deal card and the report — a route failure is visible in the first hours, not after complaints.
What permissions are needed for setup?
Portal administrator rights and access to business process settings are required; provider access is issued separately and revoked upon completion of work. After launch, you manage templates and schedules yourself — we hand over the regulations.
Let's discuss your task and come back with a plan
To get straight to the point, it is worth preparing a few inputs — this is data that your team already has anyway, just laid out point by point. Below is what most often speeds up the estimate.
- Events and triggers. Which CRM actions should trigger a message: deal creation, stage change, missed call, task deadline expiration. The more precise the list, the fewer unnecessary sends.
- Which channels are already used. SMS, messengers, email, or calls — it is important to understand what remains, what is replaced, and where to write on non-delivery.
- Text requirements. Templates, deal field substitution, content restrictions, and who approves the wording.
- Roles and permissions. Who sees the correspondence, who edits templates, who receives notifications — we assign rights by role, not to everyone at once.
- Responsible person on your side. A person who confirms the logic and accepts the result; we coordinate disputed scenarios with them.
- Contract with the carrier. Sender name, limits, and text moderation rules if the mailing does not go through a mail gateway.
- Technical access to CRM. A separate account with rights for integrations and process setup — we do not touch employees' working logins.
- What has already been tried. Previous attempts, manual workaround scenarios, and the places where everything is currently done by hand.
In response, you receive a trigger map, a draft of scenarios with texts, and a timeline estimate. Describe the task — we will come back with a plan.