Setting up customer base segmentation in Bitrix24

Bitrix24 segmentation: why mailings go to the wrong people

When the database in Bitrix24 grows beyond several thousand records, the first thing to break is not size but consistency.

Some fields were filled in manually from the record, some were pulled from forms and email, some remained empty after import — and in the "field of activity" field, "wholesale", "wholesale trade", and "WHOLESALE" sit side by side.

Any filter by such a field produces an incomplete selection: Bitrix24 segmentation stops describing real customers and starts describing how different managers named the same entities.

The second problem is duplicates in the database. One customer exists in several records: one came from the website, the second from correspondence, the third was created manually during a call.

Deals are scattered across them, the communication history is broken, and a mailing goes to the same person twice.

Next to that are contacts without an owner: they do not appear in manager reports, reminders and distribution rules do not trigger for them, and such records either do not enter targeted mailings at all or enter without accounting for who already manages the customer.

The third layer is how the selection is assembled. While there are two or three segments, they are assembled by hand: a filter by stage, by last deal date, by city, export to a file.

With a dozen regular sends, this turns into a separate job — the manager each time has to remember again which fields to exclude and whom not to bother again. An error in one filter sends a commercial proposal to those who have already bought or left after a conflict.

All this is fixed not by a mailing but by the database structure: unified field dictionaries, duplicate merge rules, a mandatory owner, and saved segments that recalculate themselves. Below we look at how this is handled on the CRM side.

What a managed database gives: effect in timelines and opt-outs

The effect of segmentation is measured not by interface convenience but by four numbers: how much time selection preparation takes, what share of recipients unsubscribes, how many spam complaints arrive after a mailing, and how many personal messages go to the wrong contact.

While selection rules live in a manager's head or in a separate file, these numbers change from month to month — and there is no way to explain them.

Then the effect holds only with a database workflow policy — without it, segments blur within a couple of months.

• a segment is described by a rule, not by a list of exceptions: a new contact enters the right slice on its own;
• consent to mailings and the reason for refusal are recorded in separate fields, not in a comment;
• before sending, the selection is checked for duplicates and segment intersections;
• each segment has its own contact rhythm and its own email scenario;
• on a schedule, the database is cleaned of inactive and undeliverable addresses.

Static lists, rules, and dynamic groups

The three approaches differ in the mechanics of population and the amount of manual work over the long run. A static mailing list is a manually fixed set of contacts: it is predictable but does not react to changes.

A customer selection rule builds a selection by deal and contact fields — stage, amount, source, region — and the composition depends on the data at the time of the request. Dynamic groups are the same rule but with regular recalculation and saved composition.

The key difference appears at the moment of recalculation. A rule selects by field state at launch time: a customer who paid yesterday will enter the selection only on the next run.

A static list does not update at all — without manual cleaning, the mailing goes to those who have already bought or unsubscribed.

Most often the combined scheme is optimal: a selection rule defines the base segment, and a static list adds what cannot be expressed through fields — personal agreements, manual exclusions, test addresses.

We separately record who owns the rule and how often the group is recalculated; otherwise segmentation diverges from the actual state of the database.

Bitrix24 segmentation: stages from audit to handover

Segmentation begins not with drawing funnels but with data inventory: until it is known what fields are filled with and where values come from, any scheme remains a guess. Below is the workflow we repeat on every project.

1. Audit of CRM fields and sources. We export the structure of deals, contacts, companies, and smart processes, calculate field fill rates, and find dictionary duplicates and manually entered values. We record intake channels: forms, email, telephony, exchange with 1C.
2. Agreement on segment attributes. We describe each segment through fields: funnel stage, industry, purchase history, activity over a period. The condition must be unambiguous — otherwise the rule can neither be checked nor handed over to another person.
3. Scheme design. We draw a map before setup: which segments are static, which are recalculated, how they relate to funnels and access rights. We check that a customer does not enter two mutually exclusive lists.
4. Assembly on a test environment. We assemble rules and automation on a copy of the portal with a copy of the database. This way conflicts with already running scenarios surface before they affect live deals.
5. Testing on real data. We run segments against historical deals and compare actual membership with expected. Discrepancies are most often caused by empty fields and different spellings of the same value.
6. Handover of settings. We transfer to the production portal in parts, monitor recalculation time, and describe the scheme and conditions inside records. We show employees how to add an attribute without breaking the logic.

The set of documents and settings that remains with you

Configured segmentation without documentation lives only until the first change of owner: fields become overgrown with duplicates, no one dares change group conditions, and mailings go to the wrong audience.

Therefore we record the result of the work as a set of artifacts that remains in your environment and does not require us for everyday edits. We write documents for specific roles and access rights — such a set is actually used, not stored in a folder.

