Stage Architecture

The Label Problem

Open your CRM. Look at your pipeline stages. They probably include some variation of:

• Discovery
• Demo/Presentation
• Proposal Sent
• Negotiation
• Closed Won/Lost

Now ask: what does it mean for a deal to be in "Negotiation"?

In most organizations, the answer is some version of "we sent a proposal and they are reviewing it" or "we are discussing terms." These descriptions refer to seller activities. The seller sent something. The seller is discussing.

What is the buyer doing?

This question exposes the flaw. "Negotiation" does not tell you whether the buyer is actively working toward a decision or whether your proposal is sitting unread in their inbox. It does not tell you whether they have internal approval to proceed or whether they are still socializing the idea. It does not tell you whether legal is engaged or whether the deal is stalled waiting for a budget cycle.

The stage is a label. It describes where the seller thinks the deal is. It provides no evidence about where the deal actually is.

Labels cannot predict. Evidence can.

The Seller-Centric Trap

Traditional stage definitions are seller-centric because sellers control what they can observe: their own activity.

A rep knows they completed discovery. They know they delivered a demo. They know they sent a proposal. These are facts within their control and visibility.

What they do not know, with certainty, is what the buyer is doing:

• Has the buyer shared your proposal with stakeholders?
• Has the buyer secured budget approval?
• Has the buyer scheduled a decision meeting?
• Has the buyer engaged procurement or legal?

Seller-centric stages assume that seller activity causes buyer progress. Discovery leads to demo leads to proposal leads to close. The pipeline flows because the seller pushes it forward.

This assumption is false.

Buyers do not progress because sellers complete activities. Buyers progress when their internal conditions align: pain is urgent, budget is available, stakeholders agree, alternatives are evaluated, risk is acceptable. These conditions operate on the buyer's timeline, not the seller's.

A seller can complete a perfect discovery, deliver a compelling demo, and send a polished proposal. If the buyer's internal conditions are not aligned, the deal does not progress. It sits in "Proposal Sent" for 90 days while the seller wonders what went wrong.

Seller-centric stages measure effort. Buyer-centric stages measure progress.

The Exit Criteria Protocol

Remotir's Exit Criteria Protocol requires that each pipeline stage has defined exit criteria based on buyer-verifiable actions. A deal cannot advance to the next stage until the buyer has taken a specific, observable action that demonstrates commitment.

The Design Principle

Each stage represents a buyer commitment threshold. As deals progress through stages, buyer commitment deepens. Early stages require low-stakes commitments (sharing information, attending meetings). Later stages require high-stakes commitments (engaging procurement, committing budget, scheduling decisions).

The Buyer Commitment Ladder:

Stage	Buyer Commitment Level
1	Information sharing
2	Time investment
3	Internal socialization
4	Resource commitment
5	Decision commitment

Each level requires the buyer to do something that costs them more than the previous level. Information is free. Time has opportunity cost. Socialization has political cost. Resources have budget cost. Decisions have career cost.

Buyers who are not progressing toward purchase do not climb the ladder. They stay at early stages, attending meetings and asking questions but never committing resources or timelines. Buyer-centric stages expose this stall. Seller-centric stages hide it.

Example Stage Architecture

Stage 1: Qualified

• Entry: Meets PAIN Threshold (Chapter 2)
• Exit criteria: Buyer has shared specific, quantified problem and confirmed willingness to evaluate solutions

Stage 2: Discovery Complete

• Entry: Passed Stage 1
• Exit criteria: Buyer has identified stakeholders who will be involved in evaluation; buyer has confirmed evaluation timeline

Stage 3: Solution Validated

• Entry: Passed Stage 2
• Exit criteria: Buyer has confirmed that solution addresses their stated problem; buyer has introduced seller to additional stakeholders or decision-makers

Stage 4: Business Case Accepted

