News and analysis
CRM implementation: making the sales pipeline manageable
Define deal stages, salesperson responsibility and conversion rules so the CRM supports useful sales decisions.
After a CRM rollout, management sees more records and charts, but the old question remains: which deals are actually moving towards a sale? One salesperson selects “Proposal” after sending an email; another does so after discussing terms. The report treats them alike, although the next work differs.
A manageable pipeline needs shared stage meanings. Integrations and reports help enforce them and examine exceptions. Configuring those tools before agreeing the process risks embedding employees' conflicting assumptions.
A collected Bitrix24 blog article demonstrates a dashboard aggregating deals, stages and salespeople, with AI-assisted configuration editing subject to confirmation. It shows that a report can be built from CRM data. It does not prove that the source data reflects the sales team's performance. BI dashboard example.
The Center for Sales Strategy recommends checking qualification through observable evidence: a clear buyer problem, decision participants and an agreed next action. These are a consultant's methodological recommendations, not published proof of sales growth. For a CRM, they suggest retaining evidence for transitions that management can inspect. Checking whether a deal is real.
Define the event that changes the stage
Consider a hypothetical equipment sales team. An incoming enquiry becomes a qualified opportunity when the need, suitable product and next step with the buyer are understood. A proposal counts as being discussed once the customer responds. These are example definitions; a particular business may use different ones.
For every stage, record the entry condition, owner and expected action. “Call back” without a date does not define the next step. “Waiting for customer” does not explain what the customer must confirm. Precise conditions make stalled deals easier to find.
Do not require every field at first contact. Some information is only learned in conversation. Make a field mandatory at the transition where it supports a decision. Otherwise, salespeople will enter placeholders and record completeness will become a decorative metric.
Separate contacts, enquiries and opportunities
One person may return with a new need. Several employees at the buyer's company may discuss one purchase. Counting every contact as a separate deal increases opportunity numbers without changing demand. Merging everything by phone number can erase a distinct request.
In the proposed model, a contact describes a participant, an enquiry records an incoming request and an opportunity concerns a specific potential sale. The CRM's actual entities may have different names. Agree merging rules and preserve links between records.
Management should see unprocessed enquiries separately from active opportunities. This distinguishes problems in incoming demand from problems advancing a deal. Automatic routing should result in an assigned owner; creating a record alone does not establish that work has started.
Give conversion a clear denominator
Dividing this month's closed deals by this month's new enquiries mixes different buyer groups. Some sales came from older opportunities, while some new enquiries have not completed the cycle. For a long sales cycle, the result is particularly hard to interpret.
A proposed analysis groups opportunities by their creation period and follows their progress. State what counts as entry, which records are excluded and the date through which outcomes are known. Open deals must not automatically be classified as lost.
Compare conversion separately from time spent in each stage. A salesperson may reject unsuitable enquiries faster and appear worse on win rate while freeing time for suitable buyers. Before changing incentives, examine the team's incoming mix and assignment rules.
Let automation support the transition
Once stage meanings are defined, the system can remind staff of the next action, transfer data or create a task. A technical event should trigger an agreed operation. Bitrix24's official documentation describes an outgoing webhook for a deal-added event; its request contains no user OAuth tokens. Design the retrieval of additional data separately. Event handlers.
The documentation also requires comparing auth.application_token with the stored value to verify the call's source. Keep this secret out of logs and client code. Handler security.
Successfully receiving an event does not establish that a task was created. In the proposed integration, transfer state is visible separately and errors have an owner. Retry and duplicate-handling principles are covered in the reliable CRM workflows article.
Test acceptance through disputed cases
Use an ordinary enquiry, repeat request, reopened deal and enquiry with insufficient information for acceptance testing. Ask different salespeople to process them under the new rules. If they choose different stages, clarify the definitions before expanding automation.
After launch, inspect the age of deals without a next action, the share of enquiries without an owner and reasons for leaving the pipeline. These reveal process gaps. There are no universal targets: values depend on the sales cycle and team agreements.
The first stage may cover one sales area and a few transitions. To discuss CRM integration, prepare existing stages and anonymised examples where employees disagree. This establishes rules before choosing modifications and report content.
Base reporting on defined operational events
At Dent-Picks, I developed an employee leaderboard covering 15 quantity and quality measures, including leads, money, calls and SMS. Another implemented workflow creates a GoHighLevel lead after an incoming IVR call. These elements connect an enquiry with observable team activity. They do not establish the pipeline stages proposed here or universal conversion targets; those rules need agreement for the particular sales process.
My guide to moving from spreadsheets to a system checks the reporting foundation: who owns each status, where data originates and which incomplete handoff holds up an order. Exercise those cases before assessing employees. Otherwise an integration failure can be mistaken for a missing next action.
Sources
- The Center for Sales Strategy: How to Tell If a Deal Is Real, 30 July 2026.
- Bitrix24 blog: a BI dashboard with an AI editor.
- Bitrix24 REST API: event handlers.
- Bitrix24 REST API: handler security.
Sources checked on 7 October 2026. Pipeline rules and metric calculations are proposed as an analytical model; no implementation results are claimed.