Setting up email notifications for abandoned carts in 1C-Bitrix

Abandoned cart: where orders get lost and why emails don't go out

An abandoned cart in 1C-Bitrix is not "the customer changed their mind," but a break in the chain of events. A user adds a product, proceeds to checkout, fills in the fields — and leaves at the payment step.

No order is created in the process: there is no record in the database, no link to the buyer, no trigger for an email. From the business side, this looks like silence in the statistics, even though there was traffic and add-to-cart activity.

Lost orders almost always fall into two classes. The first — checkout events are not recorded: the e-commerce module does not write the intermediate state of the cart, and the cart lives only in the browser session. The customer closed the tab — the data is gone, there is nothing to restore.

The second — the events exist, but cart notifications do not arrive: the email event template is not bound to the type, the email goes to spam due to missing correct domain records, or the sending fails at the queue stage and settles in the agent logs.

Funnel diagnostics begins with the logs. We check whether the email event is registered in the journal, whether it reaches the sending agent, whether there is an entry in the unsubscribe table, and how the bounce handling works.

If the event is not created at all — the problem is in the cart recording logic, not in the email. If it is created but there are no emails — we examine the transport: SMTP settings, hosting limits, domain reputation.

Often both defects coexist: half of the carts are not saved, and of the saved ones, half of the notifications are silently lost.

We break down how this gets closed: first we restore event recording at every checkout step, then we fix notification delivery, and only after that we set up the customer return scenarios themselves.

What a configured abandoned cart email chain delivers

A configured abandoned cart email chain is not "a single email after 24 hours," but a sequence of touchpoints tied to user behavior on the site.

The first email goes out 30-60 minutes after the cart has been left idle: during this time the person still remembers what they were choosing, and the probability of return is at its highest.

Then comes a second touchpoint after 24 hours and a third after 3-5 days if the order still hasn't been placed. This scheme recovers a noticeable share of abandoned carts, whereas a single "you forgot something" email barely works.

The key parameter here is reaction speed. While the email is in transit for hours, the customer either buys from a competitor or cools off on the purchase.

We configure sending so that the notification goes out within an hour of the event, rather than as a batch send at the end of the day. This directly affects cart conversion: the shorter the gap between the action and the email, the higher the share of recoveries.

The second part is reducing manual work. When automated emails handle the initial touchpoint, managers don't waste time calling "cooled-off" carts and step in only where the customer opened the email or clicked the link.

The load on managers drops, and attention goes to hot orders where human involvement genuinely increases the deal value.

We build the chain on data from the cart itself: we insert the order contents, the current price and stock levels, and add a return-to-cart link with the saved item.

If an item has gone out of stock or the price has changed, the email accounts for this — the customer doesn't land on an empty page and doesn't lose trust. We configure segmentation separately: authorized users and guests, repeat and one-time buyers receive different scenarios.

All of this works on the standard tools of 1C-Bitrix and Bitrix24 without external email services, so order data never leaves your environment. We configure logging of sends and unsubscribes so you can see which steps in the chain recover orders and which can be removed.

Delivery Methods: Transactional Emails, Bulk Campaigns, and External Services

An abandoned cart notification is a transactional message: it is triggered by a specific user's action and must reach that exact person.

If you send it through a bulk campaign, the email falls under the general warm-up and domain reputation rules, and the trigger loses its targeting. Let's break down which delivery channels are actually used and where each one has its limits.

What Determines Deliverability

The key factor is not the sending engine, but the reputation of the sending domain and the correctness of authentication. Abandoned cart emails are best sent from a separate subdomain: that way, complaints and unsubscribes don't affect your main business correspondence.

Email templates are built on cart data — contents, total, link back to checkout — and are populated at the moment the trigger fires, not during export.

How It's Chosen in Practice

For an online store with a flow of hundreds of orders, transactional emails via the platform with a dedicated subdomain are sufficient. When segments, A/B template tests, and open-rate analytics are added, a bulk email service is connected.

A mail gateway is justified when volume grows and detailed control over bounces and complaints is needed. Often the setup is combined: transactions go directly, while reactivation series go through a service.

Stages of setting up abandoned cart notifications

Setting up abandoned cart notifications is not a matter of ticking a checkbox in the settings, but a sequence of work where each stage relies on the data from the previous one. Below is how we run a project from event audit to handover of regulations.