• Entry: Passed Stage 3
• Exit criteria: Buyer has internal approval to proceed; budget is identified; decision-maker has verbally confirmed intent to move forward pending terms

Stage 5: Negotiation

• Entry: Passed Stage 4
• Exit criteria: Procurement or legal is engaged; specific terms are being discussed; decision meeting is scheduled

Stage 6: Commit

• Entry: Passed Stage 5
• Exit criteria: Verbal commitment received; contract is in signature process

The Evidence Requirement

Exit criteria must be documented, not asserted.

"Buyer confirmed solution addresses their problem" is not met because the rep feels it went well. It is met when there is evidence: an email from the buyer stating fit, meeting notes capturing the confirmation, a recording of the statement.

The documentation requirement prevents optimism from corrupting stages. A rep may believe the buyer is committed. The documentation requirement forces them to test that belief against evidence. If evidence does not exist, the exit criteria is not met.

Building Your Architecture

Stage architecture must be customized to your sales motion. A 30-day transactional sale has different stages than a 9-month enterprise engagement. The principles are consistent; the specifics vary.

Step 1: Map the Buyer Journey

Before defining stages, understand how your buyers actually buy.

Interview recent customers:

• What steps did they go through internally?
• When did they involve stakeholders?
• When did budget get approved?
• When did legal engage?
• What had to happen before they could commit?

Interview lost deals:

• Where did the process stall?
• What internal blockers emerged?
• What were they waiting for that never happened?

The buyer journey reveals the natural commitment points. Stages should align to these points, not to seller-convenient divisions.

Step 2: Define Exit Criteria for Each Stage

For each stage, specify:

1. What buyer action demonstrates this commitment level?
2. How will the action be verified?
3. What evidence must be documented?

The criteria must be specific enough that two different managers, looking at the same deal, would reach the same conclusion about whether criteria are met.

Vague: "Buyer is engaged."
Specific: "Buyer has scheduled follow-up meeting with economic buyer present."

Vague: "Proposal well received."
Specific: "Buyer has provided written confirmation that proposal addresses requirements."

Step 3: Implement Enforcement

Exit criteria without enforcement becomes suggestion. Enforcement requires:

CRM configuration: Stage advancement should trigger validation. If criteria fields are not completed, advancement should be blocked or flagged.

Manager inspection: Deal reviews should verify exit criteria documentation. "Why is this in Stage 4?" should be answered with evidence, not narrative.

Retroactive demotion: Deals found to be in stages without proper documentation should be demoted. This is uncomfortable but essential. A deal in Stage 5 without evidence belongs in Stage 3 until evidence exists.

Step 4: Calibrate Continuously

Stage definitions will need refinement. After 90 days, analyze:

• Are deals meeting exit criteria and then stalling in the next stage? Criteria may be too easy.
• Are deals sitting in stages unable to meet criteria? Criteria may be misaligned with buyer behavior.
• Are certain criteria consistently gamed or misinterpreted? Criteria may need clarification.

Stage architecture is infrastructure, not a one-time project. It requires ongoing maintenance as you learn how buyers actually behave.

The Probability Implication

When stages are defined by buyer commitment, stage-based probability becomes meaningful.

A deal in Stage 4 (Business Case Accepted) has a buyer who has secured internal approval and confirmed intent. This buyer is demonstrably more likely to close than a buyer in Stage 2 (Discovery Complete) who has only invested time.

Probability should be derived from historical conversion rates, not assigned arbitrarily.

After implementing buyer-centric stages, measure:

• What percentage of Stage 2 deals advance to Stage 3?
• What percentage of Stage 4 deals close?
• What is the win rate from each stage?

These historical rates become your probability weights. They are not guesses. They are measured conversion rates based on deals that met evidence-based exit criteria.

If Stage 4 has historically converted to Closed Won at 65%, a deal that enters Stage 4 should be weighted at 65%. This probability means something because Stage 4 means something.

Case Study: The Enterprise Rebuild

