Pilot Proposal

A Pilot Buys a Decision

A prospect agrees to try the product for six weeks. People are enthusiastic, a kickoff is scheduled, and nobody can say what will happen at the end. That is not yet a pilot. It is temporary access with an expiry date.

A useful pilot lets a buyer decide whether to continue under normal commercial terms. It also lets the founder decide whether the workflow, customer, price, and support burden belong in the business. Write the decision before you write the work:

On [date], [decision owner] will decide whether to [continue, expand, revise once, or stop] based on [observable evidence].

If the sentence cannot name an owner, a date, and evidence, return to discovery. More activity will not repair an undefined decision.

Choose Evidence That Can Disagree With You

Start with the customer’s current alternative. Record how the work happens now, how long or costly it is, what errors matter, and who feels the consequence. The pilot does not need a research-grade baseline, but it does need enough context to distinguish improvement from optimism.

Then choose a small set of signals with different jobs. One should show that the promised outcome occurred. One should show that intended users adopted the workflow often enough to judge it. Where errors could damage money, trust, or operations, one should expose quality or safety. Finally, set a founder-side limit for setup and support. A product can create customer value and still be a poor solo-founder business if every account requires heroic labor.

Do not write a target merely because it is easy to count. “Users logged in” says little about whether useful work changed. Do not guarantee a result that depends on customer behavior or conditions outside the product. Agree instead on what will be observed, how it will be measured, and what evidence would count against continuation.

Draw the Workflow Boundary

Scope one repeated workflow, not a bundle of features. Name the users, volume, input data, output, and existing system that remains in place. State exclusions beside the included work while the boundary is still visible.

This is especially important when the product touches real data or consequential decisions. The proposal should name the human review, fallback process, access limits, and data class needed for the test. Security, confidentiality, privacy, ownership, and termination terms belong in an agreement appropriate to the risk; the proposal should not pretend to replace it.

Write the Proposal

Use the template as a short operating document. Replace every bracket before sending it. If a field cannot yet be completed, that is unresolved discovery rather than harmless paperwork.

Pilot: [customer] — [one workflow and outcome]

Decision
On [date], [named customer decision owner] and [founder] will decide whether to
[continue on stated terms, expand, revise once, or stop]. The decision will use
the evidence below.

Current alternative
Today, [named users] complete [workflow] by [current process]. The relevant
baseline is [time, cost, error, delay, or other observable condition], measured
from [source or sample period].

Pilot boundary
For [duration], [number and role of users] will use [product or assisted service]
for [workflow], covering [volume, cases, or events]. [Existing system or human]
remains responsible for [approval, system of record, or fallback].

Included: [setup, capability, integration, onboarding, and support].
Excluded: [adjacent workflow, custom work, migration, automation, or support].

Evidence
- Outcome: [observable change, measurement method, and threshold or review rule]
- Adoption: [behavior that shows the workflow was genuinely used]
- Quality or trust: [error review, human check, safety condition, or complaint signal]
- Founder load: [setup and support boundary that must remain commercially viable]

Responsibilities
Customer: [named user], [decision owner], [data/access], [usage commitment], and
[check-in or evidence collection].
Founder: [deliverable], [setup], [support channel and response window], [review
cadence], and [issue-escalation path].

Milestones
Kickoff: [date]
First complete workflow: [date or event]
Evidence review: [date or cadence]
Decision: [date]

Commercial terms
Pilot price: [amount and billing timing]
Continuation if approved: [offer, price or pricing basis, and start date]
If stopped: [access end, data return/deletion handling, and any final deliverable]

Agreement needed before work begins: [order form, services terms, confidentiality,
data-processing, security, or other review appropriate to the actual risk].

Price the pilot as the work it is. A concession may be rational when the test resolves an unusually valuable uncertainty, but make the concession explicit and temporary. Free, high-touch work hides willingness to pay and teaches the customer that founder labor is part of the free product.

Test the Proposal Against Real Work

Suppose the evidence-request tracker from the design partnership is now stable enough to evaluate. The pilot might cover one operations lead and the next three customer security reviews. The current baseline is the hours spent locating approved evidence and chasing owners. The outcome measure is the change in that effort; adoption is whether requests are actually processed through the tracker; the trust check is the rate of suggested evidence that the operations lead rejects; the founder-load limit is a fixed setup allowance and weekday email support window.

The customer’s existing repository remains the system of record, and its staff retain approval. Writing policies, answering questionnaires, storing credentials, and building customer-specific integrations are excluded. At the end of six weeks, the budget owner chooses the stated subscription or stops. The founder makes a separate decision: continue only if the account can be supported inside the promised boundary.

This example has room to fail. The tracker may save time but produce too many unsafe suggestions. Users may bypass it. The customer may value the result but require more service than the price supports. Each outcome teaches more than a vague report that the pilot “went well.”

Negotiate the Test, Not Just the Scope

When a customer requests another integration, user group, or workflow, ask which decision the addition enables. If none, defer it. When procurement delays the start, move the evidence and decision dates rather than quietly shortening the observation period. When the buyer wants an unpaid trial with no usage commitment, offer a demo or a smaller evaluation instead of calling inactivity a pilot.

Decline the pilot when the customer needs production assurances you cannot support, cannot provide representative users or inputs, will not name a decision owner, or expects bespoke delivery outside the product’s intended segment.

The proposal is ready when both sides can explain the same test: what work will change, what remains outside it, which evidence can support or defeat continuation, what each side must provide, what the pilot costs, and what happens on the decision date.