Bitrix24 deal setup: where the sales funnel breaks
In the standard delivery of Bitrix24, the sales funnel repeats the demo stages: “New,” “In Progress,” “Success.” Such a scheme does not describe the real deal cycle — managers move cards manually and arbitrarily, and deals get stuck at a stage where no responsible person is assigned or no next action is set.
The second failure point is manual card completion. If fields are not required on transition, and the amount and client data are transferred from an invoice or contact by hand, then empty amounts, duplicates, and lost contacts accumulate in the CRM.
The manager sees the total funnel amount but does not understand which deals are alive and which are hanging as dead weight.
The third is access rights: when full access to deals is granted to the entire department, sales reps edit others' cards, and reports stop reconciling.
Configuring deals in Bitrix24 closes this not with persuasion but with mechanics — required fields on transition, robots and triggers based on idle time, and role-based access differentiation.
Next, we break down how this is closed: from the stage scheme and automation rules to reports you can trust.
What order in deals delivers: measurable effect
The first effect is deal velocity. When each stage has an entry and exit condition described, and the transition is performed by a robot in Bitrix24 on an event, the sales rep stops being a bottleneck: the invoice, reminder, and task assignment go out without their involvement.
The cycle from first touch to payment is cut by one and a half to two times — this is visible in the average deal duration in reports.
The second is transparency of the sales funnel: the share of deals without movement. In an unprocessed funnel, it reaches up to a third because cards hang at a stage without an assigned next action.
The rule “no task — no stage” and automatic reminders by deadline keep the metric within a few percent, and stalled deals are visible in the manager's report on the same day, not at the end of the quarter.
The third is the number of manual operations per deal. Filling fields from the company card, template documents, and scheduled follow-ups are taken off the sales rep: where a dozen transitions between sections were required, one remains. The freed-up time goes to talking with the client, not to servicing the system.
The fourth is the class of lost data. Inquiries from email and messengers, losses with reasons, and correspondence history settle in the deal, not in personal folders.
Loss reasons are counted by the funnel, not collected via a survey, and when an employee leaves, deals remain in progress along with the context.
Manual stages, robots, or external automation: what to choose
Standard stages and robots cover a typical process without code: the robot moves the deal, assigns a task to the responsible person, and sends the invoice.
As long as the logic fits the “event → action” pattern, this is enough, and edits are made by the CRM administrator, not a developer.
As soon as branching by amount, client type, or warehouse stock appears, standard conditions are not enough.
Then we either customize the card, access rights, and reports for a specific process, or set up an external integration with the accounting system, leaving the status and history in the CRM.
| Option | When it fits | Limitations |
|---|---|---|
| Standard stages and robots | The process is typical, few branches, fast launch needed | Does not cover complex conditions and calculations; as logic grows, the number of robots and conflicts between them grows |
| Customization for the process | Unique approval rules, custom fields, roles, and reports | Support is needed during updates; the deeper the edits, the more expensive the migration |
| Integration with the accounting system | Data on stock, shipments, and payments lives outside the CRM | Depends on exchange stability: discrepancies, repeated transfer, status delay |
Where the boundary lies
The limitation of automation is not in the tool but in the data. If sales reps edit fields manually and run deals bypassing stages, robots trigger on an incorrect state. Therefore, we first fix the completion rules and access rights, and then automate.
Implementation order: from funnel audit to handover of regulations
We start the sales funnel audit not with interviews but with an export of deals for a period: we look at which stages accumulate the bulk, how much time a deal spends at each, and which fields are filled inconsistently.
This gives a real picture instead of the manager's idea of the process — and it is according to it that we design the scheme. We roll out the CRM implementation stages sequentially so that the portal does not have to be redone after launch.
- Survey. Analysis of current stages, fields, reports, and roles; we separately record which deals are run outside the system and why.
- Stage scheme. List of stages, grounds for transition, required fields at each; we collapse extra stages and split vague ones.
- Business process setup. Robots and automation: task assignment, emails, movement by stage on an event, not from the sales rep's memory.
- Access rights. Role matrix by stages and fields: sales rep, department manager, finance — each sees only their own, and database export is limited.
- Testing on real deals. Run scenarios on a copy of the portal: incoming deal, return from a stage, loss, repeat inquiry. We make edits before handover to work.
- Training and handover of regulations. Instructions on stages, robot map, rights matrix, procedure for changing the funnel and the person responsible for it.
After the handover of regulations, the portal lives by the document, not by the administrator's memory: each new stage or robot is described through the task it solves.
What you keep: stage maps, rights, regulations
Configured stages do not work by themselves: without a description of the rules, they begin to be edited “to suit themselves” within a month, and the logic falls apart.
Therefore, we hand over not a finished CRM but a set of artifacts by which the department runs deals without our involvement, and further edits are made into a clear scheme, not into a live process.
- Stage map — funnel scheme with the order and names of stages, transition conditions, and a list of required fields at each step.
- Access rights matrix — what each role sees, changes, and exports: separately the right to change the stage, edit the amount, and delete a deal.
- Set of rules and robots — for each one, it is specified what triggers it and what happens next: task, email, reminder, escalation to the manager during idle time.
- Instructions for sales reps — one-page memos for each stage: what to fill in, which files to attach, when to move the deal further.
- Sales department work regulations — deadlines for processing incoming, what to do with a stalled deal, when to record a loss, and how to return it to work.
- CRM documentation — description of fields, reference lists, and deal links to contact and company, so that new fields do not duplicate existing ones.
- Change log and backups — what and when changed in the configuration and how to restore the previous stage and rights scheme.
We adapt the composition to the number of departments and roles: for a small team, some blocks are reduced to one page, but the stage map, rights matrix, and regulations always remain.
Case study: how manual operations in the sales department were reduced
Before and after implementation: where deals stalled
The client is an industrial equipment supplier, with a department of nine sales reps. Before starting work, we exported the deal history from Bitrix24 and calculated the funnel metrics.
Of 420 deals in progress, 160 had not moved for more than a week, and two-thirds stalled at invoice approval.
One deal accounted for 14 manual operations: issue an invoice, compose an email, set a task for oneself, manually drag the card to the next stage, remind the client about oneself.
Some steps were simply forgotten — the card remained at the old stage, and the manager's report diverged from reality.
What was changed and what it delivered
Stages were described with required fields and transition conditions.
Robots were attached to key steps: the invoice goes out after the amount is confirmed, a task with a control deadline is set automatically, and when payment is received, the card changes stage without the sales rep's involvement.
Access rights were separated by department, and the system writes a change of responsible person to the card history.
Two months after implementation, deal cycle time fell from 26 to 14 days, the share of cards without movement dropped from 38% to 9%, and manual operations per deal became 5 instead of 14.
The manager now sees bottlenecks from the report, not from questioning at the planning meeting. The reduction in manual operations here rests not on a “magic button” but on stage discipline and transition rules.
How stages, robots, and business processes differ
A stage is the state of a deal on the funnel scheme: it answers “where we are now,” not “what to do next.” The logic of transitions is set not by the stage but by entry conditions: who moves the deal, whether a field is required, whether a stage can be skipped. In Bitrix24, this is configured at the level of the card and rights.
A robot is an automatic rule tied to a deal stage or event. It works as a flat scenario: one action — one consequence, within the boundaries of one deal and one funnel. The log shows why the rule triggered or was skipped, and editing one robot does not break neighboring stages.
A business process is an end-to-end route with branches, parallel steps, and participation of different departments.
Discount approval, a request for non-standard configuration, counterparty verification: the process launches on top of the deal, lives across several stages, and survives a change of responsible person.
What to choose: linear communications and reminders — robots; they are predictable and cheaper to support. Approvals with return for revision and multiple participants — business processes.
More often the scheme is mixed: stages hold reporting, robots move the deal, and processes cover exceptions.
Access rights are a separate layer. A robot and a process are executed on behalf of a user or a service account: without rights to a field or stage, the rule will work partially or roll back.
Therefore, the role matrix is described before automation; otherwise the funnel works in testing and breaks on live deals.
Doubts about rights, integrations, and data migration
Doubts usually surface at the stage when the logic of stages has not yet been agreed, and it will have to be transferred to live data.
This is a normal signal: it means the boundaries of responsibility and the connection points with the accounting system are discussed before work starts, not after launch. Below are the things that most often slow down the decision.
How do you delimit access if areas of responsibility overlap in the department?
We assemble rights on three levels: role in the system, rights to a specific stage, and field visibility.
The role defines access to the section, the stage level defines which deals an employee sees and can move, and field visibility closes amounts and contracts from adjacent teams.
Separately, we configure a ban on changing the responsible person and editing closed stages; otherwise deal history is reset retroactively. All rights changes go into the action log — you can see who received extended access and when.
What will happen to deal history when data is migrated to the CRM?
We transfer not only active deals but also closed ones: creation dates, responsible persons, correspondence, files, comments, and current stage.
The key point is reference data: counterparties and nomenclature are merged once, and then deals reference them rather than creating duplicates.
Before export, we run a full migration on a test environment and compare the number of deals, amounts, and distribution by stages — we resolve discrepancies before launch.
How do you link deals with the accounting system so that data does not diverge?
One system remains the source of truth for primary documents, the second for the sales process, and the link rests on an external identifier of the counterparty or order. This excludes duplicates: a repeated export updates an existing record rather than creating a new one.
Payment and shipment statuses are pulled back into the deal card, so the sales rep does not need to check with accounting manually.
Will the department have to be stopped during setup?
No. We roll out stages and robots in parts, first to a pilot group, while the rest continue to work in the current mode.
We switch over at a moment of low activity, and changes to rights, automation, and fields can be rolled back with one operation if the behavior turned out not to be what was expected.
Who will be able to change settings after handover?
We hand over to administrators the stage scheme, rights matrix, list of automation with trigger conditions, and instructions for typical edits. Your specialists then add fields and edit notification texts themselves — without contacting us for every little thing.
Let's discuss your funnel and come back with a plan
To make the scope estimate accurate and the implementation plan feasible, it is enough to describe the current structure of the funnel and how it should work after customization.
Some points can be clarified on a call — but the more specific the input data, the fewer clarifying rounds before work starts.
- List of deal stages in the current order and what each one means: where the sales rep qualifies, where they wait for the client's response, where they hand over to a paid deal.
- Required fields at each stage: which data a deal must not move further without and who fills them in.
- Robots and triggers: what should happen automatically when a stage changes — task assignment, email to the client, invoice, reminder about a stalled deal.
- Access rights: who sees and moves deals, who changes amounts and the responsible person, where restrictions by department are needed and why.
- Connections with the 1C accounting system, telephony, email, and website forms: which data must be transferred and in which direction.
- Volumes: how many deals pass per month, how many sales reps and funnels are in operation, whether accumulated history needs to be migrated.
- Exceptions and regulations: non-standard deals, discount approvals, repeat inquiries, data storage requirements.
- What is already configured and what is getting in the way now: where deals are lost, which stages are duplicated, what sales reps complain about.
Describe the task by letter, table, or a short call — we will come back with a scope estimate, a stage scheme, and a work plan.
After approval, we start immediately: configuring deals in Bitrix24 proceeds in stages, so you will see the first changes before the entire scope is complete.