Proof of Concept: Scoping One Properly and Knowing When to Refuse

A proof of concept exists to answer a question that a demonstration cannot settle. Usually the question is about this buyer's specific environment: whether their data will import cleanly, whether the integration they need actually works, whether performance holds at their volumes, whether their identity system can be used for access. These are factual questions with observable answers, and that is exactly what makes them suitable.

Questions that are not suitable include whether people will like the product, whether the team will adopt it, and whether it will deliver the promised benefit. Those are pilot questions, because they need real users doing real work over enough time for habits to form. Running the wrong instrument at a question is the most common structural mistake in evaluations, and it wastes weeks on both sides.

Start from the doubt

Ask directly what would have to be true for the buyer to proceed. The answer is usually shorter than the requirements document suggests, and it identifies the two or three things genuinely in question. Everything else can be handled by a demonstration, a document or a reference conversation, all of which are faster and cheaper than an evaluation.

Write criteria that can be marked

Each criterion should be a sentence someone could tick or cross without needing a discussion. An import of a stated size completes with a sampled match rate. A message arriving on the business number appears against the right account within a stated time. A named report can be produced by the buyer's own administrator without vendor assistance. Criteria describing impressions rather than events are not criteria, and including them is how an evaluation ends in disagreement.

State what is out of scope

Exclusions prevent more disputes than inclusions. Write down what will not be built, tested or configured during the exercise. This is far easier to agree at the start, when nobody has invested anything, than in week three when a new requirement has appeared and refusing it feels like obstruction.

Set a decision date, not just an end date

The end date is when the technical work stops. The decision date is when a named person says yes or no. Only the second one prevents the drift that turns evaluations into indefinite free usage, and asking for it is a reasonable request that also tells you a great deal about how serious the buyer is.

Question under test: can order messages arriving on the company's business number be attached to the correct dealer account and converted into draft orders with the right price list, at the volume this business handles.

Criteria: first, 500 historical dealer records import with a field-level match on a sampled 50; second, a message from a known dealer number appears against that dealer's account within one minute; third, an executive converts a message into a draft order with the correct tier price applied, without manual price entry; fourth, an administrator adds and removes a user without vendor assistance.

Out of scope: integration with the accounting system, custom reports, and any change to the existing invoice format. Buyer commitments: an export of dealer master data by the second day, one nominated administrator available for two hours, and two executives available for a one-hour session in the second week. Duration: ten working days, with a decision meeting on the twelfth with the named sales director present.

On the vendor side, the classic failure is agreeing to everything. Each additional requirement seems small, the exercise expands into weeks of configuration, and what began as an evaluation becomes an unpaid implementation with no commitment attached. The moment a proof of concept requires custom development, it has stopped being a test and become a project, and it should be re-scoped or charged for.

On the buyer side, the common failure is the evaluation with no decision maker. Users are enthusiastic, technical reviewers are satisfied, the criteria are met, and then the exercise reaches someone who never agreed to the criteria and starts a fresh set of questions. The preventable version of this is fixed by one requirement at the start: whoever will decide must accept the criteria in writing.

The shared failure is the exercise that never ends. Without a decision date, an evaluation becomes a comfortable arrangement in which the buyer gets value and commits to nothing, and the vendor keeps supporting it in the hope that goodwill converts into a contract. It rarely does. A stalled evaluation is usually a decision that has already been made and not communicated.

A pilot programme puts the product into limited real use and tests adoption as well as capability. A trial is unassisted access with no agreed criteria. A bake-off is a competitive evaluation running several vendors against the same criteria, which is legitimate but demands close attention to who wrote the criteria. A statement of work is the contractual document that governs a paid evaluation, and using one is sensible whenever real effort is being committed on either side.

Related pages on evaluating, demonstrating and buying software:book a demo, free CRM plan, features overview, what a CRM is, use cases, and compare alternatives.