Setting up email sequences in Bitrix24: CRM marketing automation

Why email sequences in Bitrix24 fall apart at scale

While a pipeline has dozens of deals, mailing scenarios are held in the manager's memory: who received the second email, who to bring back in three days, where to set a reminder.

At scale, the scheme falls apart — some emails don't go out at all, some go out repeatedly, and the correspondence history in the card diverges from the actual dialogue.

The cost of such a breakdown is not in one missed email.

A customer who receives two identical emails in a row reads this as a failure and stops opening the next ones; the manager manually reconciles what was sent instead of working with deals in the active stage, and the head cannot answer how many inquiries actually reached a touchpoint.

The root is usually one — sending is not tied to a change in deal stage. A robot or business process is set to an event that triggers twice: when the stage rolls back, when the card is edited again, during a mass import of contacts.

There is no send log, so the system doesn't know that the email has already gone out and generates duplicate emails.

Added to this are manual reminders that live in the activities of a specific employee: the person went on vacation or moved the deal — the sequence broke in the middle, and the customer fell out of communication.

We'll break down how this is closed: how to build email sequences in Bitrix24 so that correspondence automation doesn't depend on human actions and doesn't allow repeats.

What changes after implementation: time, delivery rate, bounces

First days: a scenario instead of a development request

The sequence is assembled in the constructor: trigger by deal status, branching by card fields, email templates with customer data substitution.

Bitrix24 launches a new scenario in a few hours — where previously they waited for a developer and a database export, now a marketer makes the change. This is the first measurable shift: the launch time of a new scenario is reduced from weeks to one business day.

First month: delivery, response, losses

The share of delivered emails grows due to a configured sender domain, signature, correct processing of unsubscribes, and gradual reputation warm-up: 97–99% versus 80–85% when sending from a shared mailbox. Emails land in the Inbox, not Spam — without this, the whole sequence loses meaning.

Response time to a reply drops to 1–2 minutes: the email goes out automatically, and the manager receives a task with the correspondence context. Previously, a response waited for a free window and cooled down in the general flow.

The share of lost inquiries is reduced to a few percent: every customer action creates a deal and a record in the pipeline, nothing settles in personal email.

You can see at which step of the sequence there was a response and where it faded — the effect of automation becomes verifiable, not declared.

Sending modes in Bitrix24: comparison of four approaches

In Bitrix24, an email sequence can be assembled in four different ways, and they differ not in the set of tools, but in what serves as the trigger condition for each step. This affects both the predictability of sending and how cheap it is to change the logic later.

The choice is dictated by the pipeline: the length of the sequence, the number of branches, and the team's readiness to move part of the data outside the portal. Below are four sending modes with their strengths and boundaries.

The common limitation of automation in all four modes is the same: the scenario works exactly on the data in the card. An empty contact, a duplicate deal, a value entered in a free-text field — and the step either doesn't trigger or goes to the wrong recipient.

Therefore, before assembling the sequence, we record which fields are mandatory and who is responsible for filling them.

Implementation stages: from scenario audit to handover

We work sequentially: first we record what is already happening in correspondence with customers, then we design scenarios, and only then do we put sending into production.

This order removes the typical problem when sequences are configured but some deals don't fall into them — pipeline stages and launch conditions have diverged.

1. Correspondence audit. We analyze deal history: at which stages the customer stops receiving replies, where managers manually duplicate the same thing, which emails go out without regard to stage.

   The output is a list of points where automation changes the picture instead of creating a flow of unnecessary messages.

2. Scenario map. We break down the customer journey by stages: launch condition, pause between emails, stop condition. We agree on the map — who receives the email, what happens when the customer replies, the stage changes, or there is no reaction.

3. Sending setup. We assemble templates for each email, connect the domain and mailbox, set up substitution of data from the deal card. We separately delineate rights: who edits text, who launches the mailing, who only views statistics.

4. Test environment. We run each sequence on test deals — emails don't go to real customers, but the whole path is recorded. We check edge cases: a reply in the middle of the series, a return to the previous stage, a repeat inquiry from the same contact.

5. Team training. We show managers and the marketer where to view opens and replies, how to stop a series for a specific customer, and how to connect a new pipeline participant.

6. Handover to support. We hand over the regulations, scenario map, and access rights, and record the procedure for edits. After that, sequences live as part of the CRM: you can add a step or change text without rebuilding from scratch.

At each stage, an artifact remains — a list of growth points, a scheme, templates, a test run report, and regulations. From them, you can see what exactly is configured and why.

What remains in your hands: schemes, rights, regulations

Setting up a sequence is not only emails in the interface but also agreements on who will change it and how going forward.

Therefore, at the end of the project, we hand over a set of documents according to which sequences develop without us: from the scenario map to employee instructions. Everything is in your portal and in a shared folder, not in correspondence with the contractor.

