A proof of concept template is a short plan for testing whether a product, feature or technology works for you before you commit real money. For software, it fixes the problem, scope, pass marks and timeline of a time-boxed trial.
It is the written agreement on what a trial must prove and how you will know. Before anyone logs in, the template records the problem, what is in and out of scope, who takes part, the measurable targets and the date a decision is due.
For a SaaS purchase, the buyer usually writes it with the vendor's solutions engineer. IT, security and the business team that will use the tool each add the tests they care about, and procurement keeps the trial from turning into months of free use.
Without a template, a POC tends to end with a vague sense that the product seemed fine. With one, it ends with a scored result against criteria everyone signed before the trial started, which makes the buy, walk away or negotiate decision far easier to defend.
The decision you need, the product under test and the business problem it should solve.
What the trial must prove, plus the use cases, data and integrations that are in or out.
Environments, test data, licences and the named people from both sides, with their hours.
Measurable pass or fail targets, each with a weight and an owner.
Week-by-week plan and the scripted tests, with results logged against each one.
A feasibility verdict and the next move: buy, move to a pilot or stop.
Ready to use in Word, Google Docs and PDF. Fill it in, save it, reuse it.
Write the problem, objectives and scope. Agree internally before talking to the vendor.
Share the success criteria with the vendor and confirm environment, data and dates in writing.
Work through the test cases on a fixed timeline, usually two to six weeks.
Score every criterion as pass or fail and log the evidence behind each result.
Recommend buy, pilot or stop, and hand the results to procurement for the commercial talks.
Start with one page: problem, three success criteria with targets, test users, end date and decision owner. Add test cases and a resource plan for larger trials.
Keep the plan to four to six pages. The most common failure is writing it after the trial has begun, when the criteria quietly bend to fit what the product can do. Sign off sections one to five with the vendor before anyone gets access.
The product, the vendor, the decision needed, the decision owner and the date, in half a page.
What is broken or missing today, with figures such as hours lost, error rates or tools replaced.
Two to four objectives, then a clear list of in-scope and out-of-scope use cases, teams, data and integrations.
Sandbox or production tenant, test data, licences, and named people from both sides with expected hours.
Measurable targets for each objective, with pass marks and weights agreed by the vendor.
Start and end dates, weekly checkpoints and the date results go to the decision owner.
Scripted tests linked to the criteria, with expected outcome, actual result and evidence.
Feasibility verdict, open risks and the recommended move: buy, pilot, extend or stop.
1. Executive Summary [Company Name] will run a [4]-week proof of concept of [Product Name] from [Vendor Name], starting [Start Date]. The POC will test whether [Product Name] can [core outcome, e.g. automate month-end reporting]. [Decision Owner] will decide by [Decision Date] whether to buy, run a pilot or stop. 2. Problem Statement [Team] spends about [number] hours a month on [manual task]. Errors in [process] caused [impact] in the last [period]. 3. Objectives and Scope Objective 1: [Measurable objective]. Objective 2: [Measurable objective]. In scope: [use cases, team, data set, integration with System A]. Out of scope: [single sign-on, data migration, additional regions]. The POC will use [anonymised / production] data in a [sandbox / dedicated] tenant.
Write the criteria before the vendor demo, not after. Mark two or three as must-haves that fail the POC on their own, such as security or a required integration. Agree the list with the vendor in writing so there is no argument about the result.
| Criterion | Measure | Target | Weight % | Result |
|---|---|---|---|---|
| Data sync with ERP (must-have) | Records synced without manual fixes | 99% of 5,000 test records | 25 | Pass |
| Report build time | Minutes to build the month-end pack | Under 30, from 4 hours today | 20 | Pass |
| SSO and role permissions (must-have) | Roles enforced for 3 test profiles | All 3 profiles correct | 20 | Pass |
| User adoption | Test users completing tasks unaided | 8 of 10 users | 15 | 7 of 10 |
| Support response | Time to first reply on 3 tickets | Under 4 business hours | 10 | Pass |
| Admin effort | Hours per week to maintain | Under 2 | 10 | Fail |
| Total | 100 | 75 of 100 |
Illustrative targets for a reporting tool. Weighted score counts only the passed rows.
Write this rule into the plan before the trial starts.
Any failed must-have criterion means the POC fails, whatever the total.
Add the weights of passed criteria. 70 or more passes, 50 to 69 means extend or pilot, under 50 fails.
Link every result to a screenshot, log or user note in the test case log.
Write test cases from your real workflows, not the vendor's demo script. Use your own data where security allows, because sample data hides the edge cases that cause trouble later. Five to fifteen test cases is enough for most SaaS POCs.
| ID | Test case | Criterion | Expected | Actual | Result |
|---|---|---|---|---|---|
| TC-01 | Sync 5,000 invoices from ERP | Data sync | 99% match, no manual edits | 4,972 matched, 28 flagged | Pass |
| TC-02 | Build the September report pack | Report build time | Under 30 minutes | 22 minutes | Pass |
| TC-03 | Log in as viewer, edit a report | Role permissions | Edit blocked | Edit blocked | Pass |
| TC-04 | New user builds a chart unaided | User adoption | 8 of 10 succeed | 7 of 10 succeed | Partial |
| TC-05 | Weekly admin tasks timed | Admin effort | Under 2 hours | 3.5 hours | Fail |
Illustrative results from a four-week trial.
Time-box the trial and put the end date in the vendor's agreement. A POC that runs past its date without a decision usually means the criteria were unclear. Block calendar time for test users before you start.
| Week | Milestone | Owner | Done when |
|---|---|---|---|
| 0 | Plan and criteria signed by both sides | Product owner | Sections 1 to 5 approved |
| 1 | Environment, data load and SSO set up | Vendor engineer, IT | Test users can log in |
| 2 | Core test cases run | Test users | TC-01 to TC-03 logged |
| 3 | Adoption and support tests | Test users, procurement | TC-04, TC-05 and tickets logged |
| 4 | Results scored and recommendation written | Product owner | Memo sent to decision owner |
| Role | Side | Responsibility | Hours |
|---|---|---|---|
| Product owner | Buyer | Owns the plan, scores results, writes the recommendation | 16 |
| Test users (10) | Buyer | Run test cases and give feedback | 4 each |
| Security lead | Buyer | Reviews data handling and access controls | 6 |
| Solutions engineer | Vendor | Sets up the tenant, fixes blockers | 20 |
Illustrative hours for a four-week POC.
Most failed POCs skip something before the start, such as security approval for test data or an agreed end date. Tick each item off and keep the checklist with the results for the business case.
Write the memo within a week of the trial ending, while results are fresh. Put the failed criteria next to how the vendor proposes to fix them, because those become terms in the contract.
To: [Decision Owner] From: [Product Owner] Date: [Date] Subject: POC result for [Product Name] Verdict: [Pass / Extend / Fail]. [Product Name] passed [number] of [number] criteria, including all must-haves, with a weighted score of [score] out of 100. What failed: [Criterion], [actual result] against a target of [target]. [Vendor Name] proposes [fix] by [date]. Recommendation: [Buy / Run a paid pilot for [weeks] / Stop]. Proceed to commercial terms, with [fix] written into the contract as a condition. Next steps: Procurement to negotiate by [date]. Implementation to start [date] if approved.
Once the POC passes, the result becomes your strongest point in the commercial talks. Compare the vendor's quote against pricing benchmarks before you sign, and plan the rollout with a SaaS implementation plan.
A passed POC still needs a fair price. Spendflo pricing benchmarks show what others pay.
See pricing benchmarksA short test of whether something can work in your environment, against fixed criteria.
An early working model of a product, used to test design rather than feasibility.
A limited live rollout to one team or site, usually paid, to test adoption and support.
The smallest releasable version of a product, built after the concept is proven.
Self-serve access with no agreed criteria. Useful for a first look, weak as evidence.
A requirement that fails the whole POC if it is not met, whatever the total score.
Sign the success criteria with the vendor before anyone gets access.
Script test cases from the work your team does today, not the vendor's demo.
Put the end date and decision date in the plan and the trial agreement.
Clear the test data and access model before kickoff, not in week three.
Run the POC on capability and negotiate price afterwards, with the results in hand.
Vendor-written criteria test what the product does well, not what you need.
Allow one extension at most, with a new end date and a reason.
Ten engaged users give clearer results than fifty who rarely log in.
Without a written verdict, the decision drifts and the trial becomes unpaid use.
State the problem in figures: hours, errors, cost or risk today.
Turn each objective into a measurable target, mark the must-haves and weight the rest.
Write one or more test cases per criterion, with the expected result.
Name test users, the security reviewer and the decision owner, and fix the end date.
Orbit Analytics trials a reporting tool from Brightline Software for four weeks with ten finance users. It passes data sync, report build time and permissions, scoring 75 out of 100, but needs 3.5 admin hours a week against a target of 2. Orbit recommends buying, with vendor-led admin training written into the contract. Figures are illustrative.
Every part on this page, in Word, Google Docs and PDF, with the examples filled in.
Use all six parts. Procurement joins from the start so the trial terms, data handling and end date are agreed before kickoff.
The vendor drafts the plan, but the buyer must approve the criteria. Keep the scope narrow so the trial closes in weeks, not months.
Swap vendor roles for engineering roles, and judge feasibility, cost to build and effort to maintain.
Best for formal POCs that go to an approval board.
Best when buyer and vendor edit together.
Two-page checklist, ready to print.
$3.7B in software spend processed through Spendflo, at 30% average savings.
See your savingsA good proof of concept template sets the finish line before the trial starts, scores the product against it and ends in a clear decision. The work that follows, from approval to price to contract, decides whether the result turns into value.
Quick answers to what people ask most about the proof of concept template.
Start with the problem and the decision you need, then set objectives, scope, resources and measurable success criteria before the trial begins. Add a timeline and test cases, and finish with a recommendation once results are in. Download the template above to follow the eight sections in order.
A finance team trialling a reporting tool for four weeks, with ten users and six scored criteria such as data sync accuracy and report build time, is a typical example. The worked example on this page shows how it was scored and decided. Download the template to run the same kind of trial.
Agree the problem and scope internally, write weighted success criteria, script test cases from real workflows and fix an end date with the vendor. Run the tests, score each criterion and write a go or no-go memo. You can download a ready-made POC template from this page.
It is a short list of checks for before, during and after a proof of concept, such as signed criteria, security approval of test data and deletion of data at the end. It stops steps being skipped under time pressure. The download includes a twelve-point printable version.
You can download it free from this page in Word, Google Docs or PDF. It includes the POC plan, success criteria, test case log, timeline, checklist and recommendation memo.
Software buying
Purchase orders
Contracts
Vendor management
Sourcing and RFx
Budgets and business cases
Procurement
Accounts payable
Purchasing
Supply chain
Spendflo runs software intake and approvals, shows pricing benchmarks for what others pay, and stores the signed contract with its renewal dates.
Enter your work email and we'll unlock every format.
Didn't start, or need another format? Pick one below.
Google Docs: upload the file to Google Drive, then open it with Google Docs.
