Setting up email funnels in Bitrix24 CRM marketing

Why Bitrix24 email funnels don't lead to deals

An email leaves Bitrix24, and some addresses don't receive it. Emails fail to arrive for various reasons: a domain without authentication records, an un-warmed sender reputation, a database collected without confirmed consent.

At the same time, no one measures email deliverability — the campaign is formally considered successful, although half of the chain is already broken.

Further, the gap is even more noticeable. The client replies to the email, but the reply does not turn into a request: the mailbox is not linked to a contact, the subject is not recognized as a reply to a specific campaign, and the source is not pulled into the card.

This is the gap between the email and the deal — the client's interest is recorded in the email, but not in the system.

Because of this, leads are lost: some settle in the manager's mailbox, some are closed with the wording "no response", and the deal stage stays in place while the client is already ready to discuss terms.

The manager is the last to learn about a warm contact — when that contact has cooled down or gone to those who responded faster.

The second half of the problem lies in the logic of the funnel itself: the transition between stages is tied to a manual action, not to an event in the email (open, click, reply). Without this, Bitrix24 email funnels remain a scheduled newsletter, not a sales tool.

We break down how this is closed: from setting up deliverability and linking the mailbox to leads to automatic transitions between stages and control of response times.

What changes after setting up email sequences in CRM

What share of emails is delivered and opened

An email sequence in CRM is sent not on the schedule of a bulk campaign, but on the event of a deal stage change — the email arrives while interest in the dialogue is still alive and lands in the card of the same contact.

Deliverability is determined by three things: a confirmed sender domain, no blanket sends across the entire database, and correct handling of unsubscribes.

When this is set up, the delivered rate stays above 95%, and the open rate of emails in the sequence is several times higher than that of a single campaign.

How many inquiries reach the deal

In Bitrix24, the client's reply does not settle in a separate mailbox: it is linked to the deal and removes the task from the manager.

The response speed is measured in minutes, not days — thanks to this, the conversation does not cool down, and the transition through stages is recorded in the history, not from memory.

Then the effect is visible on the funnel: automatic inquiries stop hanging between stages, because each email addresses a specific objection and pushes toward the next step. As a result, the share of leads that reach the deal stage grows, not just the number of emails sent.

Hence the main conclusion: value comes not from the email text itself, but from linking the email to the stage, response time, and owner.

Scenarios, modes, and limitations of email funnels

In CRM marketing, a funnel is assembled from two fundamentally different mechanics. An event-driven scenario is tied to a change in a deal stage or field and sends an email in response to an action.

A bulk campaign goes through a database segment and knows nothing about deal stages. Both work in the same portal and use the same sending queue, so mixing them in one flow without explicit launch conditions is the main source of duplicates and untimely emails.

Event-driven sequences vs. bulk campaigns

The choice is determined not by what is "more powerful," but by where the attribute lives. If an email must coincide with a client action, only an event-driven sequence will do. If you need to go through a database slice once, use a bulk campaign.

Limitations of scenarios and standard subscriptions

A scenario triggers only on the event that is actually recorded in the deal — an arbitrary condition on a calculated field will not launch it. Therefore, the "email sent" attribute is stored separately, and the step is not repeated when the deal moves back.

Consent to receive emails lives in the contact card, not in the deal: when importing a database, it is not set, and the scenario formally sends an email but actually collects complaints.

An unsubscribe in a bulk campaign must also disable event-driven steps — otherwise the sequence by stages continues to hit someone who has already opted out.

How we implement an email sequence: stages of work

The order of work is the same for a new scenario and for reworking what is already being sent: first we look at what exists, then we design the scheme, then we assemble and test on real people.

Skipping any step leads to duplicate emails, sends to invalid addresses, and a drop in domain reputation — that is why the stages follow strictly one after another.

Audit of emails, database, and current scenarios

1. We export the contact database and sending history: we look for invalid addresses, duplicates, repeated subscriptions, and spam complaints. Such addresses immediately go into exclusions — every email to them damages the deliverability of all the others.
2. We analyze already working campaigns: what events they are launched by, at what frequency, and where they interfere with each other. A frequent finding is three emails in one day from different scenarios.
3. We check the sending domain: authentication records, separation of transactional and bulk emails across different subdomains, and an unsubscribe link in every template.

Testing the scenario on a test segment

• We assemble the scenario scheme on paper: launch event, branching condition, pause between emails, exit condition from the sequence on purchase or unsubscribe.
• We prepare the emails: client data substitution, subject, preheader, source tags for analytics.
• We run the sequence on a test segment — employees and a small sample of the real database. We check that each step triggers, the branching works, there are no duplicates, and the scenario exits correctly.
• We hand it over for work: scheme, texts, edit regulations, and the person responsible for changes. After that, the scenario lives without us, and metrics for each step are visible in the panel.

Settings, segments, and regulations that we hand over

Setting up email funnels in Bitrix24 ends not with launching the first campaign, but with handing over a working contour to the team. Below is what remains in your account after delivery: without verbal agreements and settings "from memory in the interface."

Scenario scheme and segment map

• Scenario scheme: triggers, branching conditions, delays between emails, and exit points — both in the document and in the robot itself.
• Segment map: which contact and deal fields form a segment, by what rule it is recalculated, and what happens when the status changes.
• Email templates: subject, preheader, plain-text and designed versions, data substitutions, analytics tags — with notes on what can be changed without risk.
• Reply handling rules: how a reply returns to CRM, to whom it is assigned, how long it waits for a response, and how auto-replies are filtered out.