• Scenario map — a table: launch event (lead creation, deal stage change, deadline expiration), audience, email number in the sequence, exit condition. From it, you can see why a specific contact received an email or fell out of the mailing.
• Email templates — blanks with substitution of data from the card (name, company, responsible manager), subject lines and first line of preview, a separate branch for resending if the email was not opened.
• Segmentation rules — which fields and filters form a segment, who is responsible for data accuracy, where contacts with unfilled fields go: they are not lost but go to a separate group for manual review.
• Access rights matrix — who creates and edits templates, who only launches sending, who sees statistics on opens and clicks. Rights are assigned by roles so that an accidental edit doesn't go to customers.
• Edit regulations — work procedure: draft, test send to an internal address, check of substitutions and links, approval, publication, rollback to the previous version. It is recorded whose "OK" is final.
• Employee instructions — a short document with screens: how to add an email, change the launch condition, view the reason why an email didn't go out.
• Change log — what was edited, at whose request, and how it affected opens and replies. It helps avoid repeating unsuccessful experiments.

Case study: how manual reminders were replaced by managed scenarios

The project is a sales department of eight managers: inquiries came from the website, email, and messengers, and each person kept a reminder about the next step in their own spreadsheet. About 120 emails went out manually per week, every third with a delay of a day or two.

According to the quarterly export, 17% of inquiries received no response at all: the customer went to the one who replied first.

How scenarios were arranged instead of manual reminders

In Bitrix24, correspondence was moved to managed sequences: an email is tied to the deal stage and goes out on status change, and a condition based on customer inactivity returns the dialogue after a specified period.

Templates substitute the name, company, and inquiry data, so the email remains personal but assembles itself. A separate rule stops the sequence as soon as the customer replies or the deal is closed — extra touchpoints don't go out.

Metrics before and after

First response time decreased from six to eight hours to fifteen minutes — this is the first thing the customer sees. There are no inquiries left without a response: the scenario sets a task for the manager and escalates it if there is no response.

Manual reminders disappeared as a class of work — eight people stopped maintaining spreadsheets, and inquiries through the sequence began reaching the sales department without losses during handover between shifts.

What to do if scenarios are already configured but don't work?

Scenarios most often "break" not in the email template but at the junction of the card and the launch condition.

The condition is checked at the moment the entity changes: if the field by which you expect triggering is filled later or by another responsible person, the rule simply doesn't trigger and the log stays silent.

Scenario diagnostics begins with the log: we look at whether the deal reached the required stage, what field values were at that moment, and whether they match the condition.

Rule conflicts and duplicates in the mailing are the second most frequent cause, and it is more dangerous than the first: the customer receives two emails a minute apart, while the manager sees one in the card.

It is treated not by disabling the scenario but by an explicit order: one rule owns the transition, the others check that the email has already been sent.

We fix scenarios on a copy of the pipeline with test contacts: we run transitions, check the log, and only then transfer the edits to working data. In Bitrix24, the check takes one run, but production doesn't get duplicate emails and lost leads.

Common technical questions before implementation

Before launching sequences, the customer checks several things: what to do with already configured scenarios, how the system will behave when a customer replies, and whether automation will turn into additional routine for the department. Below are answers to doubts that most often arise at the design stage.

Each answer describes behavior at the level of rules: launch conditions, steps, delays, and stop points. If your case is different, we analyze it separately on your pipeline.

What happens if the customer replies in the middle of the series?

The sequence stops: the remaining steps are canceled, the card is marked, and the reply goes to the responsible person. You can leave a soft option — pause until the manager's decision and return the customer to the same sequence.

How is the email deliverability issue solved?

Emails go from a corporate domain configured for mass sending: confirming records and a separate subdomain for mailings so that the reputation of the main domain doesn't suffer. Bounces and complaints are visible in statistics.

Does this heavily load employees?

Setup is a one-time job: rules, texts, checks. After that, routine goes into automation, and the department deals with replies, not reminders. The load grows only at the stage of email approval.

Can everything be checked without real recipients?

Yes. Test sending goes to internal addresses: we check the order of steps, delays, substitution of data from the card, and behavior when a field is not filled. A test run on a test deal does not affect live customers.

Let's discuss the task: what to prepare for the conversation

An accurate estimate for Bitrix24 email sequences rests on three things: how the pipeline is structured, where communication currently breaks, and which systems should receive deal data.

If managers already run deals in the CRM, but send some emails manually from email, that is enough for the calculation — we will reconstruct the logic from actual actions, not from a description of "how it should be." Below is what is worth collecting before discussing the task.

• List of deal stages and transition rules between them: what exactly the manager records in the card — call, invoice, contract, refusal. This determines at which step the email triggers and which field stops it.
• Examples of current correspondence: 2-3 emails for each stage, including touchpoints for deals that "went silent." They will show the tone, volume, and which emails can be reused.
• Integration points: website forms, telephony, 1C, mailing service, meeting calendar. We need to understand where the event comes from and where to write the sending result.
• Access rights: which employees approve texts, who sees statistics on opens and replies, from whose address emails go out.
• Stop rules and frequency limits: what we consider a response, how long we wait for a reply, after which event the sequence is interrupted, what sending limit the mailbox can handle.
• Requirements for mailing consents and customer data storage — they affect which segments can be included in automatic touchpoints.

Describe the task in free form and attach what you already have. We will return with a work estimate, a sequence scheme, and a staged implementation plan — from setting up the pipeline and triggers to testing on real deals and handing over to the team.