Why the Bitrix24 contact card loses data and leads
Duplicate contacts appear not because of operator error, but because of record matching logic.
While the Bitrix24 contact card looks for a match only by phone or email, any request without this data — an email from a form, a call from a hidden number — creates a new record instead of appending to the existing one. The more channels connected, the faster the number of such records grows.
Communication history falls apart: some emails are in one card, calls in another, deals are linked to different records. A manager opens the contact and sees half the correspondence, while the client receives two calls from different people about the same issue. Source reporting also diverges from reality: the same deal is counted twice.
The second point of loss is empty contact fields. A form or integration fills in name and phone, while source, direction, and responsible person remain empty.
The distribution robot relies on them: the request does not enter any queue and hangs in Unassigned — without an owner and without a task in the calendar.
The most expensive losses come from fragmented data: the client waits for a response while the request sits without a responsible person, and contact duplicates accumulate with every new touch.
Lost requests surface already at the client return stage, when the context has to be restored manually. Next, we break down how this is closed — at the level of matching rules, required fields, and queue control.
Effect of reworking the card: speed and data quality
Reworking the contact card in Bitrix24 is not cosmetic, but a change in the data handling scheme: required fields are moved to the top, the contact is linked to the company and deal, and some attributes are pulled from email and telephony. Below is what exactly changes in the metrics that show the result.
Request processing speed
The manager sees correspondence, calls, tasks, and documents on one screen — the context does not have to be assembled manually across sections. A repeat request is identified by phone or address, so the conversation continues from where it left off instead of starting over.
In practice, request processing time is reduced by about a quarter, and deal time by 15–30% with the same headcount.
Data completeness and accounting quality
Required fields with input format validation and prompts eliminate retroactive manual entry — the main cause of empty reports.
The share of completed fields for key attributes (source, industry, status, responsible person) reaches 90% and above, while duplicates are collapsed during card merging. Accounting quality becomes sufficient for planning by segments, rather than for an approximate picture.
Standard form, customization, or a separate entity: what to choose
The contact card grows together with the process: at first custom fields are enough, then linked records, role-based rights, and logic that cannot be expressed by settings appear.
There are three levels of solution, and the choice should be based on the load on the process, not on habit.
| Option | When it fits | Limitations |
|---|---|---|
| Standard card and custom fields | One work scenario, up to two or three dozen fields, simple filtering | No custom stages or calculation logic, only standard links, the interface gets cluttered with fields |
| Customization of the standard card | Field display rules, custom print forms, automation are needed | Logic lives in an add-on: after a platform update, compatibility checks are required |
| Separate entity with its own card | Many linked records, its own pipeline, roles, and contact reporting | Takes longer to implement, requires data migration and employee training |
When standard settings are enough
If a contact is created once and used as a reference record, the standard card is enough: add custom fields, configure required status and rights, and connect standard links to the company and deal. Setup takes days, creates no support debt, and survives updates without intervention.
When configuration limitations become a bottleneck
When one contact has dozens of linked records, separate numbering or record-level access is needed, standard mechanisms stop supporting the logic.
Then we design a separate entity with its own fields, stages, and links, and migrate data in stages so that the department's work is not interrupted.
Work order: from field audit to handing over regulations
We keep the work order fixed: each contact card follows the same route, so the result is reproducible and does not depend on which engineer handles the task. Below are the stages as they proceed on Bitrix24 projects.
-
Field audit. We export the current set of contact fields and related entities, mark which ones are filled in in practice, which duplicate each other, and which remain from past customizations.
Separately, we record where data is entered manually and where it is pulled automatically — discrepancies here usually create garbage in the database.
-
Data schema. We agree on the target structure: required fields, fields in the card header, fields in tabs, links to the company and deals. For each field, we define the required rule at a specific stage — a contact without a phone and communication channel does not move further.
-
Rights setup. We lay out roles and access levels by department and stage: who sees the card, who edits, who only reads, who can access service fields. Separately, we lock down export and deletion — this is the most common source of incidents.
-
Card setup. We assemble the layout of blocks, configure autofill from calls, emails, and website forms, and bind handlers to robots and rules. We check that a repeat request creates an activity, not a second duplicate contact.
-
Scenario testing. We run typical paths on a test environment: a website request, an incoming call, a repeat client, contact transfer between departments. We check that required fields and rights trigger at every step, not only at the first one.
-
Training and handover of regulations. We provide filling regulations with right/wrong examples, a short instruction for new employees, and a field map. We hold a session with the department — reviewing real cards, not abstract rules.
-
Support. For the first weeks after launch, we monitor how fields are filled in and make targeted adjustments to required status and rights until the schema reaches stable metrics.
Handover package: settings, schemas, access rules, regulations
We hand over not "completed work," but a working system: after delivery, all settings remain in your account and do not require our involvement.
The package is assembled so that a new administrator can understand it without back-and-forth — the configuration shows what is configured, and the documentation shows why it is done that way.
Configuration: what is configured in the system
- Contact card settings — composition and order of fields, required fields, automatic substitutions, duplicate search rules.
- Link schema — contact → company → deal → task, with a note on where the link is required and where it is filled manually.
- Access rules — roles, read and edit rights, restrictions by directions and pipelines, who can see other people's records.
- Automation — robots and triggers with a list of trigger conditions and binding to stages and fields.
- Custom fields and dictionaries — types, values, sources of filling.
Documentation: how to use it
- Employee instruction — one to two screens: how to create a contact, what must be filled in, what to do with a duplicate.
- Work regulations — who creates and updates records and when, response times, procedure for periodic database cleanup.
- Change map — what was changed in the card and why, so that the next edit does not break the previous one.
- Rollback procedure — where the original settings are stored and how to return the previous state.
Documentation is updated together with the settings: editing a card without a record in the regulations turns into the next breakdown a few months later.
Case study: how the sales department stopped losing requests after restructuring
The client is a sales department of 12 people with two channels: email and calls, while website requests fell into a common folder.
After a few months, it turned out that some requests did not reach a deal not because of demand, but because of accounting: the contact was created manually and not always. We break down what was changed in the Bitrix24 contact card and how it affected the numbers.
What diverged in accounting
Previously, the contact card lived separately from the deal: phone and email were often left in a comment, the source of the request was not filled in, and duplicates appeared when a repeat email came from another channel.
The manager saw 60 deals per month with 80 actual requests — the rest dissolved in correspondence. Preparing for a call took up to five minutes: the manager assembled the history from email, tasks, and memory.
What changed in the department's work
We rebuilt the card: required fields for phone, email, and source, automatic linking to the deal and company, and duplicate merging by number and address. Correspondence and calls are collected in one feed, and changing the deal stage records the responsible person and date.
Lost requests disappeared as a category: every email or call creates a record that cannot be closed without a result note.
The manager sees 80 requests and their fate instead of 60 deals, the share of contacts with a specified source grew to 98%, and duplicates were reduced sixfold. Preparing for a conversation takes less than a minute — the history comes up directly in the card.
What to do if your CRM already has its own fields and rights
The card is not rebuilt from scratch — it is extended on top of the current configuration. First, inventory: which custom fields are already filled in, who sees them and with what rights, what is linked to the contact — deals, companies, forms, exchanges, reports.
A settings conflict almost always surfaces here: a field is tied to a deal pipeline, and you are going to restrict access to it.
We migrate data without deleting or renaming existing fields — their symbolic codes participate in exports and exchanges, and changing a code breaks the history. We add new fields alongside, and after reconciliation we move old ones to read-only mode.
Before that, we count completeness: how many records contain a value, whether data in related entities matches, what is visible in the change history — otherwise migration quietly loses some contacts.
We rebuild access rights from the target role matrix, not "as is." Restriction down to individual fields is a common cause of broken scenarios: one department loses visibility, while an exchange loses access to the parent company.
Therefore, we first describe the "role — entity — field" matrix, then compare the card behavior for specific employees before and after.
Gradual implementation removes the main risk: we enable it on one department, look at the log and automation errors, and check whether tasks and records have doubled. We keep rollback ready — a configuration snapshot before edits and a plan to return to the previous logic.
As a result, the contact card in Bitrix24 works on top of previous settings, and accumulated data remains in place.
Addressing technical doubts: data, access, timelines
Before designing a contact card in Bitrix24, the customer and their technical lead have the same questions: what will happen to the current database, who will see extra fields, how will this affect timelines, and will records multiply. Below are short answers for each point.
What will happen to the current data?
Before edits, we take a full database copy and export contacts together with related deals to a separate file. Fields are only added and migrated; we do not delete anything — if migration fails, the card returns to its original state from the copy.
How can access to contact fields be restricted?
We separate rights at the level of roles and custom fields: a manager sees contact data and request history, a supervisor also sees service fields, and integration keys remain only with the administrator. We grant access selectively, not to the entire department.
Will duplicate records appear?
We set a matching rule by normalized phone and email address: a match means appending to an existing contact, not a new record. Additionally, we configure a report that shows questionable pairs for manual merging.
How is the card linked to deals?
The link goes through binding the contact to the deal and company, so the card shows the entire history of work with the person. When the company changes, the history moves together with the contact — nothing needs to be transferred manually.
How will the work affect timelines and department workload?
We assemble and test changes on a portal copy, while the sales department works as usual. We switch during a window outside active hours: the card is updated, and old links and bookmarks continue to work.
Let's discuss the task and come back with an estimate and work plan
An initial scoping of a contact card task in Bitrix24 takes one conversation — full access and a detailed description are not needed at this stage.
It is more important to understand the scope and how the contact is linked to other entities: deals, companies, tasks, and exchange with the accounting system.
Below is a short list of what helps us come back with a task estimate and work plan, rather than with clarifying questions.
- Which card fields are needed in work and which of them are required: this affects both the input form and filling rules during import.
- Where contacts come from — manual entry, website, email, calls, export from the accounting system — and what to do when data diverges.
- How duplicates are currently searched for and what counts as a match: phone, email, company details.
- Who sees what in the card: roles, edit rights, hidden fields, change history.
- Which actions should be triggered from the contact: task, email, deal, notification to the responsible person.
- What is already configured in your portal and what cannot be broken in current processes.
Based on these answers, we assemble a work plan: the order of stages, the scope of changes, and a pilot area — for example, one department where the solution is tested on live data without stopping the others. Then we agree on the next step: you describe the task — we come back with an estimate and plan.