1. Audit of events and data. We look at which customer actions are recorded in the system: adding a product, changing quantity, entering checkout, leaving the page.

   We check whether the cart is tied to a user or to a session, and how the contact is stored — from the profile, from a form, or from a cookie. At this stage it becomes clear which events can even be used to build triggers, and where there is not enough data.

2. Designing the notification scheme. We define the chain: how many emails, at what intervals, and what happens when the customer returns. We fix the stop conditions — a completed order, unsubscription, resending.

   The scheme is agreed upon before work begins, so that the logic does not have to be redone on live traffic.

3. Setting up triggers. We implement cart selection by idle time, exclude service and test accounts, and connect email templates with product substitution and a link to return to checkout.

   We separately configure the sending schedule so that emails are not sent at night or on weekends, when their open rate drops.

4. Testing the emails. We run scenarios on test carts: a single product, several items, a removed product, an already completed order. We check delivery to popular email services, the correctness of the layout on mobile, and the working of links and unsubscription. We separately check that the customer does not receive two emails in a row on a repeat visit.

5. Launch and monitoring. We enable the mailing on part of the traffic, reconcile the actual sending with the plan, and track returns to checkout. If the share of opens or clicks is below expectations, we adjust the intervals and the text.

6. Handover of documentation and regulations. We give the client a description of the scheme, a list of triggers, email templates, and instructions for edits.

   We record how to change intervals and stop conditions without a developer, so that the client's team can manage the mailing independently.

Describe your task — we will come back with an estimate and a work plan for your project.

What the client receives after setup: configurations and regulations

The output is not a "configured mailing" but a package that your team can maintain without us. Each artifact covers its own area: emails, trigger logic, segments, and employee actions.

• Email templates — three to four scenarios for different behaviors: abandoned the cart at the selection stage, reached checkout and left, did not open the first email. Texts, subject lines, substitution variables (name, cart contents, return link) — in separate files, editable without calling a developer.
• Trigger scheme — a map: which event launches the email, after how many minutes or hours, under what conditions it stops. Exceptions are described separately: completed order, unsubscribe, repeat cart — so the client does not receive two emails in a row.
• Segmentation rules — by which attributes the audience is divided into groups: new and repeat buyers, product category, email activity. For each segment, it is specified which template and which delay apply.
• Instructions for employees — what the manager sees in the panel, how to manually remove a client from the mailing, where to look when there is a complaint about an extra email. Without this, the setup lives only until the first question from the sales department.
• Maintenance documentation — where the templates are stored, how to change the text and interval, how to check that the email was sent, how to roll back a change. With a description of the points where the logic most often breaks.
• Verification regulation — the frequency of checks: whether emails are arriving, whether there is growth in unsubscribes, whether data is being substituted correctly. With an indication of the responsible person and the threshold after which intervention is needed.
• Rollback scheme — how to return to the previous behavior if the new logic fails: which settings are saved before launch and in what order they are restored.

We hand over everything in your repository and on your infrastructure — without being tied to us. Describe the task, and we will come back with an estimate and a plan for your catalog and funnel.

Case Study: How We Restored Email Delivery and Brought Orders Back

The project is an online store on 1C-Bitrix with several thousand SKUs and a daily stream of orders. The client complained about "silence": customers added items, left, but never received reminder emails. In reality, abandoned carts were piling up, and there was no way to follow up with the buyer.

What We Found

The investigation showed that the email template and the mail handler were configured correctly, but the event that was supposed to trigger sending wasn't firing.

The cart handler had a condition that cut off some scenarios: the email was only generated for a certain order status, and some abandoned carts never reached that status.

On top of that, some addresses were filtered out due to a format validation error — valid mailboxes weren't passing the filter.

What We Did

We rewrote the event handler logic: removed the hard dependency on status and tied sending to the very fact of an incomplete cart.

We fixed address validation, added retry attempts for sending during temporary mail server failures, and added logging for every step — now you can see whether the email was delivered and whether the buyer opened it.

We set up a sequence: first reminder, second one a day later, and a final one — with a reminder about a product that will soon be out of stock.

Metrics Before and After

A month after launch, the share of recovered orders reached 11% of all abandoned carts — these are orders that would previously have simply been lost.

We also surfaced a separate metric on the dashboard: if the share of emails sent drops below 95%, a notification goes out to the responsible person. This kind of monitoring catches an event error the same day, rather than a month later when revenue has already dropped.

How a cart abandonment notification differs from a transactional email

A transactional email is a confirmation of an action already completed: the order is placed, the payment went through, the registration is finished, the order status has changed.

