What are success criteria? How to define them for a POC or evaluation (with template)
OpineSuccess criteria are the specific, measurable conditions a buyer and vendor agree on before a proof of concept (POC) or evaluation starts. Together, they establish whether the product passed.
If you’ve watched an evaluation end with “we liked it, but we need to think about it,” you’ve seen what happens without clear criteria: tests nobody wrote down, measured against a bar nobody agreed on, with no date for a decision. Predetermined success criteria turn that conversation into a scorecard both sides can read and act on.
During a POC, success criteria judge whether a project delivered. In a sales evaluation, they judge whether a product earned the deal. This article focuses on the second: turning successful tests into signed contracts.
Success criteria: definition
| Term | Success criteria, also called evaluation criteria, proof of concept (POC) or proof of value (POV) acceptance criteria, or exit criteria |
| Definition | The measurable conditions a product must meet during an evaluation to prove it satisfies the buyer’s requirements |
| Who writes them | The sales engineer (SE) drafts, the buyer’s technical owners edit, and the economic buyer signs off |
| When they are determined | Before the evaluation starts, at kickoff at the latest |
| Who scores them | Both sides, separately, so any misalignment surfaces before the readout |
How do you define success criteria?
- Start from the business outcome. Ask what the buyer needs to be true in six months, then work back to what the evaluation has to prove.
- Write each criterion as a pass/fail statement. “Engineers sign in through the company’s existing SSO provider” can be tested. “Easy to use” can’t.
- Name the measurement. Say how the criterion will be checked and with what data: a test run, a security review, a timed task.
- Mark each one Must-Have or Nice-to-Have. A missed Nice-to-Have should never sink a deal, and a missed Must-Have should never be glossed over. Your Must-Haves double as the buyer’s kill criteria, so write them that way. If a Must-Have fails or stalls mid-evaluation, act immediately: pivot the test configuration, escalate for an engineering fix, or stop the POC early to preserve team resources.
- Give each criterion a buyer-side owner. The person who will rate it is the person whose opinion decides it.
- Set the decision date and what passing earns. Agree on what day the buyer will decide and what happens if every Must-Have passes: the technical win, a commercial conversation, or a signature. An evaluation without an end date isn’t a deal.
- Get written agreement before work starts. The economic buyer signs, not just the technical team. Criteria added after kickoff are how evaluations drift past their end date.
Opine’s own evaluation plans show why the pass/fail rule in step 2 matters. Fewer than half of the criteria added to a plan were ever rated. Criteria written as outcomes, such as “SE leaders have improved visibility into team activities,” were never rated at all, while the most-rated criterion is a testable one: “Two-way CRM synchronization.”
Success criteria template
Copy this into your evaluation plan. The example rows below show how to structure criteria for a data platform evaluation. Replace them with your own buyer requirements.
- Make it yoursEdit the example rows, add a criterion for each requirement (up to 15), and remove the ones you don’t need.
- Set the decisionAdd the decision date, who decides, and what passing earns, then rate each criterion.
- Share the readoutCheck your plan for a verdict, then email it to your team or copy a link anyone can open.
Criterion 1
Criterion 2
Criterion 3
Criterion 4
Criterion 5
The four-point rating scale (Exceeds, Meets, Partially Meets, Does Not Meet) is the one Opine uses, weighted by whether the criterion is a Must-Have or a Nice-to-Have. On Opine’s own plans, most ratings are Meets, so a Partially Meets stands out the week it lands. Keep one more answer outside the scale: Not Tested. A criterion that never got its data, environment or owner has neither passed nor failed, and the readout should say so. Not Tested is different from Out of Scope, which both sides agree to at kickoff. A Must-Have left Not Tested blocks the decision just as a failure would. Name what’s holding it up, then either test it before the decision date or agree in writing to move it to Out of Scope.
How do you use success criteria to advance enterprise deals?
Written criteria do four things a verbal agreement can’t do.
- They make the technical win a fact. When the buyer rates the criteria themselves, the win is a score both sides watched land, not an unsubstantiated claim made at the readout.
- They tie the win to a next step. Criteria agreed with a decision date and a named outcome turn into a signature conversation instead of a fresh round of evaluation or negotiation.
- They give your champion something to forward. A readout built from the agreed criteria is the document your champion takes to the economic buyer.
- They expose risks while you can still act. A criterion rated Partially Meets in Week 2 is a conversation. Found at the readout, it’s a loss.
The economic buyer’s signature is the part deal teams skip frequently, and it matters most. In a 2026 PreSales Pulse survey of 412 SEs, POCs with success criteria agreed in writing by the economic buyer won at 1.4x the rate of POCs without them (source).
How Opine handles success criteria
Opine keeps a success criteria library, searchable by meaning, that each POV plan draws from. Buyers rate their assigned criteria through the buyer portal, and their scores sit beside yours per criterion rather than blended into a single number. Across deals, the Criteria Metrics view shows which criteria your wins have in common, while technical fit assessments show where you consistently fall short.
Success criteria FAQ
What is the definition of success criteria?
Success criteria are the measurable conditions a product must meet for a buyer to approve a technical evaluation. They are agreed upon before the evaluation starts and scored at the end.
What are examples of success criteria for a POC?
Good examples are testable statements tied to a business outcome: users sign in through the existing SSO provider, data stays in a required region, or a full day of production data loads without manual fixes. Each one names how it will be measured and who on the buyer’s side rates it.
What’s the difference between success criteria and acceptance criteria?
In product and project work, acceptance criteria are the pass/fail checks a specific deliverable must meet before a customer accepts it. POC success criteria work the same way, applied to an entire evaluation to determine whether the buyer accepts the product.
Who should write success criteria?
The sales engineer should draft them, the buyer’s technical owners should edit them, and the economic buyer should sign off. Criteria the buyer never agreed to in writing won’t decide anything.
How many success criteria should an evaluation have?
Enough to cover every Must-Have and few enough that both sides can finish rating them before the decision date. If a criterion won’t change the final purchase decision, rank it as Nice-to-Have or drop it from the evaluation entirely.
Further reading: How to improve technical win rates · Enterprise POC best practices
