The B2B Software PoC Charter: Scope, Success Criteria, and Exit Rules

“The pilot went well” is not a buying decision. A B2B software proof of concept (PoC) is useful only when both sides know what question it is testing, what evidence would answer it, and what happens when the test ends.

Write those rules down before the demo turns into an implementation project. A one-page charter can keep the evaluation bounded, make success measurable, and give the buyer and vendor a shared route to scale, extend, or stop.

Start with the decision, not the feature list

A demo asks, “What can the product do?” A PoC should ask, “Can this product solve this specific problem in our environment well enough to justify the next commitment?”

For example: “Can this tool route invoices to the right approver using our current data and permissions, without adding an unacceptable review burden?” That question names a workflow, a constraint, and a decision. “Test the automation features” does not.

People use proof of concept, pilot, and trial differently. Agree on what the label means in this engagement. You might use a PoC to test technical feasibility, then a pilot to see whether a bounded group can use the solution in a live workflow. Or you may use one term for both. The name matters less than a shared test and a decision date.

There is a useful procurement principle here. The U.S. Federal Acquisition Regulation Companion recommends considering proof periods with defined acceptance criteria before full deployment under contract. That guidance is written for federal acquisition, not every commercial deal, but the discipline travels well: agree on what counts as acceptable before seeing the result. The GSA AI Guide for Government makes a related point for public-sector AI projects: evaluate a pilot against quantified objectives, then address ownership, implementation, and when the solution should be retired before moving to production.

Put the test on one page

A charter is not a contract substitute or a full project plan. It is the short agreement that keeps the evaluation answerable. Capture these items before access, data transfer, or configuration begins:

1. Decision to make: What will the buyer decide at the end—expand, run one bounded follow-up test, or stop?
2. Question and hypothesis: What must the software demonstrate, for which workflow and users, under which conditions?
3. Scope and exclusions: Which team, use case, data, integrations, locations, and product functions are in? What is explicitly out?
4. Baseline and evidence: What happens today, how will the pilot be measured, where will the evidence come from, and who will interpret it?
5. Success gates: Which conditions are mandatory, which are targets, and what result would count as inconclusive?
6. Owners and responsibilities: Who runs the test, supplies the data, supports users, validates results, and makes the final decision?
7. Guardrails and limits: What data, security, access, spend, support, or change-control boundaries apply?
8. Dates and exit plan: When does the test start and end, what can stop it early, and what happens to data and access afterward?

Keep the decision owner and the operational evaluator distinct if they are different people. A team can generate evidence without having authority to approve a wider rollout. The GSA guide explicitly asks who owns the product after a pilot and how the broader implementation will work; those questions belong in the charter, not in a post-pilot scramble.

Make success measurable—and possible to miss

A strong criterion has a measure, a threshold, a data source, a time window, and an owner. “Users like it” is too vague on its own. “At least [buyer-set share] of [defined user group] completes [named workflow] without [defined failure] during [window], measured from [system or observation]” can be evaluated.

Choose criteria that match the buying question. A software pilot often needs evidence in three areas:

• Capability: Does the product complete the required task on representative cases, including the awkward cases that matter?
• Outcome: Does it improve the agreed business measure compared with a stated baseline, such as elapsed time, rework, error rate, or cost per completed workflow?
• Operational fit: Can the intended users, systems, and support team operate it within the agreed security, integration, and workload constraints?

Not every pilot needs the same measures, and a short pilot may not establish long-term return on investment. Pick one primary outcome and a small number of supporting or “must-pass” criteria. Mark hard blockers separately from preferences: a security requirement may be non-negotiable, while a usability improvement may be a trade-off.

Write down the baseline before the pilot. If the workflow has no reliable baseline, make establishing one part of the test and lower the strength of the conclusion. If the result is meant to show that the software caused an improvement, decide whether a comparison group, a before-and-after design, or another credible comparison is feasible. Otherwise report an observed change, not proof of causation.

For an example of choosing an outcome instead of counting setup activity, see Rothenhall’s guide to measuring time to value alongside onboarding completion. The same distinction applies to a software PoC: an integration connected is evidence that setup happened; it is not, by itself, evidence that the user’s problem was solved.

