Setting up triggered email campaigns in Bitrix24

Triggered email campaigns in Bitrix24: where the chain breaks

Triggered email campaigns in Bitrix24 are designed as part of a funnel: an event in the card changes the stage, and the stage launches automatic emails by event. While the scheme is on paper, everything matches.

On a live deal flow, the chain breaks in places that are not visible in the robot designer — and the client receives neither an email nor a call.

The first bottleneck is stage transition conditions that remain unmet. The rule waits for a filled deal field or confirmation from the client, but cannot actually fire, and the notification scenario simply remains in waiting mode.

The second is empty and non-standard card fields: substitution into the email template takes a value from a field that does not exist, and sending is delayed or goes out with empty lines.

Then manual work intervenes. A manager moves the deal to the next stage via the list, bypassing the form — some rules do not fire, and some are triggered twice.

When several scenarios overlap on one stage, conflicting rules mute each other: the first email goes out, the second no longer passes the condition check.

The result is that a bottleneck in the sales funnel occurs before the first conversation with a manager. A client who left a request waits a day or two for confirmation, cools down, or goes to those who responded faster.

The sales department learns about the problem from the client rather than from the system and spends time on manual follow-up emails instead of deals.

Below we look at how this is solved: where to view the send log, how to check transition conditions, and how to separate notification scenarios between stages so that emails are not sent twice and are not lost.

What event-based email automation in deals provides

Manual reminders to clients rely on the manager's memory: while there are dozens of deals, this works; further, some steps simply do not reach the recipient.

Event-based email automation in Bitrix24 removes this dependency — an email goes out upon stage change, invoice issuance, client reply, or a pause in correspondence, not based on the remaining attention of the person responsible.

Manager response speed begins to be measured by configuration rather than department discipline: in manual mode, the first touch takes from several hours to a day; when working by events — minutes.

A response to client action arrives while interest is still alive, and this is immediately visible in the share of replies to the first email.

The share of lost inquiries falls for another reason: the event fires regardless of workload, vacation, or change of responsible person. The deal was transferred to another employee — the chain continued by the same policy, and no inquiry was left unanswered due to human factor.

Manual workload is calculated simply: how many emails per day the employee wrote themselves and how many of them were repeats on the same subject.

After switching to events, only those messages remain where a person is truly needed — discussion of terms, a non-standard request, a disputed deadline.

Predictability of communication is the final effect: each deal has the same set of steps and a clear log of who received the email and when.

Before launch we fix the criteria: which events we take, how long we wait for a reply before a reminder, who receives a notification on send failure.

Campaign modes: event, schedule, condition

The launch mode determines when an email goes out: immediately after an event in CRM, at a designated moment, or after accumulating conditions. This affects both the campaign behavior when the deal status changes and how much manual work remains for the manager. Below are four modes and their limitations, which most often surface during operation.

The combined mode is not a separate mechanism but an assembly of the basic ones: an email goes out by event, then a pause, condition check, and second step.

For several sales funnels, rules are isolated by funnel and stage, otherwise a lead will receive an email from another scenario. We run each mode on a test funnel before enabling — this is cheaper than stopping the campaign after the first complaints.

Step-by-step implementation: from diagram to launch

Implementation of triggered emails in Bitrix24 starts not with templates but with an inventory of what already works.

The account usually has robots at stages, business processes, and old rules: some duplicate each other, some are silent due to an unmet condition, and this can only be seen in the send log.

1. Scenario audit — export rules, stage robots, and templates, reconcile with the log: where duplicates are, where the email does not go out, where the recipient has already unsubscribed.
2. Event scheme — table "event → condition → template → delay → responsible person". It shows intersections: a deal falls both into a stage email and a segment campaign.
3. Send rule setup — trigger conditions, stop conditions (client replied, deal closed, unsubscribe), and frequency limit: no more than one email per contact per specified period.
4. Templates and variables — substitution of deal and contact fields, checking that with an empty value the email does not go out with a blank spot in the text.
5. Test send — run on test deals: create duplicate cards, move stages, check substitution, time zones, spam placement, and unsubscribe link behavior.
6. Fault tolerance check — behavior when the address is missing, the deal re-enters the same stage, or the responsible person is changed manually.
7. Handover of settings and training — diagram, accesses, instructions, walkthrough with employees; the first week we reconcile the log with the plan.

Handover package: diagrams, rules, regulations

A handover package is not a folder of files "just in case" but a set of documents by which a new administrator or manager reproduces campaign operation without contacting us. Below is what exactly remains with the customer after the triggered campaign setup is handed over.

