You know the deal that looks alive but never seems to move. The AE wants momentum, the prospect sounds interested, and you keep doing “just one more” call, “just one more” integration check, and “just one more” follow-up email. Weeks later, you're still the person everyone expects to keep the evaluation warm, even though nobody can say what success would actually look like.
That's what missing entry and exit criteria does in PreSales. It turns a solution evaluation into unqualified technical support with a sales logo on it. The fix isn't more process for its own sake, it's a clear standard for when you start work, when you stop, and when you kill the deal instead of feeding it more SE time.
The POC That Drifted for Months
The worst part of a drifting POC isn't the workload, it's the ambiguity. You've already said yes, so nobody feels comfortable calling it off. The customer keeps asking for one more integration, the AE keeps framing it as “close,” and you're the one carrying the technical thread with no clean finish line.
Why these deals drift
When a POC starts without a shared gate, every new request feels reasonable. That's the trap. A vague evaluation can absorb discovery gaps, missing stakeholders, unclear success measures, and procurement surprises, all while still being labeled “active.”
The cleaner way to think about it is blunt. If the buyer can't name the problem, the decision path, and the proof they need, you're not running a POC, you're accepting open-ended technical work. A useful external reference on buying-intent qualification is how Captiwate qualifies buying intent, because it reinforces the same discipline, qualify before you spend scarce effort.
Practical rule: if you can't state the exit in one sentence, the POC shouldn't have started.
That's why strong entry exit criteria matter. They create a shared language for the AE, the SE, and the customer, so “yes” means something specific and “no” doesn't depend on mood, pressure, or hope.
The point isn't to become gatekeepers. The point is to stop acting like unstructured patience is a strategy.
What Entry and Exit Criteria Actually Mean
At the simplest level, entry criteria are the conditions that must be true before work begins. Exit criteria are the conditions that must be true before you call that work complete. That definition comes from engineering and quality disciplines, not from sales theater, and it's exactly why it works in PreSales.
NASA's guidance is explicit. Entry criteria are the activities and technical products that must be completed before a review begins, while exit criteria are the decisions and actions required before the review is complete, and the agency expects teams to tailor those criteria to the work at hand NASA entrance and exit criteria. ISTQB is just as direct, warning that starting without entry criteria can make work more difficult, time-consuming, costly, and risky, and that criteria should be defined against the objective rather than copied generically ISTQB guidance.
How that maps to PreSales
For you, the logic is straightforward. Before you commit SE capacity to discovery, a demo, a POC, or a pilot, the buyer should already have met the minimum readiness conditions. Before you close the activity, there should be evidence that the agreed outcome was met, not just that meetings happened.
That's why the framework is more than paperwork. It creates cause and effect. Incomplete discovery blocks premature solution design. Missing success metrics blocks a clean exit. You're replacing gut feel with an objective standard, which matters when sales pressure tries to turn every interested account into a technical project.
If you want a practical companion to that thinking, this guide on pre-call planning helps reinforce the same habit of preparing before you spend time. Good preparation and clear gates are the same muscle.
A strong criterion sounds observable. A weak one sounds aspirational. “Good discovery” means nothing, “documented business problem, named decision maker, and agreed evaluation date” gives you something you can verify.
Stage by Stage Criteria for Presales
Presales is not one stage with different labels. Discovery, demo, POC, and pilot each solve a different problem, so they need different gates. If you use the same checklist everywhere, you'll either over-control the easy stages or under-control the risky ones.
Criteria by stage
| Stage | Entry Criteria | Exit Criteria |
|---|---|---|
| Discovery | Named contact, known business problem, basic decision process, and a reason to talk | Problem and stakeholders are clear enough to decide whether a demo or deeper evaluation is justified |
| Demo | Discovery completed, use case confirmed, agreed audience, and fit questions identified | Buyer has seen relevant capability and can decide whether to move to validation |
| POC | Signed evaluation plan, success metrics, technical constraints, and named business owner | Predefined evidence is captured, or the evaluation is stopped for a documented reason |
| Pilot | POC complete, security and operational assumptions cleared, and business ownership confirmed | Business value is verified, stakeholders sign off, and the next step is agreed |
NASA's stage-gate thinking fits this well, because the work before a review begins is different from the work needed to finish the review NASA entrance and exit criteria. That's also why you should keep a separate reference for POC planning, like this POC success criteria template, instead of trying to improvise every time.
A demo is for fit. A POC is for technical validation. A pilot is for business validation before production. Mixing those up creates confusion fast, especially when the AE calls a pilot a POC because it sounds easier to get approved.
Operational rule: if the stage purpose changes, the criteria must change too.
For teams trying to identify ready-to-buy prospects, that stage discipline matters even more. A buyer who's curious is not the same as a buyer who's ready to commit SE time, and your gates should reflect that difference.
Readiness Failures vs Qualification Failures
The cleanest distinction in stage-gate thinking is between a readiness failure and a qualification failure. Cooper's model separates readiness checks from minimum business requirements, and that distinction is gold for SEs stage-gate model.
Why the difference changes your response
A readiness failure means key tasks or deliverables are missing, so the work should recycle to the previous stage. A missing discovery artifact, for example, is a reason to delay the demo, not to barrel ahead and hope the customer won't notice. A qualification failure means a required condition is missing, and that should kill the opportunity.
That line matters because it changes your behavior. Readiness failures ask for more preparation. Qualification failures ask for a clean stop. If the security requirement fails, if the economic buyer disappears, or if the business owner won't commit, you do not have a “technical issue,” you have a dead opportunity.
Cooper's model is useful here because it treats readiness as yes or no, and a “No” sends the project back instead of pretending it's fine stage-gate model. In PreSales, that means a missing stakeholder map delays a demo, while a missing business owner or knockout requirement ends the evaluation.
A missing artifact is a pause. A missing requirement is a stop.
Many SEs burn time here. They keep trying to “fix” a deal that should have been qualified out, usually because nobody defined the difference early enough. Use that distinction in your discovery call planning, and it gets much easier to protect your calendar and your pipeline quality discovery call guide.
Why Exit Discipline Matters More Than Entry
Entry criteria get attention because they feel protective. Exit criteria do the harder job, because they force a decision when people would rather keep talking. That's where a lot of SE time disappears.
A recent analysis of trading records found that traders' best possible exit points produced profit and loss results roughly 2–3 times larger than their actual realized results, while observed exit efficiency commonly fell between 35% and 55% trade exit strategy analysis. The numbers come from trading, not PreSales, so don't stretch them into a universal law. The lesson still transfers cleanly, because the quality of the start does not determine the quality of the finish.
What exit discipline looks like in practice
Exit triggers should be specific. Use them when the stated outcome is achieved, when a milestone fails, when a risk threshold is breached, when assumptions change materially, or when the decision window expires. In plain terms, that means you're not asking, “Do we like this account?” You're asking, “Does the expected value still justify continuing?”
That framing creates better operating data too. Once you track signal time, actual entry, initial stop, target, position size, partial exits, stop changes, and transaction costs, you can compare planned risk to realized outcomes. In PreSales terms, that translates into cleaner data on conversion, cycle time, resource consumption, and value realized.
Practical rule: an evaluation without an exit criterion is just a delay with better branding.
This is why vague criteria slow deals down more than clear ones. When nobody knows what ends the POC, every extra request stays alive. When the exit is written, the team can stop spending time on low-value work and move on to the deals that deserve attention.
How to Create and Enforce Your Criteria
Good criteria don't come from a template alone. They come from people who know the work, especially the SEs who have to live with the outcome. NASA recommends tailoring criteria to project size and complexity and involving the technical team in defining them NASA entrance and exit criteria, and that logic holds in PreSales too.
Write conditions you can actually verify
Use observable language. Don't write “strong discovery,” write “documented business problem with named decision maker and agreed decision date.” Don't write “successful POC,” write “business owner signed off on predefined KPIs and the next step is approved.”
A simple operating pattern helps:
- Define the gate with the AE and SE together. If sales and PreSales don't agree, the gate won't hold under pressure.
- Make the condition visible. Put the criteria where the team works, not in a document nobody opens.
- Use the gate in real decisions. If it doesn't affect start, stop, or progression, it isn't a gate.
- Review what worked and what didn't. Kill criteria that never matter, and tighten the ones that let bad deals through.
For teams that want a structured way to standardize this across deals, a sop maker can help document the mechanics, but the true value comes from enforcement, not formatting.
Keep criteria tied to the deal
Criteria should change with deal size, risk, and complexity. A small, low-risk opportunity does not need the same rigor as a strategic enterprise pilot. The wrong move is copying a generic checklist across every account and pretending that's discipline.
Use your criteria with the rest of your discovery workflow, including this discovery call guide and your internal handoff process. That's how you stop becoming unqualified technical support. You turn the technical win into a managed outcome, not a guess.
Bottom line: if the gate isn't written in terms the AE can defend and the buyer can understand, it won't survive contact with the deal.
PreSales Unleashed GmbH supports Solution Engineers and SE leaders through the Trusted Advisor Academy, with live practice, structured content, and deal-based application that helps teams build stronger discovery, demo, and POC habits. If you're tightening how your team defines and enforces entry and exit criteria, visit PreSales Unleashed GmbH and see how that kind of enablement fits into your operating rhythm.