Bound the work and protect the test

A pilot can grow quietly: another team joins, a new integration becomes “essential,” or custom work consumes the time meant for evaluation. Write down the boundary—users, workflow, data, integrations, sites, duration, and support hours—and require a named owner to approve any change that affects the result.

Define the operating guardrails before starting. At minimum, agree who may access the environment, what data may be used, how incidents are escalated, what the vendor will configure or support, what work is chargeable, and how data, credentials, and access will be removed or returned at the end. Ask procurement, security, privacy, and legal teams to review the parts that fall within their authority; a one-page charter does not replace their review.

Also set the evidence standard. Record what counts as a successful completion, a failure, a user workaround, and a missing observation. Include the number and type of cases or users needed to make a decision. A pilot that did not encounter enough representative work is inconclusive—not a pass by default and not necessarily a product failure.

Choose a duration that fits the question

There is no universal 30-, 60-, or 90-day PoC. The right window depends on the workflow’s frequency, implementation steps, user availability, and how much evidence the decision requires. Set calendar start and review dates, but also define the minimum evidence needed: for example, complete end-to-end cycles across the relevant case types, rather than a fixed number of elapsed weeks alone.

Set early stop rules as well. Stop or pause for a material security or privacy incident, a breached cost or access limit, a critical technical requirement that cannot be met, or a missing prerequisite that makes the test invalid. Treat a missing input as “not tested”; do not quietly count it as success.

An extension should answer one unresolved question, not rescue an evaluation with no finish line. Require a short written case: what remains uncertain, what new evidence the extra time will produce, who owns the test, how long it will run, and the date of the final decision. If the question or scope changes materially, re-charter it.

Decide: scale, extend, or stop

At the review, compare evidence with the gates set in advance and record the decision with its owner:

• Scale when the must-pass requirements are met, the primary outcome reaches its agreed threshold, and there is a credible owner, operating plan, and commercial or procurement path for the next stage. A successful test in one team supports a decision about that context; it does not automatically prove results will repeat everywhere.
• Extend only when the pilot is promising but one important, testable uncertainty remains. Name the new question, evidence, owner, time limit, and decision date. Do not expand the scope simply because the team is reluctant to stop.
• Stop when a critical gate fails, a hard constraint cannot be resolved, the economics do not work for the buyer, or there is no viable owner or path to operate the solution. Preserve the learning and close access and data handling as agreed.

The Australian Centre for Evaluation’s guide to evaluating pilot programs lays out the same broad decision logic—scale, adapt, test further, or stop—and advises planning evaluation and measurable outcomes from the beginning. It is public-program guidance rather than a B2B software standard, but it reinforces a useful point: “more testing” is one possible decision, not the default outcome of every pilot.

If you stop, the evidence can still improve the next buying decision. Rothenhall’s closed-lost buyer research loop offers a useful companion for separating what decision-makers actually said from the team’s interpretation of why an evaluation did not proceed.

A copyable PoC charter

Use this short version to start the conversation; tailor the fields to the product, risk, and buying process:

Decision: At the end, [decision owner] will decide whether to [scale / run one defined follow-up test / stop].
Question: Can [product] complete [workflow] for [users] under [conditions or constraints]?
Scope: Included: [users, cases, systems, data, locations]. Excluded: [explicit boundaries].
Baseline and measures: Today: [baseline]. Primary outcome: [measure, target, window, source, owner]. Must-pass gates: [criteria].
Evidence: Minimum useful observations: [cases/users/cycles]. Inconclusive means: [condition].
Responsibilities and guardrails: Buyer owner: [name/role]. Evaluator: [name/role]. Vendor: [work/support]. Limits: [security, data, cost, access, change control].
Schedule and exit: Start: [date]. Review: [date]. Stop triggers: [conditions]. At close: [data/access/configuration handling].
Decision rule: Scale if [conditions]. Extend only to test [one question] by [date]. Stop if [conditions].

Have the buyer and vendor sign off on the charter before the first test run. Afterward, keep the result just as specific: what passed, what failed, what was not tested, who owns the next step, and by when. That is how a PoC becomes a decision rather than an open-ended demo.