A sales pipeline in a CRM is the sequence of stages a deal passes from the first enquiry to payment. Every stage has an entry criterion, an owner and a time limit, while everything that happens after payment — fulfilment and repeat sales — runs in a separate pipeline. Implementing a CRM with a pipeline built around your stages starts at $3,000 at Syntra Systems.
Key takeaways
A pipeline is not a picture for a presentation but a set of stages that deals are moved through in the system. Bitrix24 calls pipelines "directions" and describes them as a set of kanban stages for working with deals, with access rights configured separately for each one — as the vendor documentation explains.
A sales pipeline ends with payment or with a loss. Everything beyond that — production, delivery, implementation, repeat sales — is different work, with different owners and different deadlines. It belongs in a separate pipeline, otherwise conversion stops meaning anything: a deal "in production" is no longer in sales and should not sit in the sales team's report.
Pipelines are linked automatically. Sales tunnels connect pipelines: at a chosen stage the deal is copied or moved into the next one, and nothing is re-entered by hand — this is described in the documentation.
A stage describes the state of the customer, not how busy a sales rep is. "In progress" cannot be a stage: it tells you neither what has already happened nor what should happen next.
| Stage | What has already happened | Criterion for moving on | Owner |
|---|---|---|---|
| New enquiry | The enquiry reached the CRM, the source is recorded | You got through by phone or received a reply in chat | Sales rep |
| Qualification | You know what the customer needs, the budget and the deadline | The customer's task and constraints are written on the card | Sales rep |
| Proposal | The customer received a quote or a commercial proposal | The customer confirmed receiving and reading it | Sales rep |
| Negotiation | Scope, price and terms are being discussed | Terms agreed verbally, objections resolved | Sales rep and head of sales |
| Contract and invoice | The documents were sent to the customer | The contract is signed, the invoice is issued | Sales rep and lawyer |
| Payment | The money has arrived | Payment confirmed, the order goes to fulfilment | Finance |
A loss sits outside this chain. It is not a stage of the process but its outcome, and it always carries a mandatory reason field. Keep the number of stages small: six to eight is enough for almost any team, and every extra stage is one more place where a deal can get stuck for no reason.
Transitions are locked with mandatory fields: amount and scope at the proposal stage, company details and deadline on the contract, date and method on payment. This is not bureaucracy but a guarantee that the report will add up and the next person will not be digging for data in someone else's chat.
Stage conversion is the share of deals that moved from that stage to the next one over a chosen period. Overall pipeline conversion runs from the first stage to payment and explains little on its own: what you actually fix is a specific transition.
Ready-made reports already do this: pipeline analytics in Bitrix24 shows deal amounts by stage, their count, conversion by both amount and count, and how long deals stay at a stage, counting separately the deals that skipped it — per the vendor's description.
It is better to count the deals that entered the pipeline within one period. If a single report mixes deals of different ages, a long cycle blurs the picture: some of this month's enquiries have not reached payment yet and will be counted as losses that never happened.
Example An illustrative calculation: over a month 100 enquiries entered the pipeline, 60 reached qualification, 25 received a proposal, 10 paid. The transitions give 60, 42 and 40 percent, with overall conversion of 10. The narrowest point here is not payment but qualification: forty enquiries dropped out before the first real conversation.
Losses show up where deals end in a refusal and where they stand longer than the time limit. Both figures belong in the system, not in someone's memory.
The reason for a loss is a mandatory field with a list of options — free text does not add up into a report. The working list is short:
These reasons are then read together with the stage where the loss happened. "Price did not suit" at the proposal stage and "could not reach them" at the first stage call for different fixes: the first means reviewing the calculation and the way the offer is presented, the second means speed and channels of response.
A time limit is set for each stage separately: first contact within the working day, a proposal within three days, a reply on the contract within a week. A deal that stands longer lands in a separate list and in a task for the head of sales. Without a limit, "a stalled deal" remains a matter of opinion.
Usually the problem is not the system but the way stages are defined and used. Here is what breaks reporting fastest.
Checking this is easy: open the deal board and look at how many deals stand at each stage. If more than a third have gathered in one place, the problem is not the customers but the wording of the stage and its transition criterion.
A second pipeline appears when the company gets a second logic of the deal, not a second sales rep. Bitrix24 recommends assigning one pipeline to one department or business line — as stated in the documentation.
Splitting pipelines costs less than it seems and almost immediately gives the reports their meaning back: in each pipeline it is clear again how many deals entered and how many reached the money.
Inside a pipeline you automate transitions and reminders: a task after a new enquiry, a follow-up task on a silent customer, a status change after payment, a document from a template at the proposal stage. Scenarios and channel rules are covered in the article on CRM automation.
What you do not automate is anything that needs a human decision: a transition that depends on the customer's answer, a loss and its reason, a change in the deal value. Let the system move deals on its own and the pipeline quickly fills with deals that do not exist, and the report stops matching reality again.
Example At UzFranchise Expo the pipeline was short: registration in a Telegram bot, questions about the purpose of the visit, a personal QR ticket and a scan at the entrance. The single database gathered 7,500+ people with contacts and interests, 3,539 QR tickets were scanned at the entrance over two days, and a scan took 0.2 seconds. The details are on the exhibition case page.
A company head needs not every number but a few that show where the work is standing still. This set is taken weekly.
Money metrics such as customer acquisition cost cannot be calculated by a CRM until advertising spend reaches it: how to connect ads, enquiries and payments is covered in the article on end-to-end analytics. The reverse route works too — Yandex Metrica accepts an upload of CRM orders with their status and revenue and builds source and ROI reports from it, per the service documentation.
Syntra Systems starts with a review: how an enquiry travels from first contact to payment, where it is delayed and why some customers never reach a deal. Then we assemble the stages around your deal cycle, define mandatory fields and transition rules, connect the enquiry sources and set up reports on conversion and sales performance. Implementing a CRM with such a pipeline starts at $3,000; the scope is on the CRM systems page.
A pipeline can be configured both in a ready-made platform and in a system of your own — it depends on whether your stages and rules fit the platform's capabilities. When they do not and modifications cost more than development, the option of a system of your own is covered in the article on custom CRM development.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Usually six to eight. Fewer, and it is unclear where customers are lost; more, and deals start getting stuck at technical stages nobody moves. Every stage should answer the question of what the customer has already decided.
Better not: the same deal then enters a stage several times and conversion stops adding up. If negotiations step back, record it with a comment and a task and keep the stage as it is, or close the deal with a reason and open a new one.
Stages that depend on the customer's decision are set by the rep. Stages with an unambiguous signal — payment received, document signed, files uploaded — are moved by the system, so the report does not show deals paid a week ago and never moved on.
Set a time limit for each stage and pull everything beyond it into a separate list. Each such deal needs one of three outcomes: a next step with a date, a move to postponed, or closure with a reason. The list is reviewed at the weekly meeting.
Yes, if a repeat sale follows its own scenario and different timelines. Mixing it with new enquiries is a bad idea: a returning customer has no qualification stage and their deals are shorter, so in a shared pipeline they distort conversion and average duration.
If more than a third of all deals are sitting at one stage, the issue isn't clients — it's how that stage and its exit criteria are worded, since every manager reads them differently. It takes a minute to check: open the deals board and see where they're piling up.
