Designing Deal Cards in Bitrix24 CRM
Designing Deal Cards in Bitrix24 CRM
The deal card is the central object a sales manager works with. This is where most working time is spent: reviewing history, recording agreements, managing the amount, generating an invoice. When the card is poorly designed, managers start keeping a parallel record in Excel — "it's more convenient there." That's not a manager problem — it's a design problem.
Structure of the Deal Card in Bitrix24
The deal card (crm_deal, table b_crm_deal) has several zones:
Header — deal name, amount, stage, responsible person, close date. These fields are always visible without scrolling — the most important ones.
Main field block — configured through "Card Settings." Can be split into tabs or sections. Composition depends on the pipeline: deals in different pipelines (crm_category) can have different card configurations.
"Products" block — catalog of products/services linked to the deal. Data is stored in b_crm_deal_product_row. If the catalog is not used — the block can be hidden.
Activity feed — calls, emails, meetings, tasks, comments. Chronological history of interactions.
Relations — contacts and companies linked to the deal. Configured via crm.deal.contact.add / crm.deal.contact.items.set.
Designing for the Sales Process
The key principle: the deal card must reflect the specific stage the deal is at. In Bitrix24, this is implemented through field display configuration based on stage — the "required fields by stage" functionality (crm.stageField).
A typical mistake: all 30 fields are displayed on every stage. A manager on the "First Contact" stage sees fields like "Contract Signed," "Invoice Details," "Purchase Order Number" — and has no idea what to do with them. A well-designed card shows the right thing at the right time.
What we design:
-
Required fields by stage. At the "Proposal Sent" stage — "Proposal Validity Date" and "Proposal Contact Person" must be filled in. At the "Invoice Issued" stage — billing details and amount. This is done through the required field settings in the card for a specific stage.
-
Field grouping by meaning. Card sections: "About the Deal," "About the Client," "Finances," "Documents." Managers know which section to look in for the field they need.
-
Custom fields of the correct type. Bitrix24 supports types: string, number, list, date, boolean, CRM element reference, file, money, address. Choosing the wrong type — e.g., "string" instead of "list" for client type — kills analytics.
-
Calculated fields. Bitrix24 has no native computed field mechanism out of the box, but automation robots can update fields when other fields change. For example, automatically calculating the margin when the purchase amount changes.
Case Study: Deal Card for a Construction Company
Client — a general contractor in civil construction. Deals: turnkey construction projects, average ticket 5–50 million rubles, cycle 3–18 months.
Original card: standard, extended with 18 custom fields in chaotic order — "Facility Area," "Foundation Type," "Number of Floors," "Client TIN," "Land Cadastral Number," "Building Permit Status," etc. All in a single block, no grouping.
Redesigned card structure:
"Facility" section: facility address (type "Address"), area (number), number of floors (number), construction type (list: new construction / renovation / major overhaul).
"Client" section: TIN (string with mask), client status (list: individual / legal entity / government contract), availability of design documentation (boolean).
"Legal Documents" section (appears only starting from the "Contract" stage): contract number, contract date, cadastral number, building permit status (list).
"Finances" section: client budget, our proposed price, final contract amount, payment form (list), payment schedule (file).
Fields in the "Legal Documents" section are mandatory at the "Contract Signed" stage — it's impossible to move to the next stage without filling them in.
Additionally configured: when transitioning to the "Facility Handed Over" stage — automatic creation of a "Request client feedback" task with a deadline of +7 days.
Result: manager card fill time was reduced, fields "not relevant to this stage" stopped cluttering the view, and the director got a working facilities status report.
Pitfalls
Too many tabs. If the card is split into 6+ tabs, managers stop going past the first one. Optimal: 3–4 sections or tabs.
Duplicating fields from contact in the deal. TIN, address, phone — these are company/contact data, not deal data. Placing them in the deal card leads to data discrepancies when the contact is updated.
"Comment" field instead of a classifier. "Why did the deal fail?" — a text field gives an answer that can't be aggregated. A list of loss reasons is needed.
Timeline
Designing and implementing a deal card takes 3–6 days for a single pipeline. For multiple pipelines with different card configurations — 8–15 days.