• Scenario map — scenario diagram with launch points: which event in CRM or on the website raises the campaign, which conditions are checked before sending, in which branch the email goes out and in which the user drops out of the chain.
• Sending policy — launch rules: time windows, limits on the number of emails per day to one recipient, resend rules after open or click, conditions for stopping the series on purchase or unsubscribe.
• Email templates and variables — the templates themselves with substitutions from deal, contact, and company fields, so a marketer can edit the text without breaking the substitution logic.
• Access rights matrix for settings — who can create and enable a scenario, who only edits the template, who sees statistics: access rights to settings are separated by roles, not granted to everyone by the administrator.
• Instructions for managers — a short document on frequent actions: how to pause a campaign for a specific client, how to exclude an address from a series, what to do on a spam complaint.
• Change procedure — campaign documentation is kept in one place: a scenario edit is tested on a test contact, and the version of rules is recorded to understand why the email went out exactly that way.

Such a package removes dependence on a specific contractor: scenarios, sending policy, and rights are described enough for the customer's team to edit them independently, and for us to get involved only on complex changes.

Case study: before and after — failures, response, workload

Project — an industrial equipment supplier: 250–300 inquiries per month, a department of five managers, all client work in Bitrix24.

Campaigns hung on the event "lead created" and did not account for client return: a person with an already open deal received the first-touch email again, and unsubscribed contacts remained in the selection. Email failure rate held around 17%, and email providers increasingly sent the entire flow to spam.

What was breaking before the edits

• The trigger fired on entity creation, not stage change — on repeat inquiry emails were duplicated.
• Unsubscribes were logged but not excluded from future selections.
• After the auto-reply, the request landed in a shared list without an owner: the client waited for a live manager for 5–6 hours.

What was changed and what happened

The trigger condition was moved to stage change and the appearance of a new contact channel; before sending, a database check was added.

Unsubscribes and closed deals were moved to a separate exclusion list; streams of service and marketing messages were separated with different domain signatures.

For new requests, escalation was configured: if a manager did not take it within 15 minutes — a notification goes to the supervisor and is forwarded to an available manager.

The share of failed sends fell from 17% to 2–3%, spam complaints almost disappeared, and average request processing time decreased from 5–6 hours to 25–30 minutes.

Manual sending — about 40 messages per day — moved fully to triggers: each manager freed almost two hours for calls and equipment selection.

What to do if some scenarios are already set up manually

We start with an inventory of campaigns: export all robots, triggers, automatic CRM rules, email templates, and business processes related to deals and leads. For each rule, record the launch condition, audience, channel, and date of last edit.

Often already at this stage it is visible that some already configured scenarios have never fired, and half duplicate each other on the same stage.

We sort duplicates and conflicts by effect: if two emails go out for one deal with a one-minute interval, the client reads the second as pushiness, and false activity appears in the card.

Such pairs are merged into one scenario with a common condition and one entry point — instead of two disputed rules, one predictable one remains.

We transfer manual rules without stopping sales: we do not delete the old rule but switch it to disabled, and launch the new scenario on a shadow segment. Some deals follow the new logic, some the old — we compare firings and email content.

A discrepancy becomes a reason to refine the condition rather than disable everything at once; rollback is one action, the previous rule turns back on.

Then we switch in blocks, stage by stage, with a pause to check the sample. Bitrix24 stores the history of robot changes, so it is visible who changed the logic and when — when parsing conflicts, this saves hours.

Common failures: spam, duplicates, repeat touches

A triggered campaign in Bitrix24 usually breaks not in the designer but at the border with the mail server and on repeat events.

The customer sees a symptom — an email in spam, two identical emails in a row, a repeat touch after the deal returns back — and concludes that automation does not work.

Client receives two emails in a row — is it a failure or a setting?

A setting. A trigger often hangs on both element creation and change, and during work the deal changes the responsible person and fields.

We set the condition "status changed to the required one", add a service flag field "email sent", and cut repeats by deal ID.

Deal returned to previous stage — will the email go out again?

Yes, if firing is based on the current status value: return and repeat transition launch the trigger again — that is how email duplicates appear. We tie sending to the last touch timestamp and keep a step log, so a deal status rollback does not produce a duplicate.

Let's discuss the task and come back with a work plan

So that the implementation estimate is based on facts rather than assumptions, we start the task review with source data.

The call takes about an hour: we look at the funnel structure, entity cards, and which events the portal already records itself and which will have to be added.

The following should be prepared in advance — this is enough for us to come back with a work plan for campaigns rather than clarifying questions:

• access to the portal with administrator rights and a separate test environment, if one is already set up;
• list of source events: deal stage change, abandoned request, overdue task, repeat inquiry;
• segments and attributes by which we divide contacts — where these fields in the card come from;
• delivery channels: email, messengers, messages within the portal;
• email texts and templates or the logic by which they need to be assembled;
• frequency limits: how many messages per day are allowed to one contact and at what hours we send;
• external systems — 1C, telephony, website, warehouse: what is already connected and which fields it exchanges;
• metrics by which you will judge the result: opens, clicks, those that reached a deal.

Send the list in any form — as a table, notes, or screenshots of cards. We will reconcile it with the current portal configuration, show which data already exists and which will have to be created, and come back with a work plan: stages, launch order, checkpoints.

We will run the logic on a test environment so that before enabling on live clients you can see which events fire and what goes into the campaign.