Regulations for handling bounces and complaints

• Unsubscribes and complaints: a separate scenario, exclusion of the contact from active segments, recording the reason, stopping sending when complaints grow.
• Undelivered emails: analysis of bounces by type, address cleanup, retry rule.
• Campaign documentation: scenario passport, edit history, pre-launch checklist, procedure for rolling back to the previous version.
• Instructions for the marketer: how to add an email or segment independently and in which cases a developer is needed.

The scheme and segment map become the point of truth for any refinement: a new employee is onboarded into the contour without questioning and reconstructing history from correspondence.

Case study: how the sequence stopped losing leads at the entry point

The sales department of a distributor managed deals in Bitrix24, but entry into the email funnel remained manual: the manager assembled the email themselves, the client's reply fell into a shared mailbox, and what happened next depended on whether they returned to that dialogue.

What it was like before implementation

Measurements over a month showed that up to 40% of second- and third-touch emails were not sent at all — the manager closed the active deal and did not return to the list.

Client replies were lost between folders: about 120 inquiries were recorded, some surfaced only on the next call, sometimes two weeks later. The sequence had no single state, so lost leads were reflected neither in reports nor in the supervisor's work.

What it became after

We assembled a scenario in CRM marketing: launch by the event "deal created", pre-approved templates, automatic pause on reply, and return to the sequence if the client is silent. The delivered email rate grew to 98–99%, and manual sending left the process.

Handling client replies stopped depending on the employee's memory: the email is linked to the card, sets a task for the manager, and moves the deal to the next stage.

The number of recorded inquiries grew approximately threefold — clients did not start writing more often; replies simply stopped getting lost. The average response time to an email decreased from a day to a few hours.

How does an event-driven sequence differ from a bulk campaign?

A bulk campaign runs on a schedule: the segment is assembled in advance, emails go to the entire database at the appointed hour, and the recipient's reaction to the next step has no effect.

An event-driven sequence is structured differently — it is launched by a client action: a submitted form, an opened proposal, a requested invoice.

The whole difference in approaches is who sets the pace: with a scheduled campaign, the marketer; with an event-triggered launch, the client.

The second launch source is a change in the deal stage. The funnel logic describes the client's path as a sequence of stages, and the transition between them changes the state of the card.

In Bitrix24 email funnels, the sequence subscribes to a specific transition: the deal went to approval — an email with terms goes out; it was put on hold — a different one goes out. The email arrives when the client has an open question, not when the editor has a free window.

Hence the difference in predictability. Bulk sending gives blurred statistics: opens depend on the day of the week and the success of the subject, and inquiries are lost in the general flow.

An event-driven sequence is tied to a specific step, so you can see exactly where the client dropped off — after which email and with what delay.

Technically, the sequence is assembled from conditions, pauses, and branches: if the email was not opened within a day, a reminder goes out; if opened, the step is skipped.

Re-entry into the sequence is blocked so that when the stage rolls back, the client does not receive the same email twice. Short answer to the question: the marketer sets the schedule, the client sets the event — that is why an event-driven funnel gives predictable inquiries.

Technical doubts: domain, deliverability, segments

We check deliverability and data integrity before the first campaign: until the domain reputation is confirmed, emails go to spam, and the funnel loses contacts right at the entry point. Below are the questions most often asked by engineers and managers before launch.

Can emails be duplicated when a scenario is re-run?

Each time an email is queued, it is marked with a step and contact attribute, so a repeated rule launch or manual intervention does not create a second email.

If a failure occurs between sending and status recording, the scenario checks against the log and skips what has already been delivered.

What will happen to existing email templates?

We transfer templates together with the layout and substitution variables, then check that personalization fields are filled from the contact card, and that links and unsubscribe lead to working addresses.

How does the funnel behave if the mail gateway is unavailable?

The email remains in the queue and goes out according to the retry schedule, rather than being lost. The contact does not fall out of the funnel: the step is marked as incomplete, and after recovery the scenario continues from the same point.

How are settings checked before launch?

We go through a checklist: domain signatures, test sending, segment analysis, funnel exit conditions, error log. We review the first sends manually and adjust settings before the bulk campaign.

Let's discuss your task and come back with a plan

For email funnels in Bitrix24 to work not as a scheduled campaign but as a managed sequence, we need to see your data and rules. Tell us where inquiries come from, which actions in CRM should switch the scenario step, and what counts as a signal to stop emails.

What we need from you to start:

• Data composition: which fields in inquiry and deal cards are actually filled, where required fields are empty, whether there are duplicate contacts.
• Access: a test portal or a separate funnel, an account with CRM marketing rights, access to segments, email templates, and reporting.
• Consents and unsubscribes: how you record consent to receive emails, how you handle opt-outs, whether you need correspondence history inside the card.
• Priorities by scenario: which sequences we launch first — welcome, warming, re-engagement of dormant contacts — and in what order.
• Channels: connected mail domain, sending volume limits, integration with website forms and telephony if an email must go out after a call.
• Readiness criteria: which metrics we consider the result — delivered rate, opens, transitions to the next funnel step, unsubscribes.

From this, the order of work takes shape: first we clean and tag the data, then we assemble triggers, then we test the sequence on a test segment, and only after that do we turn it on for the real flow.

Describe the task — what is already set up, which scenarios are needed, and which events should launch them. We will come back with a timeline estimate and an implementation plan that details step by step which scenario we put into operation and when.