The recipient expects it and perceives it as part of the transaction, so such messages go out immediately after the event and do not depend on whether the customer reopened the site.

The sending logic here is rigid: the event happened — the email went out, with no pauses or conditions.

A cart abandonment notification is triggered, not transactional. It is tied not to a completed action but to its absence: the cart is filled, but the order was not placed.

This means the sending scenario is built on conditions — how much time has passed since the last cart change, whether the user is authorized, whether they have a confirmed address, whether they have already bought the same thing.

Without these checks, the email will go to someone who placed the order in a neighboring tab and will turn into an annoyance.

The difference also shows up in the content. A transactional email is a dry statement: number, contents, status, link to details.

A triggered cart email is a return to an unfinished selection: a reminder of the items, a link to the cart with the saved contents, a gentle reason to come back. Personalization based on catalog and inventory data matters here, otherwise the email loses its meaning.

For setup, this means different infrastructure. Transactional sends go through a single template and a single event handler; there are few of them and they are predictable.

Triggered ones require a scheduler that periodically checks unfinished carts, stores the sending history, and can stop the chain when an order is placed.

These flows cannot be mixed in a single template: different launch conditions, different frequency, different unsubscribe requirements.

Hence the practical conclusion: first we separate the flows at the level of events and templates, then we configure the conditions and delays for triggered emails, and only after that — the copy and design.

If this is not done, some emails will go to the wrong recipients, and repeat reminders will start arriving after the purchase.

Common technical questions about notification setup

A cart abandonment email is a transactional message, but email providers judge it by the same rules as a bulk mailing: domain and IP reputation, the presence of SPF, DKIM, and DMARC, and the share of complaints and clicks.

If the domain is new or a bulk mailing is being sent from it in parallel, emails start landing in "Promotions" and "Spam" — the cart is formally abandoned, but the customer never sees the notification.

This is fixed not by the email copy, but by configuring sender authentication and moving the transactional flow to a separate subdomain so that reputation doesn't get mixed with marketing.

Duplicates are the second most common cause of irritation. They appear when the add-to-cart event is processed both by agents and by an event handler, or when a repeated agent run doesn't check whether an email for that cart has already been sent.

The solution is idempotency: a unique key by user and cart, a send flag in the database, and blocking repeated runs.

How can duplicate emails be avoided with certainty?

Idempotency at the data level: we write the fact of sending to a separate table with a unique index on the "user + cart" pair. A repeated agent run sees the record and doesn't send the email a second time.

Additionally, we eliminate the overlap between agents and event handlers so that a single action doesn't trigger sending twice.

What should be done if sending fails or the mail server is unavailable?

We put sending into a queue with retries and increasing delay. If the external server doesn't respond, the email isn't lost but waits in the queue.

We write all attempts and errors to a log — it shows at which step and why the sending failed, and the incident can be investigated without guesswork.

How can you tell that notifications actually arrive?

We keep logs of sending and delivery statuses, and on the email service side we look at reports on delivery, opens, and clicks. If the share of spam placements grows or deliverability drops, it's visible before customers start complaining. Using the same data, we configure the frequency and triggers of emails.

Let's discuss your abandoned cart notification task

To come back with an estimate and a plan rather than generalities, we need baseline data on your project. Below is what we clarify and in what form to send it, so the review is substantive.

• Platform and edition. Bitrix or Bitrix24, the edition, the online store module, connected notification channels. This determines which events already provide cart data and which will have to be collected.
• Cart scheme. Where it is stored: tied to the user, to the session, or to both; how long an abandoned one lives; whether carts are merged on login. This determines the criterion by which a cart is considered abandoned.
• Recovery scenarios. What is already being sent — emails, messenger messages, a manager's call. Which steps and how long after abandonment. This way we don't duplicate what already works.
• Customer data. Consents to mailing, profile fields, order history. Needed so the notification is appropriate and doesn't go to those who have already purchased.
• Infrastructure. How email sending is set up, who the provider is, whether there are limits on volume and domain reputation. The queue and retries are part of the work.
• Accesses. A test environment, a database copy, access to settings and logs. Without a staging environment, scenarios can't be tested blindly.
• Timeline expectations. By what date the launch is needed and whether there is a tie-in to a promotion or season.

Describe the task in free form — what you're unhappy with in the current notifications and what result you need. We'll come back with an estimate and a plan: the stages, what we do at each, what data we need from you, and what timelines we can meet. The work format is remote, with fixed synchronization points on progress.