Template

A Proof-of-Concept Plan With Success Criteria

For vendors whose pilots drift into unpaid production.

You leave with a one-page PoC plan: success criteria the buyer wrote, a fixed end date, owners on both sides and a decision meeting booked at kick-off.

By Intandemly team · Updated 24 Oct 2026 · 5 min read · Free, no sign-up

Preview

On this page

What you'll get

  • 1 copy-ready blocks
  • 5 min read

A PoC template earns its keep with three lines most pilots skip: what we are proving, when it ends and who decides what on which date. Without them a proof of concept becomes an unpaid trial with your A team attached. This plan is one page, agreed before anything is installed, and the decision meeting goes in the calendar at kick-off.

The one-page plan

PROOF OF CONCEPT: [vendor] at [company]

What we are proving
[One sentence. One claim, testable, chosen by the buyer.]

Success criteria (written by the buyer, before kick-off)
1. [Measure]   passes at [threshold], measured by [method]
2. [Measure]   passes at [threshold], measured by [method]
3. [Measure]   passes at [threshold], measured by [method]

Scope
Covers: [the one path or dataset or site]
Does not cover: [everything adjacent; this list prevents the drift]

People
Theirs: [name] (owner), [name] (hands-on), [name] (decides)
Ours:   [name] (owner), [name] (hands-on)

Dates
Kick-off:          [date]
Mid-point check:   [date]  (30 minutes, both owners)
End:               [date]  (fixed; 2 to 4 weeks is usual)
Decision meeting:  [date]  (booked NOW, with the decider attending)

The decision
If the criteria pass: [the next step, e.g. phase one contract, scope
and price already attached].
If they fail: we both say so, we take [learnings], and we stop.

Why the buyer writes the success criteria

Because criteria you wrote prove what you chose to prove, and the committee knows it. Ask the budget holder and the evaluator: "what would this have to demonstrate for you to proceed?" Their answer, written into the plan, does two jobs: it makes the decision meeting short, and it converts the PoC from your demo into their test. If nobody on the buying side can name a criterion, the account is not ready for a PoC, and finding that out free of charge is the plan's first win.

Why the end date is fixed and the decision meeting is booked first

An open-ended PoC rewards delay on both sides: their team deprioritises it, your team keeps polishing. The fixed end date and the pre-booked decision meeting with the decider in the room are the two mechanics that force the account to move. The contract that follows a passing PoC should already exist as an attached scope and price, which is the software project proposal template waiting one signature away. The small-first-project logic of entering accounts this way is one project per account.

The mid-point check

Thirty minutes, both owners, three questions: are the criteria still the right criteria, is anything blocking either side, and is the decision meeting still correctly attended? Many PoC failures are access failures (data not provided, environment not ready), and the mid-point is where they get caught while the end date can still be saved. A blocked PoC extended silently becomes a drifting one; a blocked PoC flagged in writing stays a project.

Worked example (illustrative, not a real company)

Illustrative example

Tessaro Analytics runs a PoC at Northfield Logistics. The claim: depot replanning time drops. Criteria, written by the finance lead and the operations director: replan under ten minutes on the Leeds depot's live data, adopted by two dispatchers without training beyond one session, measured over two weeks. Scope excludes the other four depots and historic reporting. The decision meeting is booked at kick-off with the finance lead attending. Mid-point catches a data access delay; one email fixes it because the plan named their IT owner. The criteria pass, the meeting takes twenty minutes and phase one signs from the attached proposal. All names are invented.

Five mistakes to avoid

  1. Proving what you wanted to prove. Criteria the buyer did not write produce a passing PoC and a stalled deal, because nothing the committee cared about was tested.
  2. No end date, or a movable one. The end date is the only thing standing between a PoC and a free production system. Extensions happen in writing with a new decision date, once.
  3. A decision meeting scheduled after the results. Booked at kick-off, with the decider, it is a commitment; scheduled later it competes with everything and the PoC result goes stale waiting.
  4. Scoping generously to impress. Every extra path, site or dataset multiplies the ways the PoC can stall on their side. One claim, one scope, provable in weeks.
  5. Running a PoC for an account with no decider attached. If nobody who can say yes will attend the decision meeting, the PoC is market research you are paying for. The plan's people section is the test.

Why this works on named accounts

A proof of concept that drifts is not a sales problem, it is a scoping problem that sales pays for: no agreed measure, no end date, no decision meeting, so the buyer rationally keeps the free thing running. The account-based version treats the PoC as the account's first project, with everything a real project has: criteria, owners, a deadline and a decision. Prove something the budget holder named, on a date everyone booked, and the PoC becomes the shortest path into the account instead of the longest.
How account-based selling works →

Common questions

What should a proof of concept include?

One testable claim, success criteria the buyer wrote with thresholds and measurement methods, a tight scope with explicit exclusions, named owners on both sides, a fixed end date and a decision meeting booked at kick-off with the decision maker attending. One page covers all of it.

How long should a PoC run?

Two to four weeks for most B2B software and services: long enough to produce the agreed measures on real data, short enough that both teams keep it staffed and the decision stays warm. If the claim genuinely needs months, split it: prove the riskiest part first as the PoC and move the rest into phase one.

Should a proof of concept be paid?

Paid where you can: even a nominal fee changes how seriously the buyer staffs their side, and it tests budget existence early. Where the market expects free, keep the scope small enough that free is survivable, and make the attached phase-one proposal the visible price of a pass.

More from the Academy

Template6 min read

Software Project Proposal Template

For IT services firms whose proposals vanish into silence.

You leave with nine sections in the order a committee actually reads, the scope wording that prevents disputes and a decision ask with a date on it.

Template6 min read

Mutual Action Plan Template

For sellers whose deals live or die on a buyer's invisible internal process.

You leave with a shared-timeline template, the introduction wording buyers accept and the weekly habit that keeps it true.

Sales hack3 min read

One Project per Account: The AI Fact Sheet

For sellers who paste the same account background into a new AI chat every time.

You leave with a fact sheet template, a set of standing instructions and a five-minute weekly update routine.

Want this in your inbox?

Optional. We use your email only to send you this, nothing else.

Want this run on your key accounts?

Tell us which accounts you need to open. We will show you how we would work them.