Build it with AI
Build a pipeline system around your stages, not someone else’s.
Define the stages, fields, views, and actions your sales process needs and turn them into working software.
Introduction
What a sales pipeline has to hold.
Most teams end up with a sales pipeline the same way: stages inherited from the CRM's default template, which the team silently reinterprets. A borrowed stage model works while everyone selling remembers what the stages were meant to mean. It fails at the first new hire, who reads the stage names literally and moves deals in ways that look wrong to everyone else and defensible to them.
Two reps mean different things by the same stage, so stage-conversion rates measure vocabulary rather than progress. There is no entry condition on any stage, no record of when a deal entered it, and no rule preventing a deal from moving forward while the thing the stage exists to verify has not happened.
What follows covers building a sales pipeline: the records it holds (opportunities, the stage each sits in, how long it has been there, owner, and expected close), the systems it reads (Salesforce and HubSpot), and what it does not fix.
The problem
Stages borrowed from a template nobody here designed.
Off-the-shelf pipelines encode a median sales motion, which is why enterprise and self-serve teams both find them slightly wrong in opposite directions. The usual response is to add stages until the model fits, which produces a fourteen-stage pipeline that nobody updates accurately.
The records are opportunities, the stage each sits in, how long it has been there, owner, and expected close, and the authoritative copy of most of them already lives in Salesforce or HubSpot. Forecast is built from the pipeline, the pipeline is built from stage positions, and stage positions are updated the night before the forecast call. The number is real; what it describes is the update ritual.
The cost is not the inconvenience: forecasting is built on a stage definition nobody agreed to.
You're likely here because
- Deals sit in one stage for months and nobody can say whether that is normal
- Two reps mean different things by the same stage, so stage-conversion rates measure vocabulary rather than progress.
- When it is wrong, forecasting is built on a stage definition nobody agreed to
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Stage board
- • Deal detail views
- • Forecast dashboard
Operated through Grow
- • Opportunity progression
- • Follow-up
- • Attribution
Systems it reads
- • Salesforce
- • HubSpot
- • Gmail
The record model
What a pipeline has to record.
- Stage and its entry condition
- The condition stored with the stage rather than in a policy document, so what the stage means travels with the deals that are in it when the definition later changes.
- Entry evidence
- What was true at the transition — the document received, the meeting held, the person confirmed. Without it a stage position is an assertion and the forecast inherits the assertion.
- Stage history including reversals
- Deals that go backwards are the most informative records in the pipeline and the most commonly overwritten. Keeping them is what makes dwell-time thresholds defensible.
- Dwell time
- Derived per stage per segment. A blended threshold across enterprise and self-serve produces noise in both directions and trains people to ignore the flag.
- Forecast category
- Separate from the stage, so a late-stage deal can be uncommitted. Every experienced sales leader makes this distinction informally and most pipelines refuse to model it.
- Segment
- Because thresholds, stage meanings, and normal cycle length all differ by it. A single pipeline model across genuinely different motions is two models sharing one board.
- Previous stage model version
- Retained for one cycle after a change, so historical reporting stays comparable through the redesign rather than resetting.
How it runs
From named stages to enforced transitions.
Step 01
Describe what a sales pipeline has to do
Write the entry condition for each stage as something observable — a document received, a meeting held, a named person confirmed. Stages defined by feeling are stages that cannot be enforced.
Step 02
Connect the systems of record
The CRM holds the deals, email and calendar hold the evidence that the entry conditions were met. Reading both is what lets a stage transition be verified rather than asserted.
Step 03
Build the operating surface
A stage board with entry conditions enforced, dwell time visible per deal, and the transitions that are not permitted simply unavailable rather than discouraged in a policy document.
Step 04
Start narrow
Enforce the entry condition on exactly one stage — usually the one before the forecast is committed — and leave the rest as they are. One enforced stage changes the forecast more than a redesign of all of them.
Step 05
Route the exceptions
A deal exceeding the normal dwell time for its stage surfaces with its history, so the question becomes whether it is stuck or mis-staged rather than whether anyone remembered to look.
Step 06
Measure stage-to-stage conversion, once the stages mean the same thing to everyone
Compare forecast accuracy at the same point in two consecutive cycles. Stage discipline shows up as a narrower gap between committed and closed, and it shows up before anything else does.
Implementation path
Changing a pipeline without stalling the quarter.
- 01
Get the sales team to write the entry condition for each stage independently, then compare. The stages where they disagree are the ones costing you forecast accuracy.
- 02
Baseline dwell time per stage and forecast accuracy for the last two closed cycles, before changing the model. Without it the redesign cannot be evaluated and will be argued about instead.
- 03
Change one stage at a time and let a full cycle pass. Redesigning the whole pipeline mid-quarter produces a quarter of data nobody trusts.
- 04
Keep the old stage on the record alongside the new one for one cycle, so historical reporting stays comparable through the change.
- 05
Build the narrowest useful version first: stages named for what has demonstrably happened, with an entry condition written down for each.
- 06
Getting each seller to write the entry conditions independently and comparing takes one session and produces the specification. The build is small; the sequencing is what matters — one stage changed at a time, a full cycle between changes, and the previous stage retained alongside. Expect a quarter before forecast accuracy is comparable, because that is how long it takes for a cycle to complete under the new definitions.
- 07
Once one stage is enforced and the forecast gap has narrowed, add per-segment dwell thresholds derived from your own closed history rather than from a round number. Win-loss reasons attached to the exit transition come next, and they are only worth collecting if somebody reviews them monthly.
Controls
Controls that matter.
Control 01
Stage entry conditions enforced by the system, so advancing a deal requires the evidence rather than the intention
Control 02
Stage change history retained per deal, including moves backwards, which are the most informative and the most often overwritten
Control 03
Forecast categories separated from stages, so an optimistic stage position cannot silently become a committed number
Examples
Three arguments the pipeline settles.
The deal that was at Proposal for five months
Dwell time as a visible property rather than a report nobody runs turns this from a discovery at the quarterly review into a flag in week three, when the deal was still recoverable.
The new rep’s first pipeline review
Written entry conditions mean the stage model can be learned from the system rather than absorbed from watching colleagues, which is the only version that scales past the founding team.
The quarter-end commit
Separating forecast category from stage position means a deal can sit at a late stage without being committed, which is a distinction every experienced sales leader makes informally and most pipelines refuse to model.
How it goes wrong
Three ways a pipeline redesign fails.
The whole pipeline is redesigned mid-quarter, and the resulting quarter of data is unusable for comparison.
Change one stage, let a full cycle pass, then change the next. A pipeline redesign is a measurement instrument change, and changing every calibration at once means you cannot tell what improved.
Stages are added until there are eleven, because each edge case seemed to need its own.
Fold anything without a verifiable entry condition back into its neighbour. Eleven stages produce precise-looking data that nobody maintains accurately, which is a worse input to a forecast than four honest ones.
Enforcement is introduced while the compensation plan still pays on pipeline created.
Sequence the plan change first or accept that the incentive wins. This is not a system problem and no amount of enforcement resolves it — people optimise what they are paid for, visibly and rationally.
Limitations and considerations
What a pipeline model cannot fix.
- Enforcing stages makes the pipeline smaller before it makes the forecast better. Plan for a visible drop in reported pipeline value in the first cycle and explain it before it happens.
- A pipeline model cannot distinguish a stalled deal from a long sales cycle. Dwell-time thresholds need to be set per segment, and setting them from a blended average produces noise in both directions.
- If the compensation plan pays on pipeline created rather than closed, stage enforcement fights the incentive and the incentive usually wins. That is a plan problem, not a system problem.
- If the stages are fine and the problem is that nobody updates them, this is an activity capture problem and a redesign will not touch it. If the sales cycle is short enough that deals close in the week they open, stage discipline buys very little and a simple won-lost record is proportionate.
- Connector coverage varies: Salesforce, HubSpot, Gmail are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a sales pipeline with AI: common questions.
How many stages should a pipeline have?
Few enough that each has an entry condition somebody can verify without asking, which in practice lands most teams between four and six. The count matters much less than whether each one is enforceable — a four-stage pipeline with vague stages is worse than a seven-stage one with sharp ones.
Can we keep using our CRM for this?
Often yes for the records, with the enforcement and dwell-time views built on top and reading through a connector. The reason to build rather than configure is usually that the entry conditions need evidence from email or calendar that the CRM stage engine cannot see.
What about deals that skip stages?
Model it explicitly if it happens routinely — an inbound deal arriving pre-qualified is a real pattern, not a violation. What causes trouble is skipping treated as an exception in policy and as a norm in practice.
Will the reps accept enforcement?
They accept it in proportion to whether the entry conditions are ones they helped write and can satisfy without extra data entry. Enforcement built on conditions the system can observe from email and calendar reads as removing work; enforcement built on new required fields reads as adding it.
What should the first version contain?
Stages named for what has demonstrably happened, with an entry condition written down for each. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure stage-to-stage conversion, once the stages mean the same thing to everyone against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a sales pipeline around the process you actually run.
Enforce the entry condition on one stage, let a full cycle pass, and judge the model on forecast accuracy rather than on how tidy the board looks.