• Field schema — which customer attributes are stored in the record, their types and whether each is required, and value normalization rules.
• Source and integration map — websites, forms, telephony, accounting system: what is transferred and how often, and where to look for exchange errors.
• Ready segmentation groups — static and dynamic segments with conditions, priorities, and exclusions, including recalculation rules when data changes.
• Mailing policy — for which segments and at what frequency contact is allowed, how unsubscribes and complaints are handled, and who approves new communication.
• Marketing instructions — how to assemble a selection, check its size, and export a list without contacting a developer.
• Support staff instructions — where in the record a customer's segment membership is visible and what to clarify upon request.
• CRM documentation — roles and access rights, data quality control points, the procedure for editing fields, and rollback of unsuccessful changes.

Case study: how database work was rebuilt on the portal

The customer had maintained the Bitrix24 portal for several years: the database had grown to tens of thousands of contacts, but they had stopped trusting it.

One customer accounted for 2-3 records with different spellings of the name, the source of inquiry and industry were filled for less than a third of records, and some deals hung without an owner.

Managers spent several hours a week on manual reconciliation before assembling a selection for a mailing.

Metrics before and after

What was reworked in rules and fields

We changed not the reports but the rules of data entry: the "phone + email" combination was made a deduplication key, and matching records are merged by a robot, not a person.

The fields "source", "industry", and "decision-making stage" became mandatory at the qualification stage — without them, a deal does not move further down the funnel.

The segment structure was assembled into two groups: static lists for specific campaigns and dynamic ones by activity and recency of the last contact. Dynamic ones recalculate themselves, so the "cooled-down" part of the database no longer mixes with the active one.

In mailings to the active segment, the opt-out rate fell by half, and the response rate grew about threefold.

What to do if the database has already grown and mailings are mixed?

Yes, an overgrown database can be sorted out without stopping mailings — if you clean it in layers rather than in one pass. Current communications continue to go through old lists until new segments confirm comparable deliverability on a control sample.

Mixing begins where one contact sits in three lists with different consent status and different contact history.

The work runs on a copy: we take a slice of historical CRM data in Bitrix24 — deals, activities, sources, last contact date — and distribute it into segments without affecting live mailings.

We use verifiable attributes: entry source, activity recency, deal stage, confirmed consent. A contact enters exactly one group — this removes the mixing.

Step-by-step cleaning: first normalization and deduplication — phones, addresses, spelling variants of company names. Then unsubscribed and inactive contacts, to whom sending is not allowed, go to the archive. After that, the active core is divided by engagement.

Each layer is checked on a control sample before the next — an error does not spread across the entire database.

List migration preserves the link to source records, so the history of opens, clicks, and deals remains workable — accumulated statistics are not reset. We switch mailings to new segments one by one: the old version lives until the new one shows the same or better deliverability.

Mixed lists go to the archive rather than being deleted — this is a rollback point. After that, segments are maintained by rules: a new touch automatically moves the contact into the right group, and the database does not become overgrown again.

Technical doubts before work starts

Before the start, the customer's technical team usually raises the same set of questions: data safety during edits, access rights in CRM, external sources, and control of selection rules.

The answers determine whether segmentation remains a reproducible setup or becomes a one-time action that no one dares touch.

How are access rights in CRM delimited?

We grant access by roles and work groups: a manager sees their own deals, a department head sees their segment, administrators see rule setup. Rights to export and mass actions are recorded separately so that new reports do not open access to the entire database.

How are external data sources connected?

We match records by stable keys — phone, email, company details — and clean duplicates before loading, not after. Exchange runs on a schedule with a log of accepted and rejected records; if a source is unavailable, segments continue to work on the last correct slice.

Who controls the quality of selection rules?

Before launch, we compare segment counters with the customer's reference sample and analyze discrepancies by condition. After that, a review policy applies: the trigger log shows which conditions have stopped being filled — the rule is corrected before the segment becomes empty.

What is needed from your side to start?

A separate account with setup rights, a contact for the accounting system, a description of the current funnel logic, and a list of approvers. We make edits in an agreed window when active mailings are not running.

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

For the conversation to be substantive rather than general, we need input data on your database.

Bitrix24 segmentation is built on what already exists in the portal, so the initial picture is more important than any wishes: the more accurate the description of the database and processes, the more realistic the estimate of the scope of work and the fewer reworks during setup.

To start, it is enough to list:

• how many contacts are in the database and how they are distributed by source — website, forms, telephony, offline points;
• which lead and deal fields are currently filled in, and which remain empty and why;
• by what attributes you already divide customers manually — region, industry, deal amount, funnel stage;
• which rules, robots, and auto-tasks operate in the portal, so that the new logic does not conflict with them;
• access: Bitrix24 portal, administrator rights or a test environment, anonymized export of the field structure;
• who on the business side confirms segment priorities and the criteria for changing them.

Then the procedure is simple. We look at the database and funnels, count the number of rules, fields, and exclusions, and provide a CRM work plan with stages, timelines, and areas of responsibility.

We agree on segment priority separately — usually we start with those that affect stage conversion fastest.

If you are ready to discuss the task, describe the inputs in free form or send the field structure as an export. We will come back with an estimate of the scope of work and a plan, and after approval the project start takes days, not weeks.