Designing deal cards in Bitrix24 CRM

Designing deal cards in Bitrix24: where the funnel breaks

A deal card is not a form to fill out but a contract between funnel stages: what must be known about the client by the time the deal is handed to the next department.

When required deal fields are designed "from memory," the card lives by different rules for different managers: some deals move forward with empty key attributes, and the conversion report describes not reality but the habits of specific employees.

The most expensive loss of leads in the funnel is the one where the lead is not formally lost. The deal remains in the database, but the source of the inquiry is not filled in, so it is invisible both in the channel breakdown and in the forecast.

It is similar with duplicates: a client returns, the manager creates a second deal or a new contact — and the history of interactions splits across two records, each of which looks incomplete.

Manual transfer of data between stages is the second breaking point. The assignee copies the contract number, attachments from correspondence, and task decisions further along the funnel because the card does not transfer them itself.

Each copying is a delay in response and another chance to omit something: part of the history settles in comments and chats that the next participant will no longer reach.

All of this is fixed not by motivation or regulations but by designing deal cards: required deal fields with filling rules and validation at transition, automatic transfer of data between stages, duplicate detection before record creation, and end-to-end interaction history in one card. We explain how this is structured.

What changes after reworking sales logic

The effect of reworking cards is visible in metrics taken on the same sample of deals before the changes and one month after working with the new logic. Below is what we check together with the client on a live funnel in Bitrix24.

• Reduction in lead processing time. The card is filled out in 2–3 minutes instead of ten: some fields come from the form, the rest are selected from a reference list. The manager focuses on the client rather than switching between windows and searching for data.
• Share of missed required fields. Validation at the transition between stages does not let a deal through without key data — omissions drop from half of the cards to isolated cases, and reporting stops being based on guesses.
• Transparency of funnel stages. Each stage has one definition and one set of required fields, so the manager sees the real picture: where deals stand, where they get stuck, and at which step they are lost.
• Eliminated error classes. Duplicate cards for one client, broken links between the deal and the contact and company, discrepancies with the accounting system during transfers. These errors did not "become rarer" — there is no longer anywhere to make them.
• Unified qualification rules. The criteria for moving a deal are fixed in fields and validations, not in verbal agreements, so two managers with the same inputs make the same decision.
• Speed of recovery after a failure. The history of changes by fields and stages allows the card to be restored to its previous state in a targeted way, without sorting through exports and manually restoring links.

We take metrics before and after over identical periods; otherwise, the comparison proves nothing.

Comparison of approaches to card configuration

The choice of approach is determined by how much logic lives inside the card and how often it will need to be changed. The built-in tools of Bitrix24 cover typical scenarios but hit a ceiling when rules begin to depend on each other.

The practical criterion is simple: if a rule can be expressed as a native condition and does not require external data, we keep it in the card. Anything that depends on calculation, adjacent systems, or change history is moved outside and returned as a result.

This separation removes the main design risk — logic smeared across settings breaks at the first change in the process.

Implementation stages: from audit to handover of regulations

A deal card is not a form but a data model: fields, links to the contact, company, and invoice, stages, role permissions, and robots that react to all of it.

If you start by redrawing the interface, a month later it turns out that some fields are duplicated, interaction history is not pulled in, and automation triggers at the wrong stage.

Therefore, the order of work is fixed: first analysis of data and schema, then configuration, then testing on real sales scenarios.

1. CRM audit before improvement. We export the current entities, fields, stages, permissions, and robots, mark duplicates and unused fields, and look at where managers bypass the system manually.
2. Field and relationship schema. A map: which fields are required, which are calculated automatically, and how the deal is linked to the contact, company, invoice, task, and inquiry from a communication channel.
3. Configuration of stages, rules, and roles. We assemble funnels, triggers, and permission restrictions by department so that the card shows the manager exactly what is needed at the current step.
4. Testing sales scenarios. We run typical and edge-case paths — returning to a previous stage, a repeat inquiry, a deal without a company — on a test environment with a copy of the data.
5. Migration of interaction history. We load accumulated deals and correspondence while preserving dates, authorship, and links, and reconcile the number of records before and after.
6. Pilot on one department. We enable the new schema for a limited group, and look at the filling speed and the share of cards without required fields.
7. Handover of regulations. We provide the data schema, role descriptions, instructions, and support rules — so that future changes can be made without us.

Data schemas, access policies, and work regulations

Deal card design is completed not with field configuration but with a set of artifacts. The support team uses them to develop the system, and the sales department works without verbal agreements about who fills in what.

