Setting up automatic email sending from Bitrix24 CRM

Why automatic email sending from CRM breaks

Automatic email sending from CRM relies on a combination of three things: a template, a trigger condition, and the data that is substituted into fields. Usually it's not the template that breaks, but the condition — a rule in Bitrix24 is tied to a deal stage, not to an event.

Because of this, automatic email sending triggers again every time a deal returns to a previous stage: the client receives a second email, and you learn about the extra message in the correspondence from the client themselves.

Duplicate notifications and changing the responsible person are the second common pair of failures. When a deal is transferred to another employee, some rules continue to send emails to the previous address or to the department's shared mailbox.

The recipient in the template is substituted based on the responsible person, not on the deal participant, so the email goes to the wrong person who is actually doing the work.

The third scenario is a stuck queue. An email got into the queue, but it could not be sent: the address is not filled in, the domain rejects reception, an empty substitution field remains in the template.

The entry does not disappear and is not sent, and subsequent emails line up behind it and also fail to arrive.

At the same time, the sending failure from CRM does not surface anywhere — it is not visible in the deal card, so the problem is discovered when the client is already waiting for a response.

We analyze how this is closed: we look at what the rules are tied to, rebuild trigger conditions, and add delivery control.

What setup gives: measurable effect for the sales department

Auto-notifications change not the fact of correspondence itself, but the moment it begins. An email goes out the same second a lead is created or a deal stage changes — without a pause for the manager to open the card and remember about it.

The time to first response stops depending on a specific employee's workload: a request that comes in the evening or on a weekend receives confirmation immediately, not the next morning.

The share of requests processed without manual involvement is the most honest indicator of order in the settings.

When a template is tied to a stage and substitutes deal data, a typical email is not written by hand: the manager confirms sending or immediately moves to the substantive part of the conversation.

The speed of reaction to a lead becomes the same for a strong and a new employee — because it is determined by a rule in the system, not by personal discipline.

Lost requests disappear where chains used to break. A website request, an email to the shared mailbox, a message from a messenger — everything turns into a lead and is distributed to the responsible person, rather than settling unread.

If the responsible person is unavailable, escalation triggers: a notification goes to the manager, and the deal does not remain without movement.

The effect of automation is visible not in beautiful emails, but in the fact that control stops being manual.

The time to first response and the number of requests without reaction are measured by a report, not by the team's self-perception — and from these numbers it is already clear where the setup works and where refinement of logic, fields, or access rights is needed.

Launch methods: scenarios, robots, and batch mailings

An email from CRM is launched not 'in general', but on a specific occasion, and the launch method defines three things: how quickly the message will go out, what can be substituted into it, and how the system will survive a mass data change. Below are the options that are actually chosen between on a project, and the limitations of each.

The choice logic is simple: single emails are tied to an event or stage, and everything that goes out in hundreds is moved to batch launch with separate access and frequency checks.

In practice, methods are combined and a stop rule is added — so that the client does not receive two emails about the same thing.

Implementation order: audit, scheme, setup, verification, handover

We start work with an inventory, not with editing templates: if you immediately enable new triggers on top of existing ones, the client starts receiving two or three emails about one event, and some of them go out without taking the deal stage into account. Therefore, we first record what already works and which events should generate an email at all.

1. Notification audit. We export all active scenarios, templates, and sender addresses, and compare them with real business processes. Usually after this, a noticeable share of scenarios that duplicate each other or trigger on outdated stages is disabled.
2. Email route scheme. We build a map 'event → recipient → template → sender mailbox', separately marking copies and service addresses. The scheme is approved before setup — this way, edits to logic cost an hour of work, not a redo of the entire contour.
3. Trigger setup. We tie sending to deal stages, deadlines, and client actions, and set trigger conditions, delays, and exceptions. We check that a repeated event does not generate a repeated email.
4. Test run. We run scenarios on test deals: we check delivery to external email services, correctness of field substitution, attachments, and Cyrillic in subjects and file names.
5. Control on the production contour. For the first days, we run sending on a limited flow and check the log: we cut off false triggers before they become a habit for employees.
6. Documentation handover. We provide a route regulation, a template registry, and rules for changing them, so that your team can edit texts and conditions independently.

What remains with you: templates, sending log, regulations

Automatic email sending in Bitrix24 lives not in code, but inside the system: in templates, launch conditions, and access rights.

Therefore, we hand all this over as ready-made artifacts — so that an administrator or a new manager can change text, add a scenario, and find the cause of a failure without us.

