How to define Opportunity stages

An Opportunity stage should tell you what has happened in one potential purchase. When it only mirrors a rep's confidence, pipeline and stage-aging reports become a running opinion poll. This page gives you a way to define stages that a buyer, manager, finance partner, and downstream system can all inspect: required evidence, the date that evidence occurred, who owns the next move, and what can happen next.

The goal is not a universal sales process. It is a stage contract your business can explain and maintain.

A stage is one transaction's current position

An Opportunity stage (or Deal stage in HubSpot) describes where one commercial transaction is in its sales process. A company can have more than one transaction at the same time. Each needs its own evidence and history.

Keep a stage separate from the other useful facts attached to the deal:

Dimension	Question it answers	Example
Opportunity or Deal stage	What evidence exists for this transaction now?	Solution review complete
Person lifecycle	What is this person's relationship with us?	Priya is Sales-ready
Account lifecycle	What is the company's commercial relationship with us?	Acme is a Prospect
Work status	What work is someone doing next?	Legal review is waiting on the customer
Forecast category	How should this deal roll up for a forecast?	Commit
Probability	What probability does the business assign to this stage or deal?	60%
Sales methodology	Which qualification framework or coaching view applies?	Required discovery fields are incomplete
Rep confidence	How does the seller feel about the outcome?	Seller calls the deal likely

Those dimensions can influence one another. They should not overwrite one another. A high-confidence rep may still be missing the evidence for a later stage. A deal can move to Closed won while the Account waits for the separately defined customer activation event. Priya can leave Acme without changing the state of an existing transaction.

Start with the record model in CRM entities. Use the person lifecycle and Account lifecycle pages to define those separate dimensions before you build rollups or automation around a stage.

Write a contract before you name the stages

Stage names are useful labels. The contract is the operating rule behind the label. For every stage, write down the same fields before configuring a picklist, pipeline, or report.

Contract field	What to document
Meaning	What is true about this transaction while it is in the stage
Entry evidence	The observable buyer or seller event required to enter
Entry milestone	The event date reporting will use, plus first-entry, latest-entry, or history behavior
Current owner	Who is accountable for moving the transaction forward or closing it out
Valid exits	The next stages, closed outcomes, regression paths, or review path that make sense
Required context	Information that must exist before the transition, such as buyer need, solution scope, or approval record
Closed reason	The reason, evidence, and owner required when the deal is won or lost
Re-entry or regression	What permits a deal to reopen or move backward, and what history must remain
Reporting treatment	Included population, exclusions, and the date each report uses
Exceptions	Missing evidence, duplicate deals, changed scope, or disputed stage and who reviews it

The evidence should say what occurred, not what somebody hopes will occur. "Champion likes us" might be useful context. It is not enough on its own to prove that a solution review happened, commercial terms were exchanged, or a buyer approved the purchase. Keep the useful context. Give it its own field or work item.

Milestone dates need names and semantics

Current stage tells you where the transaction sits today. A stage milestone tells you when a reporting-significant event occurred. Those are different jobs.

For each stage, decide whether you need:

• the first time the deal entered it;
• the latest time it entered it;
• every entry and exit; or
• a deliberate business event date that is related to the stage but is not the same thing.

Do not use a generic record-modified timestamp as a substitute. An unrelated note, integration write, or owner update can change it. That creates false stage-age and conversion reporting.

GTM Lab: Acme Manufacturing's new-business deal

The GTM Lab is a fictional B2B software company. Acme Manufacturing is a prospective customer, Priya Shah is the main contact, and the new-business Opportunity below is one potential purchase. These labels and rules are fictional working choices, not a stage taxonomy to copy.

Worked stage	Required entry evidence	Owner and milestone	Valid exits
Discovery in progress	A seller has opened a transaction after the documented problem, buying group, and next conversation are recorded.	Account Executive records discovery_started_at.	Solution review complete, Closed lost, or review.
Solution review complete	The buyer and seller have reviewed the agreed problem and the proposed approach. Notes identify the attendees, open gaps, and next decision.	Account Executive records solution_reviewed_at.	Commercial review, back to Discovery in progress if scope changes, Closed lost, or review.
Commercial review	The agreed commercial terms or proposal were shared with the defined buyer-side reviewer.	Account Executive records commercial_reviewed_at.	Closed won, Closed lost, back to Solution review complete if the solution changes, or review.
Closed won	The business's approved commercial completion event is recorded. For this example, it is an executed agreement, not a verbal indication.	Deal desk records closed_won_at, approved amount, and required completion evidence.	Reopen only through the documented exception path.
Closed lost	The seller records the loss evidence and an approved loss reason.	Account Executive records closed_lost_at, loss reason, and next permitted follow-up.	Reopen only when new evidence meets the re-entry rule.

Priya can become Sales-ready before Acme's new-business deal reaches commercial review. Acme can remain a Prospect until the separate Account lifecycle contract says a customer relationship has begun. A task such as "send security questionnaire" is work status. It may be required context for a stage transition, but it is not a stage itself.

The trace: confidence is not evidence

Fictional attempt one. The Acme account executive wants to move the deal from Discovery in progress to Solution review complete because Priya sounded positive on a call. The contract rejects the move. No buyer-and-seller solution review is recorded, and the open gaps and next decision are missing. The deal stays where it is. The work status can still say that the review needs to be scheduled.

Fictional attempt two. Priya and the buying group complete the review. The seller records attendees, the agreed problem, the proposed approach, open gaps, and the next decision. The deal moves to Solution review complete, and the system records solution_reviewed_at. Pipeline and stage-velocity reporting now have an event they can explain.

