Sales stage exit criteria: examples from published processes
Require customer evidence before a deal advances: what did the customer confirm, agree, test or sign, and where is it recorded? Use MEDDICC elements to specify the evidence needed at the gates between your stages.
A recap sent by a seller and a recap confirmed by a customer are different exit criteria. For each item in your stage definition, ask who must act and where that action is recorded. Keep necessary internal checks, and make the customer's confirmation explicit when the criterion is meant to show buying progress.
What are sales stage exit criteria?
Exit criteria are the conditions a deal must meet before it moves to the next stage.
Write four things for each stage, as Fleet's handbook does: a probability, a definition of one or two sentences, a timeline, and the exit criteria, "What's required to take place before moving this opportunity to the next stage." The timeline is how long a deal may stay in the stage before it is reviewed and possibly closed.
Sales stage exit criteria examples
GitLab's negotiating criteria distinguish preparing an agreement from the customer's agreement to its terms.
Its 5-Negotiating stage asks for both "Quote & Agreement ready to be routed for signature" and "Customer has agreed to business terms".
For Discovery, GitLab's commercial stages list a "Recap email sent to customer confirming pain points, key stakeholders, next steps, project timeline" and a "Scoping meeting scheduled". Neither line explicitly requires a customer reply or acceptance. Fleet's first stage requires the prospect to confirm the meeting, or a meaningful conversation to have taken place. Flexpa's go-to-market process ends Developing when the prospect completes the full testing flow, defined as successfully integrating with Flexpa and making a first API call. It counts a deal as won "once the first live mode request occurs."
| Company and stage | Criterion without explicit customer confirmation | Criterion naming customer action or agreement |
|---|---|---|
| GitLab, 3-Technical Evaluation | Criterion without explicit customer confirmation "ROI measures determined and validated" | Criterion naming customer action or agreement "Mutual agreement to move to proposal and identified next steps" |
| Fleet, Meeting set | Criterion without explicit customer confirmation "The prospect account has been qualified as being ICP." | Criterion naming customer action or agreement "Meeting date and time have been confirmed by the prospect OR a meaningful conversation has already taken place." |
| Fleet, Discovery | Criterion without explicit customer confirmation "Initial budget range discussed." | Criterion naming customer action or agreement "Mutual agreement that Fleet is worth further evaluation" |
| Fleet, Scope | Criterion without explicit customer confirmation "Economic Buyer identified in SFDC." | Criterion naming customer action or agreement Written proof, "in the form of an email", that the prospect agreed to the success criteria and timeline |
| Fleet, Justification | Criterion without explicit customer confirmation "Business value summarized and executive readout delivered." | Criterion naming customer action or agreement "Economic Buyer agrees to initiate commercial discussion/procurement process." |
| Flexpa, 2 Engaging and 3 Developing | Criterion without explicit customer confirmation "BANT confirmed" | Criterion naming customer action or agreement The prospect completes the full testing flow, defined as integrating with Flexpa and "making first API call" |
| PostHog, first call | Criterion without explicit customer confirmation "You have a plan to get their feedback on the product as soon as they use it" | Criterion naming customer action or agreement "They commit to using PostHog in a reasonable timeframe" |
How to tell a seller's task from customer evidence
Ask two questions of every item: who did it, and where is it recorded?
Distinguish the person who acts from the person who records it. A seller's CRM note can record a customer's confirmation; sending a recap does not establish that confirmation by itself. Every qualification element is an evidence claim. For a stage gate, name the customer action or agreement required and specify a record that lets the team check who confirmed what and when.
PostHog's handbook draws that line at the close: a deal is won "when the contract is signed by everyone", and "I've sent a DocuSign" is "NOT CLOSED EITHER". Fleet's Scope stage requires the success criteria to be "written down in a Google doc, email, etc. and recorded in SFDC", and also written proof by email that the prospect agreed to the criteria and timeline. The second requirement makes the customer's agreement explicit.
Proposed customer-evidence criteria for your own stages:
For GitLab's "Recap email sent to customer confirming pain points, key stakeholders, next steps, project timeline": require the customer to reply and confirm or correct the pain points and timeline.
For GitLab's "Scoping meeting scheduled": require the customer to accept the meeting and name who from their side will attend.
For Fleet's "Economic Buyer identified in SFDC.": require the economic buyer to confirm what they can approve for this purchase and which business outcome would justify it.
For GitLab's "ROI measures determined and validated": require the customer to confirm the figures the return on investment rests on.
Retain the seller work and internal checks needed to qualify the deal. Add the customer confirmation each exit criterion needs, rather than treating a completed task as sufficient evidence of readiness for the next stage.
MEDDICC elements as gates between sales stages
Place the MEDDICC evidence you need at the stage transition where it must be known.
MEDDICC, a widely used third-party framework, has no stages of its own. Decide which elements need supporting evidence before each transition. Keep an unresolved element visible rather than treating entry into a later stage as proof that the gap has been closed.
GitLab explicitly names MEDDPPICC in its stage criteria; Fleet names a stage after the economic buyer. GitLab lists "MEDDPPICC: Decision Criteria, Decision Process, Paper Process" among the exit criteria of Technical Evaluation. Fleet's "EB (economic buyer)" stage includes "The AE has spoken with EB OR strong champion confirms EB support for the project."
A field labelled "decision criteria documented" still needs an identified source. Fleet's written agreement to success criteria and a timeline confirms an evaluation arrangement. For your gate, establish which purchase criteria that evaluation tests and which other criteria remain to be confirmed. Use a question the right person at the customer can answer to define the missing evidence.
A sales stage exit criteria template
Start with one or two customer acts per stage, each tied to the MEDDICC element it gives evidence for and to the record that shows it.
This is a suggested starting point for a contract-led sale. Adapt the stage names and evidence thresholds to your own process. For each MEDDICC row, check what the evidence establishes and what remains unconfirmed. A close plan agreed with the customer is a mutual action plan, and each of its customer steps needs a named owner at the customer.
| To leave this stage | The customer has | MEDDICC element | Where it is recorded |
|---|---|---|---|
| Discovery | The customer has Described the problem in their own words and confirmed or corrected your recap | MEDDICC element Identify pain | Where it is recorded Their reply to the recap |
| Qualification | The customer has Presented the case internally and secured a decision-maker's agreement to the next step | MEDDICC element Champion | Where it is recorded The decision-maker's reply or the agreed step they take |
| Qualification | The customer has Confirmed the figures the business case will rest on | MEDDICC element Metrics | Where it is recorded Their email or the shared case |
| Scoping | The customer has Confirmed the purchase criteria, their priorities and how the evaluation will test the relevant requirements | MEDDICC element Decision criteria | Where it is recorded Their agreed criteria and evaluation plan |
| Evaluation | The customer has Confirmed the authority to approve this purchase and the business outcome needed for that approval | MEDDICC element Economic buyer | Where it is recorded The economic buyer's message or dated notes of their confirmation |
| Evaluation | The customer has Said which alternatives they are weighing, doing nothing included | MEDDICC element Competition | Where it is recorded Their words in the recap they confirmed |
| Proposal | The customer has Agreed a close plan with owners and dates, the approval and signature steps included | MEDDICC element Decision process and paper process | Where it is recorded The shared plan |
| Negotiation | The customer has Agreed the business and legal terms, then signed | MEDDICC element None: the deal closes | Where it is recorded The signed contract and any purchase order |
When a deal misses its exit criteria
Keep the deal in its stage until it meets the criteria, and set a deadline for deciding whether it should remain open.
Fleet gives its first stage two clocks: "30 Days from oppty creation to deliver the meeting." and "30 Days from meeting date to move the opportunity up or out." GitLab closes inactive new business deals in Discovery and Scoping automatically. Its inactivity warnings and closures are set by segment: days 45 and 90 for large and public sector deals, days 21 and 45 for mid-market, and days 7 and 15 for SMB.
Set your own early-stage limits around the customer steps you expect, rather than adopting either company's day counts. Decide what restarts the clock. GitLab counts stage progression, Command Plan entries and updated next steps as activity. For your own rule, specify what new customer commitment or completed step a CRM update must record. If the customer has agreed a future milestone, name its owner and date so that a planned wait can be distinguished from unexplained inactivity.
Sources
- Commercial Sales Opportunity Stages. The GitLab Handbook, September 2026.
- Go to Market. The GitLab Handbook, September 2026.
- Opportunity stages. Fleet handbook, undated.
- Go to market. Flexpa OS, undated.
- New business sales. PostHog Handbook, undated.
- MEDDIC, the way to reverse engineer a purchase decision (episode 105). The SaaSiest Podcast, 3 October 2023.
Facts last checked on 27 October 2026.