Lifecycle Stage Definitions Template
Four tests on every stage you already have, then exit criteria rewritten as evidence your buyer produced rather than work a rep logged.
Free download · No account needed
Everything published on lifecycle stages tells you to pick the stages, write entry and exit criteria for each, and get sign-off. That is the easy half and it is thoroughly covered. The hard half is finding out which of the stages already in your pipeline mean anything at all. Your stage history answers that, and it answers it with numbers rather than opinions. This pack runs the diagnosis first, then rewrites the definitions from whatever survives it.
Four tests decide it. How long records really sit in a stage, because a median dwell of eleven hours is a field update rather than a stage. Whether anything is ever filtered out, because a stage converting at ninety-eight percent has no boundary in it. What share of won deals skipped the stage entirely. And whether the conversion rate holds still across quarters, because a stage swinging twenty-four points between quarters is measuring your pipeline reviews rather than your buyer.
Then every exit criterion gets rewritten as something the buyer can be seen doing. Proposal Sent is the canonical failure: it turns on a rep attaching a document, so the stage advances on outbound activity and fills with deals nobody has answered. The register counts how many of your stages work that way, which is usually most of them. The definitions land beside a CRM field dictionary and your metric definitions, so one vocabulary survives into the reports.
What the pack does that a criteria worksheet does not
Runs the diagnosis before the definitions
Four tests on every stage you already have: real dwell, forward conversion, skip rate among won deals, and quarterly spread. The register carries a verdict per stage, so the rewrite starts from seven survivors rather than a blank nine-column grid.
Counts the stages that turn on rep activity
Every stage gets an observable-by value with two options, buyer evidenced or rep only. The headline number is how many of yours are rep only, and in the worked example it is five of nine.
Separates the rate from its stability
A conversion rate is only a forecast input if it holds still. Conversion by Stage carries the rate and its spread across four quarters, so a stage running 71% one quarter and 47% the next is disqualified on the spot.
Strips the events that were never buyer events
Bulk updates at an identical timestamp, import-sourced changes, non-owner edits and reopened losses all get counted and excluded before a single rate is quoted. In the worked example that is about 19% of all stage change events.
Finds the stuck deals your platform report cannot see
A separate sheet computes dwell for deals still sitting in a stage, ranks them by multiple of the stage's own 75th percentile, and names the last thing the buyer actually did. Eight deals, six of them dead, 542,000 of stated pipeline.
Writes the policy that keeps the definitions true
Who may move a deal, what evidence gets attached, what happens on a skip or a backward move, and when a stuck deal gets closed. Definitions decay without it, and the decay is what produced the nine stages in the first place.
How the pack runs
- 1
Send the export
The deal or opportunity export with stage history: dates entered and exited each stage, owner, amount, close date and outcome. Four quarters is ideal, two is workable.
- 2
Audit the history
River separates real buyer events from bulk updates, imports and non-owner edits, then quantifies what each pattern corrupts before any rate gets computed from it.
- 3
Test every stage
Dwell, forward conversion, skip rate among won deals and quarterly spread, one row per stage, ending in a keep, rewrite, merge or delete verdict.
- 4
Rewrite and publish
Each surviving stage gets an exit criterion the buyer can be seen meeting, plus the change policy and the stuck deal report that keep the register honest.
Frequently asked questions
Is this not just entry and exit criteria with extra steps?
The criteria are the last thing it writes. Most pipelines already have criteria and still have nine stages, two of which nothing passes through. The diagnosis is what tells you which stages to write criteria for, and it usually removes two before anything gets written.
What actually counts as buyer evidence?
Something in the record that the buyer caused. Accepting a diary invitation, returning a proposal with questions on scope, naming a procurement contact, raising a purchase order, having counsel send comments. Attaching a document, logging a call and marking a stage complete are all things a rep did. Post-sale, the same problem is signals that fire only after the customer decided.
Our pipeline is HubSpot's default. Does that change anything?
It sharpens the problem. The default pipeline ships seven deal stages carrying probabilities of 20, 40, 60, 80 and 90 percent, and the weighted amount in board view multiplies each stage total by them. Those are round numbers from a vendor, so replacing them with your measured rates is the whole exercise.
Our average time in stage looks fine. Why the separate stuck report?
Because the average cannot see the stuck deals. HubSpot's Latest time in stage property carries no value while a record is still in that stage, so any figure built on it is computed only over deals that already left. In the worked example none of the eight worst offenders appear in it.
Half our stage history is bulk updates. Is the data usable?
Yes, once the patterns are named and excluded rather than averaged in. The audit sheet counts each one and says what it corrupts, so the rates you publish come from a clean denominator. If the wider database is the problem, run a CRM audit diagnostic first. Merges corrupt it too, which survivorship rules prevent.
How many stages should we end up with?
However many pass the four tests, which is almost always fewer than you have. The worked example goes from nine to seven: one merges because nothing was filtered by it, one is deleted because 31% of won deals routed around it, and one becomes conditional on deal size.
We run two CRMs and they report different pipeline. Same fix?
Stage definitions are one of the four reasons those numbers disagree, so start here and then reconcile record by record with a HubSpot and Salesforce reconciliation. Aligning definitions across systems is pointless while one of them is still advancing deals on rep activity.
Find out which of your stages mean nothing
Send four quarters of stage history and get the register, the conversion sheet and the verdicts back.
Get the template