Sales Proof of Concept: Success Criteria Before the Pilot

A sales proof of concept tests an agreed buyer requirement before a larger purchasing decision. Its useful output is evidence: what worked, under which conditions, what failed and what the buyer can decide next. A successful demonstration and an approved purchase are separate outcomes.

Before offering an enterprise pilot, agree on the unresolved question, the acceptance criteria, the people responsible and the decision meeting. This guide proposes a practical charter for that conversation. It draws on Christian Lund's Templafy interview and Cos Nicolaescu's Accrual interview; their experiences inform the method without establishing a universal conversion rate.

What is a sales proof of concept?

A proof of concept, or POC, investigates feasibility. Atlassian's project management guide describes it as gathering evidence before committing substantial resources. In a sales evaluation, the buyer's question might be whether a proposed solution can meet a specific requirement in the buyer's setting.

Names vary between organizations. For this guide, a demo shows a relevant capability; a POC tests an uncertain capability against agreed conditions; a pilot exercises a limited operational deployment. One evaluation can contain all three. Ask what is actually being tested instead of assuming that the label defines the scope.

Our product demo framework helps structure the presentation itself. This article addresses the next decision: whether to invest in a buyer-specific evaluation and how to judge its evidence. A POC should add information the buyer cannot obtain from an ordinary demonstration or documentation review.

Qualify the request before assigning engineers

In The SaaS Podcast, Christian Lund describes enterprise prospects asking to begin with ten users. He says Templafy attached conditions to a POC: appropriate timing, a budget, purchase intent, explicit proof criteria and an understanding of the larger rollout that could follow. When those prerequisites were absent, they could walk away.

That is an account of one company's approach. It does not mean every small pilot deserves rejection or every uncertain budget makes learning worthless. Distinguish a commercial evaluation from an exploratory research engagement. Both may be useful, but they deserve different resource limits and should not produce the same forecast commitment.

Start the qualification conversation with four questions:

• Which unresolved requirement prevents a decision today?
• Who will supply the inputs and judge the result?
• If that requirement is demonstrated, what additional approvals remain?
• When will the buyer review the evidence and decide what follows?

A buyer who cannot answer yet may need discovery rather than a custom environment. Return to sales discovery questions, clarify the problem and agree on what information would make a test useful. Avoid using a trial simply to postpone an uncomfortable conversation about fit.

Write the proof before building the test

Replace a broad promise such as “make the team more productive” with a checkable statement. Specify the task, the representative inputs, the expected output, how it will be assessed and the conditions that would invalidate the test. Decide these together with the buyer rather than writing a success definition after seeing favorable results.

Consider an illustrative document automation evaluation. The buyer wants approved sales documents produced from an existing record. The test might check whether agreed mandatory fields appear correctly, whether authorized reviewers can complete the workflow and whether exceptions are visible. The buyer selects representative examples, including difficult cases, and defines acceptable thresholds. These are proposed criteria, not reported Templafy results.

Separate different kinds of evidence. Technical feasibility asks whether the capability works. Operational usefulness asks whether people can use it in their actual workflow. Commercial readiness asks whether the organization is prepared to approve and implement it. A positive answer to the first question does not automatically answer the other two.

Do not claim that ten friendly users represent an entire enterprise. Record which roles, workflows and conditions the test covers, plus the ones it leaves untested. That boundary makes the conclusion more useful to the people who must authorize the next step.

A sales POC charter you can copy

The following charter is an editorial synthesis from the interviews. It is a working brief for buyer and seller, not a legal agreement or a fixed industry standard. Complete it before requesting implementation time.

• Decision to inform: name the purchase or deployment decision and its owner.
• Uncertainty: write the specific requirement that remains unproved.
• Scope: state the included workflow, participants, inputs and exclusions.
• Acceptance criteria: define the result, assessment method, reviewer and failure conditions.
• Dependencies: identify access, input preparation, internal approvals and named owners.
• Resource boundary: agree on the work each side will contribute and when testing ends.
• Evidence record: preserve results, exceptions, assistance and changes made during testing.
• Decision review: schedule a meeting with options to proceed, run a bounded additional test or stop.

