I remember the early SDR instinct clearly.
A buyer gets on the phone and says the sentence every rep wants to hear: "This is exactly what we need." The note goes into the CRM. The stage moves. Demo completed. Evaluation started. Proposal prep. The pipeline looks alive.
In the first month, that felt like a win. I probably would have Slacked my manager or the AE and said something like, "I think this one is real." That was the honest read at the time.
Everyone has been there. Over time, coaching helped me separate interest from movement. You start to catch the language, hear what is missing, and steer the conversation toward the evidence you actually need.
A buyer could like the idea, feel the pain, and still leave the call without a budget owner, a decision path, or any reason to do something next. That changed how I looked at the CRM. A stage was useful, but only after I could explain what had changed on the buyer's side.
The stakes are higher now. A stage change no longer just updates a report. It can trigger workflows, forecasts, handoffs, manager review, and follow-up sequences before anyone has checked whether the buyer actually moved.
A weak stage definition used to create reporting noise. Today, it creates operating noise.
Seller activity vs. buyer movement
Stages give the business a clean shape: discovery, evaluation, proposal, commit, closed won. The breakdown starts with that shape becoming a substitute for buyer movement.
Discovery, demo, and proposal work can all happen before the buyer owns the pain, builds consensus, or understands budget, timing, security, and procurement.
The stage changed. The deal did not.
The cost shows up in the systems attached to the stage: CRM configuration, funnel reporting, forecast categories, handoff rules, manager inspection, and AI-triggered workflows. The account has to reveal something that changes the commercial reality of the deal before the system treats the label as truth.
Today's GTM environment creates false positives faster. Outbound reach is broader, automation can manufacture follow-up motion, buyers can evaluate multiple SaaS platforms at once, and service providers often look interchangeable from the outside. A reply, demo request, or polite evaluation becomes noisy reporting once the system treats interest as progress.
Stage design starts to matter here. Not because the labels are sacred, but because each label gives the business permission to act differently.
MQL, SAL, SQL, discovery, evaluation, proposal, and commit are supposed to mark changes in buyer reality. In practice, they often become internal shorthand for seller motion. Marketing sees engagement. BDR sees a booked meeting. Sales sees a qualified conversation. RevOps sees a stage update. Leadership sees forecast movement.
The problem starts once those teams use the same label to mean different things. A stage that lacks shared meaning creates a false handoff: the record moved, but the business has not agreed on what became true.
The human-capacity question from the last article comes back into play at these turns. Not every stage needs more human touch. The important ones do: weak signal to sales attention, conversation to real problem, opportunity to buying path, and commit to buyer-owned action.
Buyer progress has receipts: confirmed pain, a business consequence, new people in the conversation, a visible decision process, named blockers, timing with a reason, and a next step that belongs to the buyer.
I wish I had understood that earlier. I used to see CRM stage design as a way to organize the seller's workflow. Now I see it as a way to make buyer evidence inspectable.
A usable stage contract needs four parts: entry criteria, exit criteria, a timestamp, and an inspectable receipt. The stage tells the business where the buyer is in the journey. Status tells the team what is happening inside that stage. Mixing those two together is how teams end up with clean-looking dashboards and unreliable pipeline.
| CRM stage | Seller's words | System-verifiable receipt |
|---|---|---|
| Discovery | "They have the problem and want to keep talking." | A buyer-owned next step is scheduled with the problem owner, and the cost of inaction is captured. |
| Evaluation | "They liked the demo and asked for more information." | New stakeholders join the process, or the buyer shares current-state requirements and success criteria. |
| Proposal | "Pricing is out and budget should not be an issue." | Explicit buyer confirmation of decision process, procurement steps, timeline, and commercial structure under review. |
| Commit | "This should close by the end of the month." | Active, dated engagement from legal, security, or procurement with an assigned internal owner on the buyer side. |
| Revive later | "They went quiet, but it could come back." | A documented reason for the delay, tied to a verifiable future operational trigger and monitored re-entry condition. |
Designing the evidence contract
A stage definition has to do more than describe the sales team's preferred sequence. It has to define what must be true before the forecast, handoff, manager review, or automated workflow treats the opportunity differently.
One way to look at it is a stage contract. The stage makes a claim, and the rest of the team needs to know what evidence supports it.
That contract has to be shared across the whole revenue system. "SQL" cannot mean accepted by sales in one meeting, qualified in conversation in another, ready for an AE in the dashboard, and likely to become pipeline in the forecast.
Shared language gives the stage teeth: buyer intent, mutual next action, required evidence, and the exact point where the record has earned the next operational step.
The mistake is turning that into a tax on the seller. Evidence can stay lightweight: no forty-five required fields, no paragraph of CRM narration after every call. That just results in low-quality data.
Fewer fields with higher stakes usually works better. Capture the meeting that actually happened. Parse the call transcript for risk flags. Track the exchange of a mutual action plan. Confirm buyer ownership of the next calendar event.
Better proof beats more data entry.
| Contract element | Operational objective |
|---|---|
| Entry criteria | What changed enough for this deal to enter the stage? |
| Exit criteria | What buyer evidence proves the stage is complete? |
| Required fields | Which fields must be trusted before the business acts on the stage? |
| Risk flags | Which missing signals, like a lack of multithreading, should trigger manager inspection? |
| Disqualification path | What happens to a deal with weak buyer evidence? |
| Handoff context | What does the next team need to know without re-discovering the deal? |
The manager review test
After the stages, fields, handoffs, and workflows are designed, one simple question still has to be answered: can the stage survive a five-minute manager inspection?
I do not mean a theatrical pipeline review. I mean a real inspection:
- Why is this deal in this stage?
- What changed with the buyer?
- Who owns the problem?
- What is the next buyer action?
- Which risk is still unresolved?
A rep who can only defend the stage with seller activity, such as a sent deck or scheduled follow-up, is describing formatting. Progress needs buyer-side change.
The fields will never be perfect. GTM systems are never that clean. The business still needs to know the difference between a stage that carries evidence and a stage that carries hope.
That is the manager review test: the stage has to explain what changed with the buyer, who owns the next action, and which risk still needs work.