Delivery notifications in 1C-Bitrix: where the chain breaks
Delivery notifications in 1C-Bitrix break not at the moment the email is sent, but earlier — at the order status transition.
The customer places an order, payment goes through, but the status remains unchanged: the event handler didn't fire, the message queue stalled, and the email template didn't receive the data for substitution.
Externally it's silence in the inbox, internally it's a broken delivery chain where the next step simply doesn't start.
Then the failure accumulates. The email goes out but lands in spam: the domain isn't signed, the return address doesn't match the sender, the template is built from inline images and links to external hosting.
The customer sees neither the tracking number nor the rescheduled date — and calls support, even though the order is already on its way.
A separate story is a manual status change: the manager moves the delivery in the panel, but the notification doesn't go out, because the trigger is tied to an automatic transition, not to the fact of the change itself.
Another silent failure is a desync between the warehouse and the site. The courier service returned a new status, but the exchange didn't go through, and the personal account shows "awaiting shipment" while the parcel is already at the pickup point. The customer learns the truth from the courier, not from the store.
We break the chain down link by link: where the event is lost, why the template doesn't assemble, what prevents the email from getting through. Below — how this is closed at the level of statuses, templates, and channels.
What end-to-end notification automation delivers
When an order status changes, the customer finds out about it on their own — from an SMS, an email, or a messenger message, rather than from a call to support.
Every event in 1C-Bitrix — handover to delivery, arrival at a pickup point, courier en route, delivery — automatically generates a notification based on a predefined template.
This takes the "call back and check" routine off managers' plates and gives the customer transparency of statuses without waiting on the line.
A unified sending log records every message: channel, template, time, delivery result, and the provider's response.
If a customer claims a notification never arrived, the question is resolved in a minute — you can see whether the message went out, whether it was delivered, and which status triggered it.
This way support stops being a "broken telephone" between the customer, the warehouse, and the delivery service.
Repeat inquiries about the same order are reduced: the customer sees the parcel moving and doesn't call a third time to ask where it is.
The load on the first line drops — typical questions like "where is my order" and "when will it be delivered" are handled automatically, while operators deal with non-standard situations.
Status transparency also works internally: logistics, the warehouse, and support look at the same data instead of reconciling it manually.
Loyalty here is a consequence of predictability. A customer who receives a clear notification on time cancels an order less often and comes back more often, and the brand is perceived as organized.
The unified log also provides a basis for analytics: you can see at which status customers are most often lost and which notification channel is actually read.
To assess the effect for your process, we need to look at the current order statuses and the points where customers most often call. Describe your task — we'll come back with an estimate and an automation plan.
1C-Bitrix Delivery Notification Channels: SMS, Email, Telegram
Each channel solves its own task: SMS reaches where there is no internet, Email leaves a trace in the inbox, Telegram gives instant response and buttons.
In practice, the working combination is not "either-or," but routing by event: order status goes to Telegram, critical milestones are duplicated by SMS, and closing documents and the receipt go to Email.
| Channel | When it fits | Limitations |
|---|---|---|
| SMS gateway | Client without messengers, urgent "courier at the door" status, code confirmation | Paid traffic, length limit, no buttons or attachments, requires a provider and sender ID moderation |
| Email campaign | Receipt, invoice, tracking number, order history | The email easily lands in spam, response is slow, requires a domain, DKIM/SPF, and warm-up |
| Telegram bot | Instant statuses, "Track," "Reorder" buttons, chat with support | The client must start the bot, requires a webhook and handling of blocks |
The cost of ownership is made up not of the tariff, but of support: an SMS gateway requires a contract and a balance, Email requires domain reputation and handling unsubscribes, Telegram requires a stable webhook and a retry queue.
That is why in 1C-Bitrix channels are connected through a single event layer: an order status change triggers a handler, and it decides where and with what delay to send the notification.
Such a layer removes the main pain point — duplicates and "lost" messages. If Telegram is unavailable, the task goes into a queue and is retried rather than lost; if the client has unsubscribed from Email, the status still arrives via another channel.
We lock in the choice of combination at the design stage: we look at the audience, geography, and which events are critical for the business.
Implementation stages: from event audit to handover of regulations
Implementing delivery notifications starts not with email templates, but with an inventory of events: which order statuses change in 1C, which of them matter to the customer, and which are internal.
At this step we record where each event comes from — exchange with 1C, status change in Bitrix24, response from the delivery service — and which notification channels are already in use. This makes it clear where the customer receives duplicates and where they receive nothing at all.
- Event audit. We compile a complete list of order statuses and their change points, noting which events already generate notifications and which are lost during the exchange between systems.
- Trigger scheme. We build an "event → recipient → channel" map: order confirmation, handover to delivery, arrival at the pickup point, delivery. We remove overlaps so the customer doesn't receive two emails about the same step.
- Template setup. We prepare texts for each channel separately: a short SMS, an email with a tracking number, a message in a messenger. We insert order variables and check that substitution works correctly when fields are empty.
- Test scenarios. We run the full order path on test data: from checkout to delivery, including cancellation and return. We check delivery when one of the channels is unavailable — the notification should go through the backup one.
- Error handling. We set up logging of sends and retries when an external service fails, so that a channel failure doesn't leave the customer without information about the order.
- Operating regulations. We hand over a document: which events are tracked, who is responsible for the texts, how to add a new status, and where to view the send history.
- Handover and training. We show employees how to make edits to templates without a developer and how to read the failure log.
After the regulations are handed over, the client's team manages the texts independently and adds new statuses — without contacting development for every change.
Project artifacts: templates, routing rules, delivery log
After implementation, the client is left with a complete set of artifacts — not a "configured website," but a portable set of configurations, rules, and documentation.
Any engineer or administrator can deploy the notification logic on another environment without reconstructing it from memory. Below is exactly what we hand over.
- Email and message templates — texts for email, SMS, and Telegram for each order status, with variable substitution (order number, contents, deadline, tracking number). Stored as separate templates rather than hardcoded.
- Routing rules — an "event → channel → recipient → delay" table. It shows where a notification goes when the status changes, who receives a copy, and what happens on non-delivery.
- Connection configuration — parameters for the mail server, SMS gateway, and bot, indicating which values are exposed in settings and how to change them without editing code.
- Delivery log — a table with history: date, recipient, channel, delivery status, error text. It is used to investigate incidents and confirm that a customer was notified.
- Process diagram — a visual map: from an order status change to the actual delivery of the message, with failure and retry points.
- Instructions for managers — how to add a new template, switch a channel, and check whether a notification was sent to a specific customer.
- Operations regulations — what to check during a failure, how to restart the queue, and where to look first.
We hand over each artifact in working form and with an explanation of why it is needed. We separately record which settings are critical and what cannot be changed without approval — so that edits do not break routing.
Case study: how delivery notifications stopped getting lost
The client is an online store with regional delivery, orders went through 1C-Bitrix, and the delivery status was entered manually by an operator. Notifications went out through a single channel and only to email: some emails ended up in spam, some went to outdated addresses.
The share of delivered notifications hovered around 60%, and support was receiving over 400 inquiries a month along the lines of "where is my order."
What we changed
We tied order status change events to a business process in 1C and built a cascade of channels: SMS as the primary, email as the backup, messenger — for customers who chose it themselves during checkout.
Each send got a log with delivery status and a retry on gateway failure, and message templates were moved into editable settings so marketing could change the text without touching the code.
What happened
The share of delivered notifications grew from 60% to 96% — the channel cascade and automatic retry on failure made the difference.
Support inquiries about order status dropped by more than half, and the load on operators fell so much that the freed-up time went to returns and repeat sales.
Worth noting separately is the transparency: for each order you can see which notification went out, when, and how it was confirmed. If a customer says "I never received anything," the operator opens the log and answers based on the facts, not guesswork.
1C-Bitrix served here as the link between the catalog, orders, and the delivery service — the notification logic lives inside the same system where records are kept, so statuses don't diverge between the storefront and the back office.
How does the event-driven model differ from status polling?
The event-driven model is built on the principle that the source of a status change reports it itself: a warehouse, a delivery service, or an external system sends an event, and a handler in 1C-Bitrix receives it and triggers a chain of notifications.
The customer receives a message at the moment the order actually transitions to a new status — "handed over for delivery," "courier has departed," "delivered." Change tracking here happens in real time, not on a schedule, so the delay between the actual event and the notification is measured in seconds.
Status polling works differently: a scheduler every N minutes goes through all active orders, hits the carrier's API for each one, and compares the received status with the one stored in the database.
A change is only recorded on the next cycle, so the customer learns about delivery with a delay equal to the polling interval. The more frequent the polling, the higher the load on the API and the database; the less frequent, the longer the lag window. This is a fundamental trade-off that cannot be circumvented through configuration.
In practice, the difference shows up at scale. With the event-driven model, the number of calls to the external system is proportional to the number of actual changes — one hundred orders produce one hundred events.
With polling, the same number of orders produces a constant stream of requests regardless of whether the status changed or not: orders sitting in the same state for days are still polled every cycle.
During sales peaks, it is polling that becomes the bottleneck, hitting API limits and database load.
A hybrid scheme covers cases where a pure event is unavailable.
If the carrier cannot emit events, we set up polling, but with targeted rules: we poll only orders in "live" statuses, increase the interval for those that haven't moved in a while, and connect an event channel where one exists.
The notification architecture remains unified — there is one handler, and only the source that triggers it changes.
For the client, the choice comes down to one question: how critical is the delay, and what volume of orders passes through the system. Where the customer expects real-time delivery confirmation, the event-driven model is the only option.
Where statuses change rarely and a delay of a few minutes is acceptable, polling is simpler to maintain and requires no modifications on the carrier's side.
Common technical concerns before starting
Before starting, the same questions almost always come up: whether what already works will have to be rewritten, how the system will behave with multiple warehouses, and whether a separate messaging service will need to be set up. Below is how we answer them based on experience.
We already have email and SMS templates set up — will they have to be redone?
No. Existing templates remain the entry point: we look at which events trigger them and connect new channels to those same events — Telegram, repeat notifications, status chains.
If a template is inconveniently structured (text hardcoded, no order number substitution), we move it into an editable form, but preserve the logic and recipients.
Some scenarios are simply extended: the email stays, and alongside it a messenger message with the tracking number appears.
We have multiple warehouses and shipping points — won't notifications get mixed up?
Each warehouse is a separate event source with its own set of statuses and templates. A notification is assembled by the rule "warehouse + delivery type + order status," so the client sees the correct text and contact details for their specific pickup point.
If warehouses operate in different systems, we bring the events to a unified format — after that, messaging follows common logic.
Is a separate messaging service needed, or are built-in tools enough?
It depends on the volume and delivery requirements. Built-in tools are enough while there are one or two channels and no retries on failures.
When messengers, retry attempts, and a delivery log are added, a separate service provides predictability: it maintains the queue, retries, and a "delivered / not delivered" report.
We don't impose it — we calculate the load and show where the built-in loop will start losing messages.
What limitations should be considered in advance?
The main one is channel limits: messengers and SMS gateways restrict frequency and require the client's consent to receive messages.
Another point is integration with delivery services: statuses arrive with a delay, so we build the chain in such a way that the client doesn't receive contradictory messages. We fix these limitations at the design stage, not after launch.
Let's discuss your task and come back with a plan
To come back with an estimate and a plan rather than generalities, we need to understand your current order flow: where the delivery status is generated, who changes it, and how the customer currently finds out about it.
Describe the task in your own words — then we will ask targeted questions and propose a solution for your setup.
What we will clarify in the first conversation:
- Where the event comes from: whether the status comes from 1C, from the delivery service, or is set manually in the admin panel — the notification integration point depends on this.
- Which channels are already in use and which need to be added: SMS, Email, Telegram, or a combination of them depending on the customer type.
- Which statuses trigger notifications: "handed over for delivery", "courier en route", "ready for pickup", "delivered" — and whether there are intermediate ones the customer does not need.
- Message templates: ready-made texts or ones that need to be written, and whether there are variables such as order number, tracking number, and delivery time.
- Volumes: how many orders per day and during peak periods — so that the channels and queue can handle the load without delays.
- Access and constraints: who on the customer's side approves the texts, and whether there are requirements for storing the sending history.
- Current integrations: connected SMS providers, email services, bots — so as not to duplicate what is already working.
Based on the conversation, we define the scope of work, break it into stages, and give timelines for each. You get a plan that shows what we do first, where we need data from you, and at which stage the result can be checked on test orders.
The next step — send us a description of the delivery process and the list of statuses. We will come back with an estimate, a work plan, and timelines, and you will decide which stage to start from.