What a proof of concept template is
A proof of concept (POC) is a time-boxed test that answers one question for the buyer: will this work for us, with our data, our systems and our people? In B2B software sales it usually comes after a tailored demo and before the commercial proposal, and it is often the most expensive stage of the deal for both sides, because it takes engineers, evaluators and weeks of calendar time.
The template exists to stop a POC turning into open-ended free consulting. Its most important part is the one written before anything is switched on: a short list of success criteria, each measurable, each tied to a use case the buyer cares about, each with a buyer evaluator who will judge it. When the buyer has agreed those criteria in writing, the end of the POC is a decision. Without them, the end of the POC is a discussion about what the POC was for.
The rest of the template gives the test the same discipline as any project: an owner on each side for each role, a dated timeline with a mid-point review, a clear description of the environment and data the test will use, and a scorecard the evaluators fill in. It ends with a decision meeting that is booked at kickoff, with the possible outcomes written down in advance: proceed, proceed with conditions, or stop.
Pilots and trials use the same structure with different weight. A pilot runs in production with a small group of real users, so the environment, data handling and support sections matter more. A free trial is usually self-serve, with no agreed criteria at all, which is why complex purchases tend to need a POC or a pilot instead.
When to run a proof of concept
- The buyer has a specific technical doubt a demo cannot settle, such as an integration, a data volume or a security control.
- The evaluation team will not recommend a purchase until their own users have tried it on their own data.
- A competing vendor is running a POC and the buyer wants to compare results on the same criteria.
- The purchase is large or hard to reverse, and the economic buyer has asked for evidence before committing budget.
- Do not offer one to fill time when the real blocker is budget, priority or a missing decision-maker; a POC will not fix those.
Proof of concept vs pilot vs free trial vs technical workshop
The names get mixed up in sales conversations. Agree which one you are running, because each answers a different question and needs a different level of commitment from the buyer.
| Type | Question it answers | Who takes part | Ends with |
|---|---|---|---|
| Proof of concept | Can it do these specific things in our environment? | A small technical and evaluation team | A scored decision against criteria agreed up front |
| Pilot | Will our people use it in real work? | A limited group of real users, in production | A rollout decision, often with commercial terms already agreed |
| Free trial | Do I like it? | Individual users, usually self-serve | A purchase or nothing, often with no agreed criteria |
| Technical validation workshop | Does the architecture fit? | Architects and security reviewers | A list of open questions answered or escalated |
The proof of concept template
Fill in the charter and the success criteria first and get both signed off by the buyer before any environment is set up. Then name the owners, date the timeline back from the decision meeting and agree the environment and data. The scorecard and the decision record are completed at the end.
POC charter
| Field | What to write |
|---|---|
| Business problem | [The problem the purchase solves, in the buyer's words] |
| What the POC must prove | [The one or two doubts that stand between the buyer and a recommendation] |
| In scope | [Three to five use cases, no more] |
| Out of scope | [What will not be tested, so nobody expects it at the end] |
| Decision it unlocks | [If the criteria are met, the buyer will move to (next step) by (date)] |
| Start date / end date / decision meeting | [Date] / [date] / [date, booked at kickoff] |
| Commercial terms of the POC | [Free, paid, or credited against the contract; who pays for any services] |
| Signed off by | [Buyer executive sponsor and seller lead, with date] |
Success criteria (agreed before the start)
| Success criterion | Use case it proves | How it is measured | Pass threshold | Buyer evaluator | Result |
|---|---|---|---|---|---|
| [Criterion 1, written so it can be passed or failed] | [Use case] | [How the evaluator will check it] | [The bar to pass] | [Name, title] | [Pass / fail / partial] |
| [Criterion 2] | [Use case] | [How it is checked] | [The bar] | [Name, title] | [Result] |
| [Criterion 3] | [Use case] | [How it is checked] | [The bar] | [Name, title] | [Result] |
| [Criterion 4, optional] | [Use case] | [How it is checked] | [The bar] | [Name, title] | [Result] |
Owners on both sides
| Role | Buyer owner | Seller owner | Responsible for |
|---|---|---|---|
| Executive sponsor | [Name] | [Name] | Signing off the criteria and attending the decision meeting |
| POC lead | [Name] | [Name] | Running the plan day to day and calling the mid-point review |
| Technical lead | [Name] | [Solutions engineer] | Environment, integrations, data loading and access |
| Evaluators | [Names] | Not applicable | Testing the use cases and scoring the criteria |
| Security and IT | [Name] | [Name] | Approving access, data handling and any review needed to start |
| Commercial | [Procurement or budget owner, if the POC is paid] | [Account executive] | POC terms and the path to a proposal |
Timeline
| When | Milestone | Owner | Done when |
|---|---|---|---|
| Before week 1 | Charter and success criteria signed off | Both POC leads | Buyer sponsor has approved them in writing |
| Before week 1 | Security and access approved | Buyer security and IT | Accounts and data handling approved |
| Week 1 | Kickoff, environment ready and data loaded | Technical leads | Evaluators can log in and see their data |
| Weeks 1-2 | Use cases 1 and 2 tested | Evaluators | First results recorded against the criteria |
| End of week 2 | Mid-point review | Both POC leads | Blockers named, scope confirmed or reduced |
| Weeks 3-4 | Remaining use cases tested | Evaluators | All criteria have a result |
| End of week 4 | Scorecard completed | Evaluators | Every criterion scored with evidence |
| Decision meeting | Decision recorded | Executive sponsors | Proceed, proceed with conditions or stop |
Environment and data
| Item | What to agree | Owner | Ready by |
|---|---|---|---|
| Environment | [Seller-hosted sandbox, buyer tenant or production with a limited group] | [Name] | [Date] |
| Access and sign-in | [Who gets accounts; single sign-on or local accounts] | [Name] | [Date] |
| Integrations | [Which systems connect, read-only or read-write] | [Name] | [Date] |
| Data set | [Sample, anonymised or real data; how much; who loads it] | [Name] | [Date] |
| Data handling terms | [NDA, data processing terms and what happens to the data at the end] | [Name] | [Date] |
| Support during the POC | [Channel, response expectation and who answers] | [Name] | [Date] |
Evaluation scorecard
| Success criterion | Weight | Score (1-5) | Evidence | Scored by |
|---|---|---|---|---|
| [Criterion 1] | [Weight] | [Score] | [Screenshot, report, test log or user comment] | [Name] |
| [Criterion 2] | [Weight] | [Score] | [Evidence] | [Name] |
| [Criterion 3] | [Weight] | [Score] | [Evidence] | [Name] |
| Overall | [Weights add up to 100] | [Weighted score] | [Summary in two lines] | [POC leads] |
Decision meeting
| Field | What to write |
|---|---|
| Date and attendees | [Booked at kickoff; both executive sponsors and POC leads] |
| Agenda | [Results against each criterion, open issues, recommendation, decision] |
| Decision | [Proceed / proceed with conditions / stop] |
| Conditions, if any | [What must be true, by when, and who confirms it] |
| Next step if proceeding | [Proposal, security review, contract, with dates added to the mutual action plan] |
| If the criteria were not met | [What was learned, and whether a narrower scope is worth testing] |
Prefer a file? We email the Word, Excel and PDF versions to your work address, free.
Email me the filesProof of concept example
Example: fictional company
Here is the template filled in for an invented four-week POC. The criteria were written in a single working session with the buyer and signed off before the environment was built.
Ferncastle Analytics (seller) is running a POC of its forecasting platform for Marlow & Finch Logistics (buyer), whose revenue operations team wants proof that regional managers can run their forecast call in Ferncastle using CRM data, without help from sales operations.
POC charter
| Field | Example entry |
|---|---|
| What the POC must prove | That forecast data from the CRM arrives correctly and two regional managers can run a call on it alone |
| In scope | CRM sync for two regions, the regional forecast view, the weekly call workflow |
| Out of scope | Commission data, the other three regions, mobile access |
| Decision it unlocks | If the criteria are met, Marlow & Finch moves to a proposal and security review in week 5 |
| Dates | Weeks 1-4; decision meeting booked for the end of week 4 |
| Signed off by | Dana Okafor, Director of Revenue Operations, and Sam Whitley, Account Executive |
Success criteria and results
| Success criterion | Use case it proves | How it is measured | Pass threshold | Buyer evaluator | Result |
|---|---|---|---|---|---|
| Opportunity data matches the CRM for both regions | Trusting the numbers | Compare totals and 30 sampled deals against the CRM | Totals match; no sampled deal differs | Grace Lindqvist, Sales Operations Analyst | Pass |
| A regional manager runs the weekly call without help | Running the call | Observed call with no Ferncastle or sales operations support | Call completed in the tool with no help requested | Luis Moreno, Regional Sales Manager | Pass |
| Forecast changes are visible by deal between calls | Spotting movement | Manager explains what changed since last week from the tool alone | All changes above the agreed deal size explained | Luis Moreno | Partial: two changes needed the CRM |
| Access works through the buyer's single sign-on | IT approval | Test sign-in for all evaluators | All evaluators sign in through single sign-on | IT Security Manager | Pass |
Decision meeting record
| Field | Example entry |
|---|---|
| Decision | Proceed with conditions |
| Conditions | Ferncastle shows field-level change history for forecast deals in the proposal-stage demo, before the CFO meeting |
| Next step | Proposal and security review added to the mutual action plan for weeks 5-6 |
Example: fictional company. Ferncastle Analytics, Harborview Metrics, Marlow & Finch Logistics and every person named in this example are invented for illustration. Any resemblance to real companies or people is coincidental.
How to run a proof of concept
Qualify the POC before agreeing to it
Ask what the buyer will do if the POC succeeds, who will decide and by when. If nobody can answer, the POC is a research project, and it is better to say so now than after four weeks of engineering time.
Write the criteria together, before setup
Run a working session with the buyer's POC lead and evaluators to write three to five criteria that can be passed or failed. Get the executive sponsor to approve them in writing before any environment is built.
Keep the scope small
Test the doubts that block a recommendation, not every feature. Each use case added stretches the timeline and gives one more place for a minor issue to become the headline.
Book the decision meeting at kickoff
Put the decision meeting in the calendars of both executive sponsors on day one. A POC without an end date tends to drift into a long free trial.
Hold the mid-point review
Halfway through, review results so far, name blockers and decide whether to cut scope. Problems found in week two can be fixed; problems found in the last week become objections.
Score against the criteria, then record the decision
Have evaluators fill in the scorecard with evidence, present results criterion by criterion and write down the decision and any conditions. Then add the next steps to the mutual action plan.
Common proof of concept mistakes
Criteria written at the end
If success is defined after the test, it will be defined by whatever went wrong. Agree and sign off the criteria before setup.
Criteria nobody can fail
"Users find it intuitive" cannot be scored. Write each criterion with a measure and a threshold an evaluator can check.
No buyer owners
If the seller does all the work, the buyer's evaluators have not tested anything. Every use case needs a named buyer evaluator with time set aside.
Scope creep during the test
New use cases added in week three push the end date and dilute the result. Log them for after the decision instead.
Security review discovered on day one
Access and data handling approvals can take longer than the POC itself. Start them before the kickoff date, not on it.
Ending without a decision
A POC that ends with "let us think about it" has not done its job. The decision meeting should end in proceed, proceed with conditions or stop.
How Revspire runs this template
In Revspire Digital Sales Rooms, the POC plan can live in the shared room as a mutual action plan with owners and due dates, next to the criteria, environment notes and security documents, with buyer engagement analytics showing which evaluators are taking part.
Proof of concept template FAQs
What should a proof of concept plan include?
A charter with the problem, scope and the decision the POC unlocks; three to five measurable success criteria agreed before the start; named owners on both sides; a dated timeline with a mid-point review; the environment, data and access details; an evaluation scorecard; and a decision meeting booked at kickoff.
How do you write POC success criteria?
Tie each criterion to a use case the buyer cares about, describe how it will be measured, set the bar to pass and name the buyer evaluator who will judge it. Write them with the buyer in one working session, keep to three to five, and have the executive sponsor approve them in writing.
What is the difference between a POC and a pilot?
A proof of concept tests whether the product can do specific things in the buyer's environment, usually with a small technical and evaluation team. A pilot puts it in production with a limited group of real users to see whether they adopt it. Pilots tend to come later, sometimes after commercial terms are agreed.
How long should a proof of concept last?
As short as the criteria allow. Plan it in weeks rather than months where you can; the right length is set by the use cases and the availability of the buyer's evaluators. Book the decision meeting at kickoff and treat any extension as a change that both executive sponsors approve.
Should a proof of concept be free?
It depends on the effort. A short, tightly scoped POC is often free; a longer one that needs services or production setup is commonly paid or credited against the contract. Some sellers charge, or offer a credit, so that both sides plan real evaluator time. Write the terms in the charter either way.
Related templates and reading
- Free templateStakeholder map templateEvery person in the buying group on one page, with buying role, influence, stance, priorities and a next action.
- Free templateSales close plan templateEvery remaining step between verbal intent and signature, with owners on both sides, the approval chain and the risks the buyer never sees.
- Free templateDigital sales room templateThe sections of a buyer-facing deal room in order: summary, stakeholder map, mutual action plan, content by stage, business case, security, next steps and handoff.
- Free templateSales quote templateAn itemised B2B and SaaS quote: header and validity, line items with discounts, commercial terms, an internal approval record and a signature block.
- Blog: tools for solutions engineers running POCsBest presales software
- Template: where the POC sits in the wider deal planMutual action plan template
- Template: turning POC results into the case for purchaseBusiness case template