Bitrix24 sales funnel: where deals are lost
Deals in Bitrix24 almost never get lost in one place — they get stuck at stage boundaries and are duplicated on repeat inquiries.
A Bitrix24 sales funnel assembled “according to the department’s logic” usually reproduces familiar stages but does not describe exactly how one stage differs from another.
As a result, stalled deals look active, and deal loss is discovered during reconciliation with payments, when it is already difficult to bring the client back.
The first common cause is blurred boundaries between deal stages. If a transition is not tied to a verifiable event (proposal sent, approver contact received, document signed), the sales rep moves the card based on gut feeling.
The stage report stops reflecting reality: the forecast is inflated, and stalled deals accumulate those that have not moved for months.
The second is required fields at the wrong step. The requirement to fill in everything when creating a card forces either creating the deal later or putting in placeholders that no one cleans up afterward.
Sales funnel setup works when data is requested where it appears: source and contact — at the first touch, terms and deadlines — during approval.
The third is the absence of return rules. Without them, a deal after a client refusal remains in an advanced stage, a repeat inquiry is created as a second card, and some tasks are lost between duplicates.
We examine how this is closed by funnel setup: verifiable transition criteria, fields at their proper steps, and scenarios for returning a deal back.
What rebuilding delivers: effect in measurable metrics
Rebuilding the funnel in Bitrix24 changes not “interface convenience” but the time it takes a deal to go from first inquiry to invoice.
Previously, the sales rep moved the card manually, duplicated data into spreadsheets, and negotiated the discount in chat — hours were lost at each stage.
After transitions between stages, required fields, and owners were tied to rules, the card moves on its own, and the sales rep focuses on the client.
What sales automation delivers in measurable terms:
- Inquiry processing speed — a request from the website, email, and phone goes into a single card without manual entry, and the first response no longer depends on who is on duty.
- Conversion by stage — you can see at which step the most deals drop off; more often the bottleneck is approval or invoicing, not negotiations.
- Share of stalled deals — the rule “no activity longer than a set period → task and reminder” brings back into work what previously sat quietly in the database.
- Recovery time after a process failure — if the exchange with an external system fails, requests are not lost: the queue is replayed, and the owner receives a notification.
Sales department transparency is a consequence of the same: the head sees the funnel in real time rather than compiling a month-end report from someone else’s spreadsheet.
A whole class of failures disappears — forgotten deals, inquiries without an owner, stages that no one controls.
Funnel schemes: option, limitations, when it fits
The funnel scheme defines not only the deal card appearance but also transition rules, required fields at a stage, role rights, and robots that move the deal without the sales rep’s involvement.
That is why the scheme is chosen before filling the database: changing the option on live data nullifies stage comparability and breaks reporting for past periods.
Heterogeneity of deals is the main selection criterion. If there is one product and the cycle is the same for all clients, extra funnels only fragment analytics; if there are several lines of business, a common funnel averages timelines and conversion to meaningless values.
| Funnel scheme | When it fits | Limitations |
|---|---|---|
| One common funnel | One product, identical deal cycle, single sales department | Different segments get mixed: average timeline and conversion are calculated “on average,” and transition rules have to be made soft |
| Funnels by line of business, including for several products | Different products, cycles, and qualification scenarios | Requires synchronization of reference data and fields; comparison of lines is possible only through summary reports, not one diagram |
| Funnel with qualification and return stages | Long cycle, deals stall, some clients return after refusal | More stages means higher cost of error: without filling discipline and robot settings, the funnel becomes overgrown with “dead” deals |
We define transition rules explicitly: which fields are required at a stage, where skipping stages is prohibited, which task is set by a robot and after how many days the deal goes into return or refusal.
Such a framework makes the funnel both a working tool for the sales rep and a source of reliable data for forecasting.
Implementation stages: from audit to handover
The order of stages here is not a formality: each subsequent step relies on the result of the previous one, and a missed link returns the project to manual correction after the fact. Below is the sequence we follow when implementing a sales funnel in Bitrix24.
- Sales funnel audit. We export stages, fields, and deal history, count how many deals stall at each stage, and identify who last changed the card. The output is a problem map: duplicate fields, stages without transition rules, reports that no one reads.
- Stage design. We assemble a scheme for the real deal cycle: how many stages are needed, which fields are required at each, where automation performs the action, and where the decision remains with a person.
- Access rights setup. Roles for the tasks: the sales rep handles their own deals, the head sees the department, service fields are closed to edits. We separately restrict card deletion and backdated stage changes.
- Automation assembly. Robots, triggers, and tasks within stages: a reminder during inactivity, a task after approval, a notification to the owner when the stage changes.
- Testing on a test contour. We run scenarios on a copy of the portal: the deal passes through all stages, reports reconcile, and rights do not hinder work. We adjust the scheme before migration, not after.
- Training and regulations. We show the team the new logic using their own deals and provide short instructions: which field is filled in when and what to do with a non-standard deal.
- Handover to operation. We migrate the settings to the production portal, reconcile reports for the first weeks, and resolve disputed points based on actual deals.
Each stage is closed with an artifact — a scheme, an access matrix, or a regulation — so the result can be accepted in parts.
What the client receives after implementation
After implementation, the funnel logic no longer rests on the integrator’s memory — it is recorded in documents according to which the sales department works independently. Below is a list of what is handed over to the client at the end of the project.
- Sales funnel scheme — stages and transition conditions between them, required fields at each step, automation binding: auto-tasks, notifications, owner change during deal inactivity.
- Access rights matrix — which roles see, change, and delete deals, who exports the database and edits settings; separation is by department, not “for everyone at once.”
- Deal handling regulations — what the sales rep does at each stage, within what timeframe, and what data they must fill in before moving further.
- Instructions for sales reps — step-by-step scenarios by role: create a deal, move it by stage, return it from refusal, attach a document, hand the deal over to a colleague.
- Access policies and audit log — who and when changed funnel settings, history of field and status edits, procedure for scheduled reconciliations.
- System documentation — map of connections with 1C, telephony, and email, description of robots, rules for handling exchange errors.
Documents are written for your process, not for a template, and are tested on real deals before handover. When stages or owners change, we update the scheme and regulations — employees stay on the current version, not on verbal agreements.
Case study: rebuilt stages and removed stalled deals
A sales department with a distributed team: six sales reps in three cities, a shared flow of inquiries from the website, email, and messengers.
In Bitrix24, by the time of the review, the sales funnel consisted of 12 stages — sales reps skipped three of them, and five did not contain required fields.
A deal went to “Success” without a payment date and shipping decision, and in the head’s report such sales were listed as active for months.
What was changed in stages and rights
Stages were reduced to seven, each got a transition attribute and required fields: date of next touch, owner, source, amount.
Rights were rebuilt so that moving further without filling in fields is impossible, and only the head can return to the previous stage, and with a comment.
We added a contract approval stage with a checklist and a robot: five days without activity — a task for the sales rep, ten — escalation to the head.
Metrics before and after
The share of deals without movement decreased from 34% to 11% — now each one shows the stopping point and the person responsible for the next step. The average deal duration decreased from 47 to 29 days, and conversion from inquiry to invoice increased by almost a fifth.
The number of deals with no data in the report was reduced to zero. A stage stopped being a label and became a control point: stalled deals are visible on the second day, not at the end of the month, when the sales rep no longer remembers the context of the conversation.
What to do if deals are already managed by their own rules
Yes, the transition is done on a working system, without stopping the department.
The procedure is as follows: first, additional funnels are built in Bitrix24 alongside the current one — stages, rights, required fields are set — and only after a test run on the test contour are deals migrated. Until the switch day, sales reps work in the previous mode.
Setting up an existing system starts with inventory, not cleanup: which stages are actually used, where deals stall, which fields are filled in, and which are no longer maintained by anyone.
We do not delete old statuses — we close them for manual selection but keep them available so cards do not lose their connection to history.
Deal migration proceeds in batches by owner or by dates, with status mapping and preservation of the creation date, amount, and linkage to the contact and company.
Each card receives an external identifier: re-running the export does not create duplicates, and disputed records go into a report and are handled separately — without manually sorting through the entire array.
Reporting breaks not from migration but from incomplete intermediate stages.
Therefore, during the transition period, we keep reference data and refusal reasons consistent in both schemes: you can see where the deal was before and where it is now, and the sales funnel remains stitched together rather than falling apart into two unrelated sets of numbers.
When the reconciliation matches, the department switches to the new contours, and the previous ones remain an archive for audit.
Technical questions on stages, rights, and reports
Stages, rights, and reports in the system are connected: editing one entity changes the behavior of the others. We have collected five concerns that most often surface during design, with brief answers on the merits.
Can an employee be shown only part of the stages?
Yes. Access is configured by roles and profiles: their own department sees the funnel in full, while related units see only the necessary sections and card fields.
Restrictions are set at the rights level, not by manual filtering in reports, so they cannot be bypassed from the interface.
What will change in reports if stages are renamed or reordered?
Deal history is preserved, but reports filtered by a specific stage will have to be rebuilt: some metrics are tied to the stage identifier, not to its name in the interface. Therefore, we make changes according to regulations and immediately check the delivered reporting.
How does a website request go straight to the right stage?
The form passes a set of fields that trigger the distribution condition: source, line of business, request type. The request is created at the starting stage, then moved automatically, and the owner is assigned by a rule. If there are several forms, we link each to its own scenario so that flows do not mix.
Does each line of business need a separate funnel?
This depends on whether the stages and owners differ. If they do, a separate funnel gives clean conversion for the line. If the processes coincide, one funnel with field-based separation is better — otherwise reports will have to be consolidated manually.
Does returning a deal to a previous stage break statistics?
No, this is a standard scenario: the deal goes back, the reason is saved in the card, and conversion counts repeat passes separately from initial ones. Without a required return reason, such deals blur the picture, so the field should be fixed in the form.
Let’s discuss the task: scope of work and start procedure
The review begins with a substantive conversation, not an overview presentation: to come back with an estimate and work plan, we need to see your current sales funnel in Bitrix24 — stages, robots, rights, integrations.
The more context at the input, the more accurate the estimate and the fewer clarifications during implementation.
- Read access to the portal or to a test contour where the current funnel settings can be reproduced.
- A list of funnels and lines of business indicating which are live and which remain from previous schemes.
- A description of the sales process from lead to deal: who changes the stage at which step, and what is considered the result of a stage.
- A list of automation: robots, triggers, business processes, email templates, and tasks that are already working.
- Integrations affecting stages: telephony, email, website forms, exchange with 1C and external services.
- Roles and rights by department — they determine which stage transitions are available to which team.
We analyze deal history, look at where deals get stuck and at which transition the most is lost, and compare this with the stage logic.
As a result, you receive a funnel scheme, an automation map, and a stage-by-stage work plan with a clear start procedure: first, stage design on the test contour, then migration to the production portal without stopping sales. Describe the task — we will come back with an estimate and work plan.