That is the distinction to protect. A rep's view is useful input. The stage states the agreed transaction evidence.

Salesforce: useful mechanics, not your stage design

Salesforce makes Opportunity Stage required and lets administrators define it. Its Opportunity Fields documentation also documents that stage maps to Forecast Category and affects Probability, with documented override behavior. Those relationships make stage design consequential; they do not tell you which stage names or evidence rules to use.

Salesforce also records Opportunity History for changes to Amount, Probability, Stage, and Close Date, including the actor and change details. Review the current Opportunity History documentation when deciding what native history can answer and what dedicated milestone field you still need.

Stage-to-forecast-category mappings are configurable. Read Salesforce's current stage-to-forecast-category mapping guidance and forecast-category customization documentation before using a stage as a forecast promise. Forecast category and rep confidence can be inputs to a forecast process without becoming the definition of a sales stage.

Different sales processes and record types can expose different stage and picklist choices. Salesforce documents that configuration in its record-type business-process guidance. Use it when different motions genuinely need different contracts. Do not use it to hide one unclear process behind several picklists.

HubSpot: useful mechanics, not your stage design

HubSpot lets teams configure Deal pipeline stages and probabilities. Its pipeline documentation describes Won and Lost as closed categories. Your team still owns the evidence that permits a stage transition, the loss-reason taxonomy, and the reporting definition.

HubSpot's default Deal properties include closed-won and closed-lost reason properties. See the current default Deal properties documentation. Your loss-reason taxonomy, requiredness, and reporting meaning are operating choices. A blank closed-lost reason is not an insight.

Pipeline settings can require conditional properties when someone manually creates a record or moves it to a stage. That UI control does not establish the same enforcement for every import, workflow, integration, or API update. Treat it as one part of the control set, then check each path that can write a Deal.

HubSpot's stage calculated properties documentation describes latest-time, cumulative-time, re-entry, and reopening analysis. Pick the property or custom milestone that matches the reporting question. A cumulative time figure cannot tell you the same story as first entry, and neither can replace a defined closed reason.

Opportunity stage contract template

Copy this into the Opportunity section of your Business Truth Map. Fill it out with the people who own sales, finance, reporting, and the systems that write the record.

Field	Fill in for each Opportunity or Deal stage
Stable ID and visible label	The internal identifier and the name people see
Plain-language meaning	What is true about this transaction in this stage
Entry evidence	Required event, record, attendee, document, or reviewed decision
Prohibited shortcut	Signals that are useful context but cannot advance the stage alone
Current owner	Accountable person or team while the deal is here
Stage milestone	Event date, writer, history semantics, and reporting use
Required context	Fields or attachments needed before the transition
Valid exits	Forward movement, regression, closure, or exception path
Closed-reason rule	Allowed reason, required evidence, owner, and follow-up treatment
Re-entry rule	What new evidence can reopen a closed deal and what history remains
Forecast and probability mapping	Any mapping or override rule, kept separate from the stage definition
Reporting treatment	Population, exclusions, conversion definition, and stage-aging logic
Exceptions and review	Duplicates, changed scope, missing evidence, dispute owner, and review date

Wrong choices that make pipeline hard to trust

Wrong choice	What breaks	Better rule
Advance a stage because the seller is confident	Pipeline appears further along than the buyer or seller evidence supports	Define observable evidence for every stage and keep confidence separate
Treat forecast category as the stage	Forecast rollups obscure what actually happened in the transaction	Map stage to forecast deliberately, then document the two dimensions separately
Make a task list the sales process	Work completion gets confused with commercial progress	Track work status separately and state which completed work is required context for a transition
Use a generic modified timestamp for stage age	Unrelated updates rewrite the clock	Use stage history or a named milestone date with explicit semantics
Mark every closed deal as final forever	Legitimate re-engagement disappears or gets counted as a new deal without explanation	Define reopen evidence, history preservation, and reporting treatment
Require fields in one screen and assume every writer obeys	Imports, workflows, integrations, or APIs can create incomplete transitions	Inventory every write path and add validation where the platform control does not apply
Make Closed lost a graveyard	Loss patterns, follow-up eligibility, and future re-entry cannot be analyzed	Require a maintained loss reason, evidence, owner, and follow-up rule

Opportunity stage audit

Run this review before making a stage drive routing, forecast, pipeline, compensation, or AI context.

• Every stage describes evidence about one transaction, with a plain-language meaning, entry evidence, owner, milestone date, valid exits, and reporting use.
• Person lifecycle, Account lifecycle, work status, forecast category, probability, methodology, and rep confidence remain separately modeled.
• Each milestone date has a named writer and first-entry, latest-entry, or transition-history semantics that match a real report.
• Closed-won and closed-lost conditions, reasons, required evidence, and owner are documented.
• Regression, reopening, duplicate deals, changed scope, and disputed stages have an exception path that preserves history.
• Salesforce stage, probability, forecast mapping, Close Date, history, record type, and sales-process configuration have been checked against the current setup.
• HubSpot pipeline-stage, probability, conditional-property, closed-reason, and stage-calculation behavior have been checked across every path that can write a Deal.
• Pipeline, conversion, and stage-aging reports name their population, exclusions, stage predicate, and milestone date.
• Sales, Finance, Operations, and reporting owners have reviewed the contract and assigned a review date for changes.

Once the contract exists, put its field meaning, authority, writer, freshness, and allowed use in a field dictionary. The context-layer trace shows why a downstream CRM AI system needs an executable definition of terms such as qualified pipeline, stage predicate, and exclusions. A label alone gives it too much room to guess. The context-layer rule schema shows how to encode those definitions after the business contract is approved.