Design a paid pilot that can end cleanly

The dangerous pilot is easy to start and impossible to finish. A champion wants movement, the founder wants a logo, and both agree to define success later. Three months on, the product team is maintaining a private branch while the buyer calls the work 'promising.'

A useful pilot is narrower. It purchases a real-world test and a decision date. The research chapter's warning about pilot purgatory is at validation chapter.

Name the buyer and the decision

Record four roles even if one person holds several: daily user, operational owner, economic buyer, and approver for security or procurement. A friendly champion without a path to budget is a research contact, not yet a pilot buyer.

GitLab's published sales handbook—an issuer description of its own commercial process—requires pain, an economic buyer or path to one, decision process, agreed next step, and stage exit criteria (GitLab opportunity stages). A startup does not need GitLab's machinery. It does need the same factual distinction between interest and a qualified buying process.

Scope one live workflow

Specify the included users, data, location, workflow, support hours, integrations, and exclusions. Prefer one consequential workflow over a broad sandbox. State what remains manual, what is production-grade, and what will be discarded.

UK government commercial guidance says pilots should have measurable objectives, defined scope and scale, resources, timescales, commercial mechanisms, and time to consider results (Digital, Data and Technology Playbook). This is procurement guidance, not proof that a startup pilot will convert; it is a useful completeness check.

Agree acceptance and exit before kickoff

Use no more than three acceptance measures: an outcome measure, a reliability or risk guardrail, and an adoption measure. Name the data owner and baseline. Then write all possible exits: convert to a defined commercial agreement, extend once for a named unresolved question, or stop and remove access/data.

AWS's own proof-of-concept guidance recommends revisiting predefined criteria for business value, technical viability, cost, and strategic fit before a go/no-go decision (AWS PoC guidance). Treat this as vendor guidance, especially where AWS technology is involved, not independent evidence of return.

Worked hypothetical pilot scorecard

Hypothetical: A warehouse software startup runs a six-week paid pilot at one site. The buyer is the regional operations director; the shift manager owns use; IT approves access. Scope is inbound exception triage for one product line, capped at 800 orders.

Scorecard:

• Outcome: median exception-resolution time falls from the buyer-verified baseline by at least 20%.
• Guardrail: no severity-one data or routing incident; every recommendation remains reviewable by a supervisor.
• Adoption: at least 70% of eligible exceptions are processed through the pilot in weeks four through six.
• Commercial decision: within five business days of the readout, sign the pre-scoped annual order form, approve one two-week extension for a named integration question, or terminate.

These numbers are invented for the example, not benchmarks. The right thresholds come from the buyer's baseline and the economics of the particular workflow.

Pilot document checklist

• Fee, invoice timing, and who can approve change requests
• Included workflow, users, data, environments, and support
• Baseline, measures, thresholds, and evidence owner
• Security, privacy, liability, and data-return terms reviewed by qualified counsel where needed
• Kickoff, midpoint, readout, and decision dates
• Conversion offer and implementation assumptions
• Stop work, access removal, export, deletion, and handover steps
• Internal labor log by role

Limits

Payment is stronger evidence than a free trial, but one buyer can fund a bespoke service that has no repeat market. A pilot also cannot settle regulatory, security, or long-term reliability questions outside its scope. Log custom labor and rejected requests; otherwise revenue can hide a product that becomes less repeatable with every customer.