Setting Up a Bitrix24 Sales Funnel: Where Tracking Breaks Down
A sales funnel in Bitrix24 can be set up formally — stages created, rights assigned, a report generated. But once you reconcile it with contracts and closing documents, it turns out that some deals never made it into the records at all.
Usually the cause is not the report itself, but three areas: vague stages, duplicate cards, and deals that live outside the system.
Vague deal stages break the entire arithmetic. If 'invoice sent' and 'client is thinking' are the same stage, each manager closes it in their own way, and conversion between stages stops meaning anything.
A workable option is a stage as a verifiable action with a required field: until the field is filled in, the deal does not move forward.
Duplicates create a second wave of discrepancies. A request comes from a form, from a call, and from correspondence — and is created as three cards. Some are closed as rejected, some are simply abandoned, and deal tracking shows a funnel wider than it actually is. Without a matching rule based on company contact and phone number, the numbers remain decorative.
The third is deals outside the system. You agreed in correspondence, shipped the goods, and the card was created retroactively or not created at all.
Lead sources are not filled in, so the sales report does not answer the main question: which channel brings revenue, and which brings only requests. Let's look at how this is closed by configuration, not by persuading managers.
What Changes in the Sales Department's Work After Setup
Sales analytics stops depending on manual collection. While the deal source is filled in from memory and stages are moved manually, the report is built on a sample where some cards have no channel and no closing date.
Required card fields and automatic source population from the first touch eliminate this class of errors: the share of deals without a source drops to single-digit percentages, and reconciliation with the accounting system runs by key, not by a similar company name.
Stage-by-stage conversion becomes manageable rather than observed after the fact. Robots on transitions record entry and exit dates, so the bottleneck is visible in numbers: at which step the most deals are lost and where they sit longer than others.
A stage time limit prevents the card from getting stuck — an overdue deal returns to the owner's work without reminders from the supervisor.
The deal cycle shortens through transparency, not pressure. When each stage has a transition criterion, disputed 'client is thinking' stops being a reason for idle time: the deal either moves according to the rule or is closed with a recorded reason for rejection.
Report accuracy rests on recalculation rules, not on the performer's discipline. In Bitrix24, a unified logic is configured: what counts as the start of the cycle, how repeat inquiries are counted, which stages are included in the summary.
The funnel report is generated on a schedule, and the time spent preparing it is removed from the supervisor's routine.
Methods of Collecting Analytics: Comparison of Approaches and Limitations
Sales data enters analytics through different paths, and each path imposes its own limitations on what questions about the funnel can be asked at all.
Manual summaries in spreadsheets last until the first change of manager, native Bitrix24 reports see only what is entered in the cards, and data exchange with the accounting system adds the fact of payment and shipment to deals. Below is a comparison of approaches by what each gives and does not give.
| Option | When It Fits | Limitations |
|---|---|---|
| Manual reports in spreadsheets | One-off snapshot, small deal flow | Become outdated on the day they are delivered, no history of transitions between stages, errors are not tracked |
| Native funnel analytics | All stages are managed in cards, fields are filled in consistently | Sees only the system: payments and refunds outside it, will not show discrepancies with the accounting loop |
| Data exchange with the accounting system | Revenue, payments, and cost of goods sold by deal are needed | Requires matching reference data and stable identifiers, exchange has a delay |
| Consolidated analytics in an external storage | Multiple channels and systems, long history | Requires an update schedule and an owner responsible for data quality |
The difference shows over the long run. A manual report cannot be recalculated retroactively without losing detail, while native analytics shows stages but does not reconcile with finance.
Consolidated analytics on top of the accounting loop provides both — at the cost of configuring reference data matching and an exchange schedule that will have to be maintained.
Work Stages: From Data Audit to Handover of Regulations
The work follows one order: first we put the data in order, then we build reporting, then we test it on real deals. The reverse order produces beautiful charts on top of unfilled fields and duplicate stages — no decisions are made from such numbers. Below are the stages of implementing sales funnel analytics in Bitrix24.
- Data audit. We export a snapshot of deals for several months, compare actual transitions with the configured stages, look for fields that managers fill in manually and therefore skip, and deals stuck at intermediate stages.
- Funnel scheme. We fix the set of stages and their meaning, required fields at each, transition rules, and automatic actions. We agree on the scheme with you before configuration — retroactive changes are more expensive.
- Configuring rules and reports. We build reports on conversion between stages, time a deal spends at a stage, rejection reasons, and employee workload. We separate access by roles: the supervisor sees the entire funnel, the manager sees only their own deals.
- Verification on control deals. We run test deals through all branches of the process and compare the numbers in reports with a manual calculation. A discrepancy at this step means an error in the rules, not in the data.
- Data handling regulations. We describe who and when moves a deal, how a rejection is formalized, what to do when fields are incompletely filled, and who is responsible for quality.
- Handover. We provide instructions, schemes, and records of reviews, and show control points by which you can notice a drop in the funnel yourself.
Accounting Schemes, Access Rights, Regulations, and Instructions
After the funnel is launched in Bitrix24, the team is left alone with the system: managers change statuses, marketing adds sources, the supervisor asks for a new snapshot.
If the funnel scheme, field completion rules, and access matrix live only in chat, the first new employee breaks the reporting logic.
That is why we hand over a kit by which the processes can be reproduced without us:
- Funnel scheme — statuses, their order, transition conditions, success and failure indicators. It restores conversion logic after any edit.
- Field completion rules — required and calculated fields, reference lists of sources and rejection reasons, prohibition of free-form input. Deals with empty analytics become many times fewer.
- Access matrix — roles, binding to business lines and departments, rights to view, edit, and export. The supervisor sees their deals, and excess data does not go outside.
- Sales department instruction — a step-by-step scenario for working with a deal: when to set which status, what to attach, how to record a rejection.
- Report documentation — reference reports, fields and filters on which they are built, the procedure for when numbers diverge.
- Change and reconciliation regulations — who has the right to edit the scheme and fields, how new statuses are approved so as not to erase history; frequency of checking convergence with the accounting system, searching for duplicates and stuck deals.
The kit stays with you: new employees enter the process by instruction, not by stories, and changes in analytics do not require calling us.
Case Study: Report Discrepancies Were Reduced Threefold
A wholesale supplier with several product lines managed deals in Bitrix24, but each department renamed stages to suit itself: for some, 'Contract' meant agreeing on terms; for others, it already meant signing.
Managers filled in the inquiry source from memory, and some deals were created manually after shipment. The funnel report did not reconcile with the export from the accounting system, and reconciliation took almost a full working day of an analyst.
We consolidated the stages into a single scheme with a fixed order and a prohibition on skipping stages.
The source began to be populated automatically from the inquiry channel at the moment the deal was created, and the deal itself was linked to a document in the accounting system by a requisite — the funnel report and sales data stopped living separately.
Metrics Before and After
| Metric | Before | After |
|---|---|---|
| Discrepancies between funnel report and accounting | 12–15% of deals monthly | 3–4% |
| Deals without an inquiry source | more than half | isolated, closed with a task |
| Time for report reconciliation | about a day | 1–2 hours |
| Deals outside current stages | after a funnel change — dozens | identified the same day |
Discrepancies were reduced threefold, and most importantly, they stopped accumulating: each new deal immediately receives the correct stage and source. Conversion between stages can now be read by channel, and the forecast for open deals relies on data, not on managers' memory.
What to Do If the Funnel Is Set Up but the Numbers Do Not Reconcile?
The discrepancy is almost never in the funnel itself. The report calculates by the selected funnel, period, and current stages, while the deal export covers all business lines at once, together with the recycle bin and archive.
Therefore, the first step is to take raw data for the same period with creation and closing dates and compare line by line: is it the number of deals or the amount for them that differs?
Lost sources surface first.
The source field is set at the first touch, but on a repeat visit the tags are overwritten, and the deal moves into 'direct entry.' We look at how many deals have an empty or default source, and whether there are unconverted leads followed by calls and correspondence.
Duplicates are the second common cause. They appear when importing from spreadsheets, when a request comes from a form and a messenger at the same time, or when a manager creates a deal after not finding the client by phone.
We check the deduplication rule, the import key, and whether every reply in a dialogue spawns a new deal: a duplicate distorts both the number of deals in a stage and the average deal size.
Next are service discrepancies: access rights, period boundaries and time zone, amount with discount versus amount without it, deals in the recycle bin and archived stages. The same report under a supervisor and under a manager will give different numbers on the same data.
The troubleshooting order is strict: reconciliation of raw exports and the period, then sources, then duplicates, and only after that stage and robot settings. Funnel edits before this step simply erase the traces of the problem.
Frequently Asked Questions About Data Collection and Reconciliation
Below are the questions that most often arise before the start: they concern data exchange between CRM, the accounting loop, and analytics, not interfaces. The answers are short but show how each doubt is resolved at the configuration level.
Why do the numbers in the report and in the deal cards differ?
The discrepancy is almost always explained by a different moment of recording: the deal changes stage in one place, while the export takes its state on a schedule.
We run the exchange by change log, not by full overwrite, and preserve deal and stage identifiers — thanks to this, every number can be expanded to a specific record and you can understand where it came from.
Can everything be configured without stopping the sales department?
Yes. The work runs on a test environment where deal history is copied without affecting the production database.
We switch over during a low-activity window, and launch the first exchange in read-only mode — managers continue working in their usual interface, and data exchange runs in the background.
Will we have to maintain manual spreadsheets in parallel?
The point of the setup is to eliminate double entry. Reference data, owners, and stages are pulled from the system, and discrepancies that used to be searched for manually are put into a separate control report.
Manual files remain only as a source of one-off adjustments, and their entry into shared data is visible.
How is deal history transferred, and will stages be lost?
History is transferred in a separate pass: first the structure of funnels and stages, then deals linked to contacts and companies. Records are matched by keys, duplicates are cut off, and closed deals are marked with correct dates.
After the transfer, we reconcile the count and amounts by stage — a discrepancy is acceptable only where it is confirmed by the source data.
Who will see all the data, and how are rights restricted?
Access is assigned by roles: the business line supervisor sees consolidated analytics, the manager sees only their own deals, and the integration exchange runs under a separate account with the minimum necessary rights. This excludes situations where reporting lives outside the access regulations.
Let's Discuss the Task: What Is Needed to Estimate the Scope of Work
To come back with an estimate and a plan, rather than general statements, we need a minimum of input data about your portal.
Below is a short list of what noticeably speeds up the review: with this set, we immediately see the scope of work on the funnel and understand where entities will need restructuring and where analytics configuration is enough.
- Access and data. A portal with rights to view CRM, funnel sections, and reports; a separate test user so as not to interfere with the department's work. If access separation is strict, describe which snapshots we are allowed to see.
- Sales process scheme. How a deal travels from first inquiry to payment: how many stages, who moves it further and by what criterion, which stages currently duplicate each other.
- Examples of reports. Two or three exports you currently work with: what you look at in them, which numbers are missing, and which metrics raise doubts about reliability.
- Lead sources and integrations. Telephony, website forms, messengers, 1C — where the inquiry comes from and how statuses are passed back to the portal.
- Reference data and fields. Required card fields, owners, rejection reasons. This way we will see where analytics falls apart because of incomplete data, not because of logic.
- Project start constraints. Regulations, roles, period closing deadlines — everything that cannot be changed during configuration.
Describe the task in free form: the current state of the funnel, what exactly should be counted, and what decisions you want to make based on it. We will come back with an estimate of the scope of work, a stage plan, and a list of timeline risks.