• CRM entity schema: deals, companies, contacts, line items, and additional entities — field types, links, and rules for transferring values between stages.
• Role permission matrix: who reads, who edits, who sees only their own records — down to an individual field; verified with test accounts before launch.
• Field completion regulations: required fields for each stage, conditions for moving further, and the procedure when data is insufficient.
• Automation rules: robots, triggers, and business processes with trigger conditions, task creation, responsible person changes, and error handling.
• Sales department instructions: a step-by-step scenario for working with the card — what to fill in during a call, before a proposal, and when closing a deal.
• Procedure for making changes: how a request for a new field or stage is created, who approves it, and how the change is tested and rolled back.
• Migration map: mapping of fields from the previous system to the new schema and a discrepancy log for manual review.

The set is handed over both as documentation and as working settings — it is enough for a new administrator to bring the system into operation without the schema author.

Case study: a unified data model for three sales lines

The client had three sales lines working in one Bitrix24 funnel, and each department customized the deal card for itself.

Required fields did not match, managers duplicated some details in comments, and a returning client was created as a second card — a typical CRM implementation case where the problem is not in the settings but in the absence of a common data model.

What it was like before

Leads were lost at the junction between departments: a deal moved to the next stage, but the responsible person did not change — the loss share reached one-fifth of new inquiries. Duplicates accounted for about one-third of deals, and client history was not collected.

The average time to pass a stage was measured in days and was calculated by its own statuses in each department, so the lines could not be compared. Support received dozens of questions per week just about how to fill out the card correctly.

What was changed

We designed a unified model: a common field reference with requiredness tied to the stage, a rule for changing the responsible person when moving between lines, and contact verification by phone number and email before creating a new deal. The lines were separated into individual funnels with shared analytics.

After launch, the share of lost leads fell from 18% to 2%, duplicates from 30% to 3%, the average time to pass a stage was halved, and the number of support requests about filling out the card dropped by a factor of three. For the first time, reporting across the three lines was collected from a single source.

What to do if the system is already deployed and there are too many fields

An overloaded field structure almost never requires stopping the sales department. Requiredness, order, and visibility of fields, tooltips, and new reference values are changed directly in the production environment — within minutes, without exports or pauses in negotiations.

Only operations on things that deal history already references are dangerous: deleting a field, renaming or deleting a stage, changing the funnel.

The reason is simple: the card is not an isolated form but a hub of relationships. Reports, automations, role permissions, and exchange with the accounting system rely on field values.

Therefore, an obsolete field cannot be disabled with a single action — first you need to see who and what reads from it. An inventory based on actual usage takes a couple of days and removes most of the risks.

Next, a phased CRM rework works, where each step is reversible:

Between steps, we keep a pause — a week of observing access to the field and exchange errors. This order allows deals to be closed at each stage: only what has already been taken out of use and will not appear in reporting becomes unavailable.

Technical concerns: limitations, migrations, integrations

A deal card is not a separate form but an extension over the native CRM object: fields, stages, permissions, and automation rules live in the same entity as the standard ones. That is why engineers' objections repeat — let us address the four most common ones.

What will happen to the exchange if the accounting system is replaced?

The exchange is built on persistent identifiers: the deal, counterparty, and line items are linked by an external key, not by name.

When the accounting system changes, matching is done by these keys — duplicates and unpaired records do not appear, and migrating the exchange comes down to configuring a new source.

Will deal history be preserved?

Closed deals remain with their stages, responsible persons, and correspondence; new fields are filled in as the deal progresses. Value changes are written to a log — you can see who entered them and when, which closes audit questions when the team changes.

What is included in support after handover?

The change regulation, field schema, and access roles. Changes to stages and automation rules go through an agreed procedure and test environment — the card does not "sprawl" six months after launch.

Let's discuss the task — we'll come back with an estimate and plan

To design deal cards for your process rather than an average template, we need a short review of the current state. It is enough to send what you already have — we will clarify the missing parts on a call.

• Composition of roles and lines: who works in the CRM — sales, service, procurement, management — and which areas of responsibility are assigned to whom.
• Current field structure: required and optional fields, duplicates, the format for maintaining reference lists and counterparties.
• Deal stages: funnel stages, what is considered the result of a stage, and where mandatory validations are needed before moving further.
• Existing integrations: 1C, telephony, email, website, external services — what is synchronized and by what attribute records are matched.
• Reporting requirements: which slices management needs, with what frequency, and in which dimensions — line, employee, period.
• Access separation: who can see which fields and sections, and whether an action log for the card is needed.

Next, we discuss the automation task, reconcile the list, and come back with an estimate and work plan: field schema, data migration order, implementation stages, and control points.

You see the scope and sequence before the start — changes at this stage cost less than reworking the funnel after launch.