Designing Sales Funnels in Bitrix24 CRM

Designing Sales Funnels in Bitrix24 CRM

A default-configured funnel is almost always a funnel with problems. Stages are named "New," "In Progress," "Closed Successfully" — managers can't tell the difference between "In Progress" and "Negotiations," and the manager can't get an answer from the CRM to the question "where is the money stuck." Designing a funnel isn't about creating nice stage names. It's about modeling the decision-making process in sales and embedding that model in the interface.

Funnel Architecture in Bitrix24

In Bitrix24, funnels are implemented through STAGE_SEMANTIC_ID — the semantic value of a stage: P (in progress), S (success), F (fail). Each stage belongs to one of three categories. Stages are stored in the b_crm_status table and linked to an entity type through ENTITY_ID (e.g., DEAL_STAGE for deals, STATUS for leads).

In a multi-funnel model (available in Bitrix24 versions that support pipelines), each pipeline (crm_category) has its own set of stages. Technically this is implemented through separate ENTITY_ID values in the form DEAL_STAGE_1, DEAL_STAGE_2, etc., where the number is the pipeline ID.

Why a Funnel Needs to Be Designed, Not Just Created

A funnel is an operational instruction for a manager, expressed in stages. If a stage doesn't answer the question "what must happen for a deal to move here?" — it's not a stage, it's just a label. A good funnel is built around measurable transition criteria.

Additionally, funnel stages directly affect:

• Triggers and automation — actions execute when entering or leaving a stage.
• Business processes — launched on stage change.
• Reports and analytics — conversion between stages is calculated based on the funnel model.
• Access permissions — you can restrict who is allowed to move a deal to a specific stage.

If a funnel was "sketched quickly" and then reworked, all accumulated conversion data is reset. This is painful for a sales team that has been working with the CRM for a month.

The Design Process

Interview with the sales team. Start with a conversation with the head of sales and 2–3 managers. The goal is to reconstruct the real sales process: from first contact to payment and repeat purchase. Key things to document: where the decision to continue working on a deal is made, who makes that decision, and what constitutes evidence of progression to the next step.

Defining deal types. If the company sells different products or works with different customer segments — the funnels will be different. Selling a support service and a one-time supply are different funnels, even within the same CRM.

Stage map. For each stage, document:

• Name and meaning (what does it mean to "be in this stage")
• Entry criterion (what must happen)
• Responsible party (or role)
• Maximum time in the stage before escalation
• Possible transitions (which next stages can be moved to)

Failure stages. A separate matter — the "lost" stages. These need to be designed as a classifier of loss reasons: "Lost — no budget," "Lost — went to a competitor," "Lost — not our target customer." This isn't cosmetic — it's data for loss analysis.

Case Study: Funnel for B2B Software Sales

Client — a software distributor, 12 managers. Initial funnel: 5 stages, identical for all deal types. Problem: deals for "direct sales" and "tender procurement" have fundamentally different timescales and processes but were mixed in a single funnel. Forecasting revenue was impossible.

Solution: designed three funnels.

Funnel 1 — Direct Sales (7 stages, 14–30 day cycle): Lead qualified → Needs identified → Proposal sent → Proposal approved → Invoice issued → Payment received → License delivered

Funnel 2 — Tender Procurement (9 stages, 30–120 day cycle): Tender identified → Decision to participate → Documentation prepared → Bid submitted → Awaiting results → Won → Contract signed → Delivery → Closed

Funnel 3 — License Renewals (4 stages, up to 30 day cycle): Notification sent → In progress → Invoice issued → Renewed

Each funnel was assigned separate automations: reminders, notifications to the manager when a stage time limit is exceeded, automatic task creation upon transition to the "Invoice Issued" stage.

Two months after implementation, the client received their first revenue forecasts with ±15% accuracy — compared to the previous "roughly the same as last month."

Stage Automation

Automation in Bitrix24 is configured through robots (b_crm_automation_trigger, b_crm_automation_action) — a simplified version of business processes. Each robot is tied to a specific stage of a specific funnel. When designing, document: which robots run on stage entry, which run after a delay, and which run on exit.

Timeline

Designing a single funnel (up to 10 stages) with configuration in Bitrix24 takes 3–5 days. A multi-funnel model for several deal types takes 8–15 days, including interviews, approvals, implementation, and team training.