A Remotir client (enterprise software, $50M ARR, average deal size $250k) had forecast accuracy below 60%. Inspection revealed the problem was stage integrity.

The Diagnosis:

Stages were defined as:

• Stage 1: Initial Meeting
• Stage 2: Discovery
• Stage 3: Demo
• Stage 4: Proposal
• Stage 5: Negotiation
• Stage 6: Closed Won

All stages were seller activity. There were no exit criteria. A deal advanced when the rep advanced it.

Analysis of 50 "Stage 5" deals showed:

• 32% had no proposal actually sent
• 44% had no contact with procurement or legal
• 60% had no confirmed decision timeline
• 28% had no confirmed budget

"Stage 5" meant nothing. Deals were in negotiation according to the CRM but not according to the buyer.

The Rebuild:

New architecture with buyer-centric exit criteria:

• Stage 1: Qualified (PAIN Threshold met)
• Stage 2: Evaluation Confirmed (buyer has committed to evaluation with defined timeline and stakeholders)
• Stage 3: Solution Fit (buyer confirms solution addresses requirements; technical validation complete)
• Stage 4: Champion Committed (internal sponsor has agreed to advocate; business case documented)
• Stage 5: Authority Engaged (economic buyer has confirmed budget and intent; procurement/legal notified)
• Stage 6: Decision Pending (decision meeting scheduled; contract in review)
• Stage 7: Verbal Commit (verbal yes; signature process initiated)

Each stage required documented evidence. CRM enforced fields. Managers verified documentation in reviews.

The Results (6 months post-implementation):

• Forecast accuracy improved from 58% to 87%
• Average sales cycle shortened by 22 days (stalled deals identified earlier)
• Stage 5+ conversion rate increased from 41% to 68% (stage now meant something)
• Rep confidence increased (stages reflected reality, not hope)

The insight: The company did not have a forecasting problem. They had a stage definition problem. Fixing the architecture fixed the forecast.

Common Architecture Mistakes

Mistake 1: Too Many Stages

More stages create more overhead without more insight. If a deal spends 2 days in a stage before advancing, the stage is not providing useful signal.

Guideline: 5-7 stages for most B2B motions. Each stage should represent a meaningful buyer commitment threshold where deals might reasonably pause.

Mistake 2: Stages That Cannot Fail

Every stage should have meaningful attrition. If 95% of deals pass from Stage 2 to Stage 3, Stage 3 is not filtering anything. The exit criteria are too easy.

Guideline: Each stage should have 15-30% attrition (deals that fail or stall). This indicates the criteria are meaningful.

Mistake 3: Activity-Based Criteria

"Demo delivered" is not an exit criterion. It describes what the seller did. The buyer may have attended but not engaged. The buyer may have nodded politely and immediately disqualified you internally.

Guideline: Every criterion should answer "What did the buyer do?" not "What did we do?"

Mistake 4: Subjective Criteria

"Buyer seems committed" is not verifiable. Different reps will interpret "seems committed" differently. The stage becomes a vessel for optimism.

Guideline: Every criterion should be verifiable by a third party with access to documentation. "Email received from buyer confirming budget approval" is verifiable. "Buyer seemed positive about budget" is not.

Conclusion: Stages Are Contracts

A pipeline stage should be a contract between the seller and the organization.

When a rep advances a deal to Stage 4, they are asserting: "This buyer has taken the actions defined in Stage 4's exit criteria. I have documented evidence. You can rely on this stage when forecasting."

If stages are contracts, they carry weight. Misrepresenting stage is not a minor CRM error. It is a breach that corrupts downstream decisions.

The Exit Criteria Protocol creates accountability. Stages stop being opinions and start being evidence. Forecasts stop being aggregations of hope and start being calculations based on buyer behavior.

The architecture matters more than the methodology. A sophisticated forecasting process applied to meaningless stages produces sophisticated nonsense.

Build the architecture first. Forecasting accuracy follows.