3 min read
How to design pipelines and stages that survive contact with a sales team
The default pipeline describes how the software works, not how you sell. Here is how to design one people keep accurate, and why that matters more than any reporting feature.
Quick answer
How should CRM pipeline stages be designed?
Name each stage after an event that either happened or did not, such as "quote sent" rather than "warm". Give every stage a defined exit criterion, keep the count between five and seven, and split into separate pipelines only when the sequence of steps genuinely differs rather than when the product differs.
Pipelines are the object everyone configures in the first hour and nobody revisits, which is why so many CRMs produce reports their own leadership does not believe.
The underlying principle
A stage is a claim about reality that someone else could check.
If two people can look at the same opportunity and disagree about which stage it belongs in, the stage is badly defined. Everything downstream — forecasting, automation, reporting, conversion rates — inherits that ambiguity and amplifies it.
Why this is an automation problem, not just a reporting one
Stage transitions are the best automation triggers available, because a human deliberately moved the record. Time-based triggers fire against records that may have gone stale; a stage move is a statement of fact.
That also means a badly-defined stage produces badly-timed automation. If “quoted” means different things to different people, the follow-up sequence attached to it fires at inconsistent moments, and the sequence gets blamed rather than the stage.
More on the underlying object in pipeline stage.
The maintenance test
The real question is not whether the design is elegant. It is whether the pipeline will still be accurate in six months.
Accuracy survives when moving a record is trivial and obviously correct. It dies when the person has to think about which stage applies. Design for the second case and the first takes care of itself.
The steps, in order
- Step
Write down how you actually sell, in order
Before touching the CRM, describe the real sequence in plain sentences — who does what, in what order, and what has to be true before the next thing happens. Most bad pipelines come from designing in the software before the process was ever written down.
- Step
Convert each step into an event, not a feeling
"Interested" and "warm" are not stages, because two people will place the same deal differently and the report becomes fiction. "Survey booked", "quote sent" and "contract signed" are auditable. Anyone can look at a record and agree whether it belongs.
- Step
Define the exit criterion for every stage
For each stage, write the single condition that moves a record out of it. If you cannot state it, the stage is a label rather than a step and should be merged into its neighbour. This test alone removes most unnecessary stages.
- Step
Cut the count to between five and seven
Too few and everything piles into the middle stage and the pipeline reports nothing. Too many and nobody maintains it, so records rot wherever they were last touched. Five to seven is the range where the pipeline stays accurate without ceremony.
- Step
Decide what "lost" means and where it goes
A lost reason is the most valuable field in the CRM and the most commonly omitted. Define a short, closed list — price, timing, went elsewhere, no response, not qualified — rather than a free-text box that produces four hundred unique answers.
- Step
Split pipelines only on genuinely different sequences
Different products usually move through the same steps and belong in one pipeline separated by a field. Split only when the steps themselves differ — a new-business sale and a renewal are genuinely different sequences and deserve separate pipelines.
- Step
Design the custom fields alongside the stages
Each stage needs the data that makes its exit criterion checkable. Design them together, because fields added later are never populated retroactively and you lose the history permanently.
- Step
Attach automation to transitions, not to time
Stage transitions represent a human decision and are the most reliable trigger available. Automating on elapsed time instead produces sequences that fire against stale records. Wire the follow-up to "quote sent", not to "three days after creation".
- Step
Test with ten real historic deals
Take ten deals you closed and ten you lost, and walk each through the new pipeline. Any deal that does not fit cleanly is telling you something about the design. Fix it before anyone starts using it.
- Step
Write the one-page definition and keep it visible
Stage name, what it means, what moves a record out. One page. Without it, two people will diverge within a month and neither will know it happened.
Questions
Related questions
How many pipeline stages should we have?
Five to seven for most businesses. Below five the pipeline usually cannot distinguish meaningful progress and everything accumulates in one stage. Above seven, maintenance collapses and records stop being moved, which makes every report built on the pipeline unreliable.
Should we have separate pipelines per product?
Usually not. If the products move through the same sequence of steps, use one pipeline and a product field. Separate pipelines are justified when the steps genuinely differ — new business versus renewal, or a sale versus a delivery process that follows it.
What is the most common pipeline design mistake?
Stages named after how the salesperson feels rather than after something that happened. "Warm", "interested" and "nurturing" cannot be audited, so different people place identical deals differently, and the resulting forecast is not measuring anything real.
Should we track lost reasons?
Yes, and as a short closed list rather than free text. It is the field that tells you whether you have a pricing problem, a timing problem or a qualification problem, and each of those has a completely different fix. Free text produces data nobody can aggregate.
Services mentioned here
A CRM structured around how you actually sell
GoHighLevel CRM setup involves designing the pipelines and stages that model your sales process, defining custom fields and objects to capture the data you need, structuring tags and segmentation, importing and de-duplicating existing contacts, and configuring the reporting those decisions make possible.
Make a working system perform better
Optimisation analyses a functioning GoHighLevel system to find where performance is lost — which pipeline stages leak, which sequences underperform, where timing is wrong, which lead sources convert poorly — then makes targeted changes and measures whether they helped.
Hire a GoHighLevel expert to build the system properly
A GoHighLevel expert is a specialist who configures and automates the HighLevel platform for a business — building the CRM, pipelines, workflows, funnels, calendars and integrations so leads are captured, followed up and booked automatically. The work is system design and technical implementation inside the platform, not campaign management.