An unresolved field is useful information. For example, “budget owner not yet involved” is more accurate than “budget confirmed” based on a supportive user's enthusiasm. Use your lead qualification process to keep buyer evidence separate from assumptions.

Record changes to criteria with their reasons. If the customer discovers a new requirement, assess whether it belongs in this evaluation or a later phase. Quietly adding work makes the original scope and results difficult to interpret. Likewise, removing a failed requirement without explanation turns the evidence into a selected success story.

Test in conditions you can describe honestly

In A Product Market Fit Show, Cos Nicolaescu discusses being explicit with Accrual customers about capabilities and limitations. He warns against presenting selected outputs from repeated attempts as if they reflect the customer's ordinary experience. He also distinguishes an impressive AI demo from the reliability and accuracy needed in production.

Apply that lesson by keeping an exception log. Record manual corrections, repeated runs, special configuration, unavailable inputs and vendor assistance. Assistance can be entirely appropriate in an evaluation; concealing it is what makes the conclusion misleading. Ask whether the buyer could reproduce the result with the support intended for the next phase.

Include the people who will actually do the work. Nicolaescu describes involving practitioners, technology teams and leaders at different levels rather than relying solely on executive enthusiasm. Their responsibilities differ: a user can assess workflow usefulness while an implementation owner can surface dependencies the test has not exercised.

The Accrual case study examines that company's design partner strategy in detail. Here the narrower lesson is to make the test record interpretable: what was demonstrated, who assessed it and what production work remains.

Decide what happens when the POC ends

Review each criterion against the agreed evidence. “The customer liked it” is feedback, not a substitute for the acceptance record. Equally, a failed test can be valuable if it reveals a constraint before both sides commit more resources.

Use three explicit outcomes. Proceed means the agreed question has been answered and the buyer can consider the next stage with its remaining approvals. Extend means one specific uncertainty remains worth testing, with a new scope and end point. Stop means the requirement, timing or resource fit does not support further evaluation now.

Do not turn a technical pass into an automatic purchase promise. Procurement, implementation capacity, commercial agreement and other dependencies may remain. Name those steps and owners in the decision record. The customer onboarding guide covers the coordination that follows once a customer begins implementation.

If the buyer wants an extension, ask what new evidence would change the decision. Repeating the same demonstration without a new question rarely clarifies the situation. Record a reason for every extension so that sales activity does not silently become indefinite custom work.

Should a sales POC be paid?

The interviews used here do not establish one correct charging model. Evaluate the work required, the value of the deliverable, the buyer's purchasing constraints and how responsibility is shared. Paid and unpaid evaluations can both be poorly scoped; price alone does not supply acceptance criteria or a decision owner.

Agree explicitly on what is included, what support is provided and what happens to any work after the evaluation. Commercial and contractual terms need their own review. A sales charter can organize the conversation without replacing that review or implying that an evaluation guarantees a subsequent purchase.

Measure the evaluation process without promising a win rate

Track evaluation requests, accepted POCs, completed tests, results against criteria, extensions, purchasing decisions and later deployment separately. Include the observation period and denominator when reporting rates. A completed test and a production customer belong to different stages.

Also track the effort consumed and the reasons for stopping. A team that declines poorly defined evaluations may create more room for suitable buyers, but these interviews do not quantify that effect for your business. Test the policy against your own comparable opportunities rather than adopting a founder's outcome as a benchmark.

Start with one upcoming evaluation. Write the uncertainty and decision owner, ask the buyer to correct the charter and secure the inputs needed to test it. The practical standard is simple: someone outside the sales conversation should be able to read the evidence and understand what it supports.

Sources and evidence limits

Christian Lund's August 2026 interview supplies the conditional POC and rollout lesson. Cos Nicolaescu's July 2026 interview supplies the transparency, stakeholder and production-readiness lessons. Both describe their own businesses; neither provides a controlled comparison of POC methods. The charter and worked example are proposed applications, not statements that either founder used every field or achieved a particular result with it.