• Email templates — one per scenario, with subject, signature, and substitution of card fields: name, deal stage, responsible person, contact. For each — a short note on which variables come from where and what must not be deleted from the body, otherwise the email will go out empty.
• Scenario map — a table 'event → recipient → template → delay → repeat'. It immediately shows where an email goes to the client, where a notification goes to an employee, and which chains intersect with each other.
• Access rules — which roles see mailboxes, who is allowed to edit a template, what happens to sending when the responsible person leaves and the deal is transferred.
• Instructions for managers — one or two pages: how to send an email manually, what not to change in the body, where to go if the client reports that they received nothing.
• Error investigation procedure — where to look at the sending log, how to distinguish a typo in the address from a rejection by the recipient's mail server, who receives a failure notification and within what timeframe it is handled.
• Control set of checks — test sending to your own addresses before publication, checking external mailboxes and emails with attachments.
• Change regulation — who approves text edits, how a new revision is recorded, and how to roll back to the previous one if the new wording reduced response.

With this set, the system remains manageable: edits do not break scenarios, failures are visible in the log, and task handover within the team does not require re-analyzing the mailing logic.

Case study: how we removed stuck notifications in the sales department

This implementation case study began with complaints from the sales department: notifications about new requests arrived with a delay or did not arrive at all, and automatic email sending in Bitrix24 worked like a black box.

At peaks — during advertising campaigns and mass mailings — some emails went into the queue and got stuck there. Managers learned about a request after 30-40 minutes or from a client's repeat call, who had already managed to write to a competitor.

Incident analysis

We pulled up the sending log for two weeks and saw the picture: notifications about requests and mass mailings went in one stream.

At a peak of several hundred emails per minute, the queue grew faster than it was processed, and when sending failed, the email was simply lost — no retry was provided, the error settled in the logs and bothered no one.

What we changed

We separated the streams: notifications for requests and deals received a separate priority queue, while mailings got their own.

We added a retry on failure with an increasing delay, a status for each email in the log, and an alert if more than a specified threshold accumulates in the queue.

Metrics before and after

The share of delivered notifications grew from 82% to 99.4%. The time from request appearance to email to the manager decreased from 30-40 minutes at peak to a few seconds.

Stuck notifications stopped being a regular occurrence: isolated cases are visible in the log and handled via alert within minutes, rather than by searching logs for half a day. Sending stability is now measured, not discussed at planning meetings.

How does an event-based scenario differ from a scheduled mailing?

The difference is in what serves as the email's trigger. An event-based scenario triggers from a client action or a card change: a completed form, a deal moving to a new stage, a reply to an email, a click on a link.

A scheduled mailing is triggered by the calendar and does not depend on the recipient's behavior — it goes out on the appointed day.

In Bitrix24, the trigger logic is assembled from three parts: condition, delay, and email template.

The condition checks fields and events, the delay sets a pause (the email goes out not immediately, but if there was still no reaction), the template substitutes deal data into the text.

A schedule is simpler: a set of emails with a step by days that leads the client along a pre-known route.

The task dictates the choice of mode. If you need a reaction to an action — registration, invoice request, incomplete request — take an event: the email arrives at the moment of interest and less often goes to spam.

If you need planned touches with the client at an even rhythm — training after purchase, reminder about service expiration, a warm-up series — a schedule works, because there is nothing to tie it to in the card.

In practice, modes are not opposed but combined: a schedule provides a framework of touches, an event adds reaction.

It is important to separate conditions so that the client does not receive two emails in one day — in the settings this is solved by checking the fact of a previous sending and the order of rule execution.

Common doubts: duplicates, spam, access rights

Duplicates are almost always a consequence of logic, not a failure: several robots trigger at one deal stage, a manual launch goes on top of an automatic one, an import of history re-runs already sent notifications.

The client receives two emails in a row, the manager stops trusting notifications and starts checking the funnel manually.

The second risk is domain reputation. If emails go directly from a work email without configured sender authentication, some settle in the recipient's spam, and this hits all future mailings at once.

Mass manual sends from the card make the picture worse, so they are limited by volume and frequency.

Will emails go to spam?

The risk is removed by domain setup: sender authentication, a separate subdomain for service notifications, and limits on mass mailings. We check the first sendings on control mailboxes at several email services.

Will managers retain manual sending?

Yes, but within set boundaries: the template, recipient limit, and frequency are set by role. Live contact with the client remains, and domain reputation is not destroyed.

Let's discuss the task: what to send for an accurate estimate

So that the estimate of work is based on facts, not assumptions, we need just a few inputs on the project. From them, the scope of setup, the number of scenarios, and the places where integration with 1C or an external sending service will be required are visible.

• A list of events that should trigger an email: deal stage change, new lead, issued invoice, reminder to the responsible person.
• Mailboxes and domains for sending, as well as restrictions from the email provider on volume and frequency of emails.
• Current templates: whether refinement is needed, how the signature is formatted, whether there are branding requirements.
• Which CRM fields are substituted into the email and which data should be pulled from 1C.
• Recipients: only clients, only employees, or both directions at once.
• Access rights — who edits templates, who sees the sending log and deal history.
• What is unsatisfactory now: emails go out manually, get lost between stages, or end up in spam.

Describe the task in your own words — that will be enough to come back with an estimate and an implementation plan.

The start order is simple: a short analysis of inputs, then a proposal on scenarios and timelines, after approval — setup on your portal without stopping current work.