Designing Company Cards in Bitrix24 CRM

Designing Company Cards in Bitrix24 CRM

In B2B sales, the company card is a "client dossier" that lives for years. Deals come and go, managers change, but the company remains in the database. If the card is poorly designed, when a manager leaves, the new employee won't be able to reconstruct the context: who made the decisions, at what pricing terms they worked, why the last deal fell through. All of that is either in the company card or nowhere.

Structure of the "Company" Entity in Bitrix24

A company (crm_company, table b_crm_company) is a legal entity or organization. Unlike a contact, a company doesn't conduct correspondence or take calls — it serves as the context for contacts and deals.

Standard fields: TITLE (name), COMPANY_TYPE (type: client, partner, competitor, etc.), INDUSTRY (industry), EMPLOYEES (number of employees), REVENUE (annual revenue), PHONE, EMAIL, WEB, ADDRESS. These are fields in the b_crm_company table.

Custom fields are stored in b_uts_crm_company. Added via crm.company.userfield.add.

Relations: a company is linked to contacts via b_crm_contact_company, and to deals directly through the deal's COMPANY_ID field. An important point: a company can have hundreds of linked contacts and dozens of deals — the card must provide navigation through these relationships, not just static fields.

What Is Actually Needed in a Company Card

Legal and registration data. Tax ID, registration number, bank account, bank — in B2B, these are indispensable. They should not be duplicated in every deal. The correct architecture: registration details live in the company card; deals reference them.

Segmentation and classification. Company type (direct client / dealer / distributor / partner), size (small / medium / large), strategic status (key account / standard / one-time). These are not cosmetic — they are the basis for segmentation in mailings, service prioritization, and manager assignment.

Relationship history. Date of first deal, total deal value over all time, last contact — some of this data can be obtained through automation: a robot updates the "Total Deals Amount" custom field when each deal is closed.

Decision-making structure. Key contacts by role — these are not company card fields, but linked contacts. However, the company card must surface this structure: who is the decision-maker, who is the procurement specialist, who is the technical contact.

Company Types and Differing Cards

Bitrix24 does not have a built-in mechanism for "different card templates for different company types" — this is a platform limitation. The workaround: show/hide sections through role-based configuration or use smart processes for atypical counterparty types.

For large implementations with fundamentally different company types (e.g., private clients and government entities with a tender process) — it is sometimes better to design a separate smart process for one of the types, rather than trying to fit everything into the standard company card.

Case Study: Company Card for an IT Integrator

Client — a systems integrator, 200 client companies in the CRM. Deals: one-time projects, service contracts, SLA support. Each company has multiple contacts at different levels and several concurrent deals.

Problems with the original card:

• The "Client Type" field was a string, filled in as "product," "project," "service," "support" — no consistent classifier.
• TIN and registration details were manually duplicated in every deal.
• No data on the client's technical environment (which software they use, what infrastructure they have).

Redesigned card:

"Main" section: name, TIN (string with length validation), registration number, legal address, website, number of employees (range list: up to 50 / 50–200 / 200–1000 / 1000+).

"Segmentation" section: client type (list: one-time project / service contract / SLA / partner), industry (list), strategic level (list: key / standard / potential).

"Technical Environment" section: primary ERP (list: 1C / SAP / other), products in use (multiselect from product catalog), software version (string), date of last audit (date).

"History" section: date of first contract (date), total realized project value (number, updated by robot), NPS score (number, updated manually quarterly).

Registration details were moved to a separate block, and auto-population from the company card into new deals was configured via robots — managers stopped manually entering the TIN in every deal.

Timeline

Designing and implementing a company card takes 2–5 business days. When working on all CRM entities simultaneously (company, contact, deal) — the timeline is 10–16 days, including interviews with key users and approval iterations.