Sales tunnels in Bitrix24: where deal logic breaks
A sales tunnel is not "just another funnel" but a rule for moving a deal between funnels based on an event: payment, signing, qualification.
As long as no such rule exists, a manager manually creates a second deal, copies fields and links, and some data is lost along the way.
It is precisely at these junctions that the logic breaks: in the first funnel the deal is closed, in the second it does not exist yet, while the client is already waiting for shipment.
A typical failure looks like this.
A deal reaches the "Contract approval" stage and gets stuck: the deal owner is on vacation, and no one reassigned the "Assigned to" field — the robot at the stage did not trigger because the trigger condition is described through a field that is not filled in this funnel.
No notification is sent to chat, no task is created, and the deal hangs for weeks. According to the statistics from our projects, up to a third of stuck deals are not a client refusal but an unprocessed transition.
The second break is at the junction of funnels.
The client paid, but the transition to the implementation funnel did not happen: there is no sales tunnel, which means there is neither automatic creation of a deal in the target funnel, nor transfer of links to the contact and company, nor reassignment to a specialized expert.
As a result, implementation starts from scratch, while the original deal remains open and distorts the forecast.
The third is CRM automation built on business processes instead of robots and triggers. A business process is launched manually or on a schedule, does not see a stage change in real time, and cannot roll back on error.
The deal passes a stage, but not a single action is performed — and no one notices until the client calls on their own.
Sales tunnels close all three breaks: the transition between funnels becomes part of the deal logic, the assignee is reassigned automatically, notifications and tasks are tied to the transition event rather than to a manual action. Next, we break down how this is configured and what to check during acceptance.
What configured logic for transitions between pipelines provides
Speed of lead processing
A sales tunnel is not just a transition between pipelines, but a set of conditions by which a deal automatically lands in the right pipeline with a ready-made set of fields, an assignee, and a starting stage.
When the logic is described in rules rather than in a manager's head, the time from lead arrival to first touch is reduced from hours to minutes: the robot records the source, assigns the responsible person by region or product, and triggers a reminder if no touch has occurred.
Reduction of manual operations
Manually moving deals between pipelines means dozens of repetitive actions per day and a constant source of errors: forgot to move it, didn't fill in a field, lost the history.
Automated scenarios take this on — the deal moves itself into the follow-up pipeline after payment or into the return pipeline after a refusal, and all fields and comments are preserved. Managers spend the freed-up time on the client rather than on switching cards.
Stage conversion and lost deals
When every transition between pipelines is recorded in the system, you can see at which stage deals "get stuck" and where the most are lost.
This allows you to fine-tune the logic: add a required field, reduce the number of approvals, set an automatic reminder for "stuck" deals. As a result, the share of lost deals decreases, and stage conversion becomes a manageable value rather than a result of luck.
Transparency for management
Configured tunnels provide end-to-end analytics: from first touch to repeat sale, you can see how many deals passed through each stage and at what speed.
A manager gets an answer to the question "where are we losing money" without exports and manual summaries — the data is already collected by the system.
Automation scenarios: which mode fits when
Standard robots handle typical steps within a funnel: stage change, task creation, email, waiting. They are predictable, require no code, and are configured by the portal administrator.
But as soon as the logic goes beyond a single entity — an aggregate across multiple deals, exchange with an external system, calculation based on data from an accounting system — robots hit a ceiling.
Business processes take on branching, approvals, and working with multiple entities at once. The price of flexibility is debugging complexity: the process lives separately from the card, and without a log its behavior is hard to reconstruct.
External integrations via REST API remove both limitations, but add their own cost — access control, error handling, and retries when the external system is unavailable.
Comparison by tasks and limitations
| Option | When it fits | Limitations |
|---|---|---|
| Bitrix24 robots | Typical steps in a single funnel: stage change, notification, task for the responsible person | Do not work with complex logic and data outside the deal; as the number of conditions grows, they become unreadable |
| Business processes | Approvals, branching, actions across multiple entities and documents | Hard to debug and version; changing the logic requires editing the process itself |
| External integrations via REST API | Exchange with accounting systems, calculations, non-standard checks, data aggregation | Require access control, failure handling, and retries; dependency on the availability of the external system |
How to choose a mode
A practical rule: if a step fits within a single deal and does not require external data — a robot; if logic with branching inside the portal is needed — a business process; if data comes from outside or goes outward — an integration via REST API.
In practice, modes are combined: a robot triggers a process, the process calls an external service and returns the result to the card.
Automation limitations should be factored in advance: rate limits on requests, response timeouts of the external system, and behavior when it is unavailable. Describe your task — we will come back with an estimate and a plan for which mode fits your process.
Setup stages: from funnel audit to handover of regulations
Setting up sales tunnels is not a one-time interface tweak, but a sequence of engineering steps where each subsequent one builds on the result of the previous.
The order matters: if you start with configuration rather than an audit, the transition scheme will be built "as-is" and will diverge from the actual sales process within a month. Below is what this looks like in practice.
- Funnel audit. We capture the current state: how many funnels there are, what the stages are, where deals "stall," and which transitions employees make manually. We record bottlenecks and the rules that have already formed spontaneously — these cannot be broken, otherwise the team will revert to workarounds.
- Designing the transition scheme. We describe which stage of one funnel leads to which stage of another, under what condition, and who initiates the transition. The scheme is agreed with the department head before configuration begins — edits at this stage are cheaper than reworking finished logic.
- CRM configuration. We implement transitions through robots and business processes, and where standard tools are insufficient — we connect the REST API. We check permissions: an employee should only see the funnels they work with, otherwise tunnels become a source of confusion.
- Test deals. We run each scenario on anonymized deals: a regular transition, a return to the previous stage, a rejection, a reopening. We check that tasks are not duplicated, assignees are not lost, and notifications trigger correctly.
- Handover of regulations. We give the team a document with the transition logic, a responsibility matrix, and instructions for managers. We conduct a short training session and leave contacts for questions during the adaptation period.
After handover, the scheme does not live on its own: we identify the points where the logic will need to be revisited when the sales process changes, and show how to make edits without stopping the department's work.
Setup artifacts: what the client keeps
Setting up sales tunnels does not end the moment a deal first travels along the new route.
The value of the solution rests on what remains in the system and in the team's hands after handover: without this, in a month no one will remember why a deal went into a specific pipeline, and any edit will turn into archaeology through the logs. That is why we capture the result as a set of artifacts, each of which solves its own task.
- Pipeline map — a diagram of all directions with entry points, transition conditions, and the links between them. It shows where a lead from each form lands and what happens to it next, without reading the settings in the interface.
- Trigger rules — a table of conditions: which field, event, or manager action initiates a transition, which robot or business process runs, and what happens on a repeat trigger. This is the main document when investigating "the deal didn't move" incidents.
- Notification templates — the texts of emails, chat messages, and reminders tied to stages. When the route changes, the template is edited, not the entire logic.
- Manager instructions — a short 1-2 page regulation: what the employee sees at each stage, which fields are mandatory, and where to write in case of a failure. A new person gets on the route on their first working day.
- CRM documentation — a description of fields, reference lists, and relationships between entities, including custom ones. It is needed when a new channel or integration is connected to the system.
- Integration diagram — which external systems exchange data with the CRM, in which direction the records flow, and where the point of failure is.
- Change log — what was changed in the routes and why, with dates and authors. It allows rolling back an edit precisely, without rebuilding the logic from scratch.
We hand over the set in two forms: a working copy in the knowledge base and an export to the repository, so that edits go through version history rather than on top of the live system.
This is enough for your team to maintain the routes, while we step in on a targeted basis — for new directions or complex scenarios.
Case study: how sales tunnels shortened the deal cycle
The client is a sales department with two product lines and a shared flow of leads from forms, telephony, and messengers. Before implementation, the manager manually decided which funnel to send a lead to, and also manually moved deals between stages.
At the junction of the lines, leads got stuck: some were lost during shift handover, some went to the wrong funnel and only surfaced in the report at the end of the month. The average deal cycle held at 21 days, and the share of overdue stages reached 40%.
We analyzed the inbound flow and built sales tunnels: lead routing is determined by lead attributes — source, region, amount, and product type.
Then the deal moves along its own tunnel, and automatic transitions are triggered by events: invoice payment, sent commercial proposal, scheduled meeting. Robots record the time limit at each stage and return the deal to the manager if he does not move it forward. Stage control no longer depended on the discipline of a particular employee.
Lead distribution also moved to automation: the rules take into account the manager's workload, his specialization by line, and his schedule.
A new lead reaches the responsible person within seconds, rather than after the morning stand-up, and immediately goes to the right funnel.
Bitrix24 in this scheme is not only the interface, but also the integration layer: some transitions are initiated by external systems via REST API, so the deal status in the CRM matches the status in the accounting system.
The result of implementation for the first quarter: the deal cycle was reduced from 21 to 13 days, the share of overdue stages fell from 40% to 9%, and lead losses at the junction of the lines — from 7% to zero. The funnel report is now generated automatically, not manually.
How are sales tunnels different from a regular funnel?
A funnel is a sequence of stages within a single pipeline: a lead passed qualification, received a quote, approved it, paid. A sales tunnel is not an alternative to it and not a "second funnel alongside," but a set of rules for transitioning between funnels and stages.
A deal starts in one funnel, and at a certain stage automation moves it to another — while preserving history, assignees, and related entities.
The CRM logic here is this: the funnel describes where a deal is, while the tunnel describes under what condition and where it moves next. Transition rules are set by a trigger: stage change, filled field, call outcome, client type.
For example, a deal for a standard delivery reaches the "Contract approval" stage and moves into a separate legal approval funnel, which has its own stages and its own assignee. Once the contract is signed, it returns to the original funnel at the shipping stage.
Deal routing is built on a combination of conditions, not on manually dragging cards around. This eliminates the main pain point: the manager no longer decides on their own where to move a deal and doesn't forget to move it back.
Every transition is recorded in the history, so you can see which rule a deal got stuck on and who is holding it.
The practical difference shows up in long and heterogeneous processes. A single funnel works well when all deals follow the same route.
As soon as branches appear — tenders, government procurement, service maintenance, repeat sales — keeping them in one funnel becomes cramped: stages start to conflict, and reports lose their meaning.
Tunnels separate these branches into individual funnels while preserving the overall logic and end-to-end analytics.
On the technical side, tunnels rely on the built-in robots and triggers of Bitrix24, and where standard scenarios are not enough — on the REST API: creating a deal in the target funnel, transferring fields, linking contacts and companies, setting tasks.
That is why before setting things up we always map out the routes on paper: which branches exist, under what condition a deal leaves a funnel and under what condition it returns.
Without this scheme, automation turns into a set of disconnected rules that no one can explain a month later.
Questions and technical concerns before implementation
Before starting, customers most often ask the same thing: will automation break the processes that are already working, and who will maintain the logic once the contractor leaves.
These are reasonable questions — sales tunnels are embedded into a live pipeline where there are already deals, assignees, and a history of correspondence, so implementation is planned in such a way that current processes do not stop for a single day.
A separate topic is CRM customization.
Some scenarios are covered by standard robots and business processes, while some require external logic via the REST API: exchange with the accounting system, non-standard conditions for transitioning between stages, notifications to external channels.
We separate in advance what is handled by configuration and what is handled by code — this removes the main fear of "we'll get in and drown."
How difficult is it to maintain automation after launch?
The complexity of configuration and maintenance depends not on the number of tunnels, but on how well the logic is documented.
We hand over the transition scheme, the list of robots and triggers, and the integration points — maintaining automation turns into a clear set of procedures rather than deciphering someone else's code. Changes are made in a targeted way, without rebuilding the entire pipeline.
Will current processes have to be stopped during implementation?
No. New tunnels and rules are configured on a copy of the pipeline, tested on test deals, and only then enabled in the production environment. Employees continue to manage deals in their usual mode; only the route for transitioning between stages changes.
What happens if the logic stops working after an update?
External CRM customizations are isolated from the standard core, so platform updates do not affect them. For critical scenarios, we set up checks and error notifications — a failure is visible immediately, not a week later when sales have dropped.
Describe your pipeline and current processes — we will get back to you with an estimate and an implementation plan.
Let's discuss your task and come back with a plan
To make the setup proposal concrete rather than "we'll do it well," we start by analyzing your current configuration.
It's important for us to understand how your funnels are currently structured, who changes the deal stage and at which point, where the handoff between departments breaks down, and which scenarios are already automated by robots. Then we look at what is covered by sales tunnels and what requires logic refinement.
Based on the CRM audit, you receive not an abstract estimate, but a work plan with priorities: what delivers results immediately, what can be deferred to the second phase. Below is what our sequence looks like if you decide to discuss the task with us.
- We analyze the current scheme: funnels, stages, responsible parties, rules for transitioning deals between departments.
- We identify bottlenecks — where deals get stuck, lost, or duplicated between groups.
- We agree on the target tunnel logic: which conditions trigger a transition, what happens to the deal and its history.
- We prepare a setup proposal: a list of robots, triggers, rules, and refinements if standard tools are insufficient.
- We assess the scope: what is covered by built-in tools and where refinement via REST API is needed.
- We agree on a phased work plan — with clear timelines and checkpoints at each stage.
- After launch, we test the scenarios on test deals and hand over documentation on the logic.
What we need from you at the start: access to the portal with administrator rights, a description of roles, and at least one real example of a deal that passes through several departments.
That's enough to come back with an estimate and a plan — without vague words and inflated expectations.