Quick answer: A CRM stage should change only when a named piece of evidence exists. Write one entry rule, one exit rule, one owner and one next action for each stage. If a deal is “Proposal” because someone feels proposal-ish, the pipeline is a mood board, not an operating system.
- Free CRM stage definition worksheet
- Keep deal stage, lead status and lifecycle stage separate
- Give every stage six parts
- Worked example: move a deal on evidence
- Treat stalled, paused and backward moves deliberately
- Do not confuse stage probability with a promise
- Roll out the definitions without rewriting history
- Run six acceptance tests
- Copyable stage-definition record
- Useful detail: A required field is a gate, not evidence of a true answer
- Sources and editorial basis
Free CRM stage definition worksheet
Define entry evidence, exit evidence and exception routes. Use the fictional example and six tests to check whether two colleagues would stage the same deal consistently.
Download the free CRM worksheet pack (ZIP)
No signup. Three editable plain-text worksheets. Unzip the pack and open 03-crm-stage-definition-worksheet.txt in any text editor, or copy it into your shared document. Includes a blank record, fictional example and review checks. Version 1.0 · September 30, 2026.
Jump to: Stage vs status · Minimum definition · Worked example · Stalled and backward · Rollout · Copyable record
Use a stage that describes a real business state.
Require evidence before moving the record.
Assign the next action, owner and due date.
Test exceptions, reversals and closed reasons.
Keep deal stage, lead status and lifecycle stage separate
A deal stage describes where a specific piece of potential work sits in the selling process. A lead status usually describes the team’s current follow-up state for a person or lead. A lifecycle stage is a broader relationship label such as lead, opportunity or customer.
Those labels can coexist. One customer may have an old closed-won project, a new open proposal and a contact who is temporarily unresponsive. Trying to squeeze all three facts into one dropdown creates a very tidy field and a very untidy business.
HubSpot’s current documentation makes similar distinctions: pipelines contain ordered stages; its lifecycle-stage documentation describes Lead Status as sub-stages within the Sales Qualified Lead lifecycle stage. Exact terminology varies by product, so document the business meaning rather than copying a vendor label and hoping it brings instructions with it.
| Field | Question answered | Example | Do not use it for |
|---|---|---|---|
| Deal stage | What evidence exists for this opportunity? | Proposal sent | The contact’s whole relationship |
| Lead status | What is the follow-up state? | Attempted contact | Revenue forecasting |
| Lifecycle stage | What is the broader relationship? | Customer | The next task on one deal |
Give every stage six parts
A stage name is not a definition. For each open stage, write:
- Business meaning: the state the stage represents.
- Entry evidence: what must be true before a record enters.
- Exit evidence: what must be true before it advances.
- Required fields: the small set needed for the next decision.
- Owner and next action: who does what, by when.
- Exception route: what to do when the buyer pauses, declines or moves backward.
Put these definitions in the CRM data dictionary. Keep the evidence observable. “Good fit” is an opinion; “service needed, decision contact identified and target start month recorded” can be checked.
Do not make every field compulsory at the first stage. A new enquiry may not know its budget, and inventing £10,000 so the record can move is not data quality. Require information only when the next decision genuinely depends on it, and allow unknown when uncertainty is a real state.
| Stage | Entry evidence | Exit evidence | Next action | Exception |
|---|---|---|---|---|
| New enquiry | Valid contact and stated request | Fit check completed | Review and reply | Spam, duplicate or invalid reason |
| Qualified | Problem, fit and decision path understood | Scope and proposal inputs agreed | Prepare scope | Nurture or close-lost with reason |
| Proposal | Dated proposal sent to decision contact | Buyer confirms decision step and date | Follow up on agreed date | Revise scope or return to Qualified |
| Decision | Commercial decision is active | Accepted or declined evidence recorded | Resolve final question | Pause with review date |
| Closed won | Acceptance under the team’s policy | Not applicable | Handover to delivery | Correct if acceptance was recorded in error |
| Closed lost | Decline, no-decision rule or disqualification met | Not applicable | Record reason and permitted follow-up | Create or reopen only with new evidence |
Worked example: move a deal on evidence
Imagine a fictional three-person IT consultancy. A local firm asks about moving email and files to a managed workspace. The enquiry is valid, so it enters New enquiry. It does not jump to Qualified merely because the message sounds enthusiastic. Enthusiasm is lovely; it is not an exit criterion.
During a call, the consultancy confirms the systems involved, approximate user count, target month and decision participants. The record moves to Qualified. After both sides agree what the proposal should cover, the team prepares and sends a dated proposal to the named decision contact. It moves to Proposal, with a follow-up date and owner.
The buyer then asks for a smaller first phase. The team does not keep the deal in Proposal while silently rewriting the scope. It returns the record to Qualified, notes why and prepares the revised scope. That backward move is useful evidence, not a tiny administrative defeat.
When the buyer accepts under the consultancy’s stated acceptance policy, the deal becomes Closed won and triggers delivery handover. If the buyer declines, it becomes Closed lost with a controlled reason such as price, timing, fit, competitor or no decision. Free-text notes can add context, but a controlled reason supports consistent review.
Treat stalled, paused and backward moves deliberately
“Stalled” is often a condition, not a sales stage. If a proposal has no activity for 21 days, show a warning or review view while keeping the last evidenced stage. Otherwise the pipeline loses the answer to “what was the last real business state?”
Use a separate paused state only when it changes how the team works and has all three of these:
- a reason, such as budget cycle or internal project delay;
- a named owner; and
- a review date or trigger.
Allow backward movement when evidence changes. Record the previous stage, reason, operator and date where the CRM supports history. Salesforce’s current Path guidance, for example, describes stage duration across repeated visits to a stage; product reporting behaviour should be verified before you use duration as a performance measure.
Do not reopen a lost deal simply because an automated email was opened. Create or reopen an opportunity when there is new commercial evidence, then keep the original loss reason and dates available for review.
Do not confuse stage probability with a promise
Some CRMs attach win probabilities to deal stages. HubSpot’s current documentation says deal probability can be updated automatically from the win probability configured for a pipeline stage, unless it is manually edited. That is product behaviour, not proof that every deal in the stage has that exact chance of closing.
If the team uses weighted pipeline, document whether probability is stage-based, manually assessed or calculated another way. Do not compare those methods as if they were the same. First make stage entry consistent; then use the pipeline metrics guide to report counts, conversion and open work with clear denominators.
Roll out the definitions without rewriting history
- Inventory current stages. Export or save a dated snapshot of open records and stage values.
- Draft the six-part definition. Test it against ten recent records, including a loss, a pause and a backward move.
- Map old to new. Mark one-to-one, split, combined and no-equivalent mappings. Do not guess when the source lacks evidence.
- Pilot with real users. Ask two people to stage the same sample records independently and compare differences.
- Configure carefully. Check permissions, required fields, automation, reports and integrations before changing production stages.
- Migrate open work. Use the CRM migration checklist, preserve unknowns and keep a rollback record.
- Review after one cycle. Inspect disputes, backward moves, records without next actions and automation failures.
Official CRM features may enforce required fields, restrict movement or trigger automation, and availability can depend on the product and plan. Start with the operating definition. Automation should enforce a rule the team understands, not turn a fuzzy rule into a faster fuzzy rule.
Run six acceptance tests
- Same evidence: two users choose the same stage for the same record.
- Missing evidence: a record cannot advance merely because the seller wants it out of the column.
- Backward move: the reason and previous state remain traceable.
- Pause: a paused record has a reason, owner and review date.
- Closure: won and lost each require the team’s defined evidence and reason fields.
- Automation: stage-triggered tasks and reports use the new definitions without creating duplicates.
Record pass, fail and not tested separately. If only an administrator can complete the workflow, the test has not proved that ordinary users can run it.
Copyable stage-definition record
Business meaning:
Entry evidence:
Exit evidence:
Required fields and allowed unknowns:
Owner:
Next action and due-date rule:
Pause or backward-move route:
Closed reason or handover:
Automation and report dependencies:
Example that belongs here:
Example that does not:
Definition owner and review date:
Useful detail: A required field is a gate, not evidence of a true answer
HubSpot conditional stage logic can require properties when a user manually creates or moves a record into a stage.
A gate prevents a blank value in that route; it does not establish that the evidence is accurate or that every integration follows the same route. Include those boundaries in the stage test.
Try this:
- Try the manual move with the required value blank.
- Try the intended import or integration route separately.
- Review one populated value against its underlying evidence before accepting the gate.
Source: HubSpot: conditional pipeline stage properties. Checked October 3, 2026. The practical check is a PSL suggestion.
Sources and editorial basis
Primary references checked September 30, 2026: HubSpot’s pipeline setup documentation, lifecycle-stage documentation and default deal properties; Salesforce’s Path overview and Path considerations. Product terminology, permissions, automation and plan availability can change; verify them in the intended account.
The stage definitions, evidence model, fictional example, rollout steps and acceptance tests are Practical SaaS Lab editorial proposals, not measured customer results or a guarantee of forecasting accuracy.
