Paid Pilot Plan

A Paid Pilot Buys a Decision

A small agency agrees to pay for a pilot, then asks whether it can include a second advertising platform, a custom report format, historical data cleanup, and a presentation to the agency’s client. The first revenue feels close. Saying yes to everything feels like momentum.

It would also make the result almost impossible to read. If the agency is pleased, did the product promise work, or did the founder win through custom service? If the pilot fails, was the core outcome weak, or did four extra obligations consume the time needed to deliver it? Money makes the customer’s commitment more consequential; it does not make an ambiguous experiment clear.

A paid pilot is a bounded commercial experiment. It asks whether a particular buyer will fund a particular outcome and whether the operator will use that outcome in real work. It also exposes what free access can hide: approval, onboarding, data access, delivery cost, support load, and the terms under which the customer would continue.

Use one after discovery has found an urgent workflow, the person with budget can participate, and the founder can deliver the narrow promise safely. Return to discovery when the buyer, outcome, or current workflow is still vague. Decline or reshape a pilot when it requires a private roadmap, an unsupported trust promise, or more simultaneous delivery than one founder can observe and sustain.

Payment proves that one buyer crossed one purchasing threshold. It does not prove repeated use, renewal, healthy economics, or product-market fit. The pilot must be designed to reach those next questions rather than borrow their meaning.

Write the Brief Before the Work

Bring the buyer interview notes, pricing hypothesis, product thesis, onboarding path, support boundary, and the evidence from the preceding experiment. Then write the operating agreement in language the buyer, operator, and founder can all inspect. Align it with the invoice, order form, contract, or other commercial terms that actually govern the work.

PAID PILOT BRIEF

DECISION
Question this pilot must answer:
Review date and decision owner:
What payment alone will not establish:

FIT
Target company, segment, and triggering event:
Buyer and budget authority:
Operator who will perform the workflow:
Current alternative:
Conditions that make an account ineligible:

PROMISE
One outcome the customer is buying:
Value event the operator must complete:
Number and natural rhythm of delivery cycles:
Start date, finish date, and pilot fee:
Payment timing and any explicit concession:

BOUNDARY
Customer inputs, owners, formats, and due times:
Included users, workflow, data, output, and support:
Manual work the founder will perform openly:
Excluded features, integrations, migration, and services:
Support channel, response window, and escalation path:
Founder hours or concurrent-pilot ceiling:

EVIDENCE
Activation event:
Repeated behavior to observe:
Acceptance or quality standard:
Founder setup, delivery, correction, and support time:
Exceptions, rescues, reminders, and custom requests to log:
What the operator and buyer will each review:

END
Success result and next offer at its stated price:
Result that changes the segment, promise, or workflow:
Result that stops delivery or prevents extension:
Cancellation, refund, access, export, and data-removal terms:
Final review meeting and decision: renew / redesign / stop

SIGN-OFF
Buyer:
Operator:
Founder:

The brief has three separate centers: the purchase, the use, and the operating burden. A buyer may approve the fee while the operator never enters the workflow. An operator may value the result while the founder spends six unrecorded hours creating it. A smooth delivery may still end without renewal because the business consequence was weak. Keeping these lines separate prevents one encouraging fact from speaking for the whole pilot.

Price the Experiment You Can Actually Deliver

The pilot fee should correspond to a bounded result, not to access to the founder’s week. State the deliverable, number of cycles, customer responsibilities, support window, and end date beside the price. If a discount buys something useful—faster access to representative data, a shorter approval cycle, structured feedback, or permission to use an agreed case study—name the exchange and the normal next price before work begins. A concession made only to avoid a refusal weakens the pricing evidence and often returns as a renewal dispute.

Customer effort belongs in the terms too. A pilot that requires data by Monday, an operator at the review, and feedback within one business day has not succeeded when the founder quietly supplies missing context and chases every response. Those rescues may be sensible once. Record them as part of the result rather than hiding them inside good service.

Set a capacity limit before recruiting. Two pilots that each require three founder hours a week are a different product from eight pilots that appear to require the same effort until they all need help on Friday. The ceiling can be a number of accounts, delivery cycles, support hours, or concurrent datasets. Pause new intake when it is reached. Founder overload changes delivery quality and makes customer behavior harder to interpret.

Let Requests Reveal the Business

A pilot customer will discover needs the founder did not predict. The right response is neither automatic refusal nor automatic scope growth. Put each request in one of four places.

• Correct the delivery when the request exposes a failure to meet the written promise.
• Record product evidence when the same need is likely to recur for the intended segment, but keep it outside this pilot unless the test cannot proceed without it.
• Quote a separate, time-boxed service when the work is valuable but not part of the repeatable product.
• Refuse work that creates an unsupported security, privacy, reliability, integration, or support obligation.

Do not redefine success after accepting a request. If the added work changes the outcome, term, price, evidence, or founder burden, revise the brief explicitly or end the current experiment and design another. A change log is more honest than a pilot that appears on time only because its finish line kept moving.

Trace One Pilot Through Two Real Cycles

Continue the modeled agency test from the landing page plan. The founder offers one small paid-search agency a two-week pilot covering one client account. For a fixed fee, the agency supplies the campaign-change export and account context each Monday. The founder returns a source-linked pre-report review on Tuesday, identifying changes that still lack a defensible client explanation. Automatic report writing, additional platforms, historical cleanup, and client presentation are excluded.

The operator is the account lead; the agency owner approves payment. Success requires the account lead to use the review before both weekly client reports and choose to continue at the stated monthly price. The founder will record intake problems, corrections, support contacts, and delivery time. The second review must take no more than forty-five founder minutes. This last boundary matters because a useful result produced by limitless interpretation would support a service offer, not yet a repeatable product.

The invoice is paid. In the first cycle, the account lead sends an export but omits the internal change notes needed to distinguish planned adjustments from unexplained ones. The founder asks three questions and spends ninety minutes on the review. The lead uses the result, but the onboarding path has failed.

The founder does not add a dashboard. Instead, the intake instructions gain a short example and a required change-note field. In the second cycle the lead supplies complete inputs, the review takes forty minutes, and the lead again uses it before drafting the client report. The owner asks to continue for one active client workflow at the price named before the pilot. A request for automatic report writing remains outside the offer.

This is encouraging evidence with limits. One buyer paid, one operator repeated the behavior, the delivery burden fell after a reusable intake correction, and the customer accepted the next price. The pilot has not established that another agency will buy, that the workflow will retain over months, or that the review can be delivered without founder judgment. The next test is another comparable account under the same promise and boundary—not a general reporting platform.

Had the owner paid while the account lead never used the review, the pilot would have shown purchase without activation. Had both reviews required ninety minutes of private reconstruction, it would have shown demand for expert service. Had the lead used both reviews but refused the stated continuation price, the founder would need to examine value, package, budget, or buying authority. None of those outcomes becomes clearer by extending the calendar.

End Where the Evidence Ends

Hold the final review on the date written in the brief. Compare the observed purchase, operator behavior, delivery load, support, exceptions, and renewal decision with the original boundaries. Then choose one next move: repeat the same pilot with a comparable customer, narrow the segment or promise, productize a stable step, offer a bounded service, or stop.

Do not leave a successful customer on indefinite pilot terms. Renewal should name the continuing outcome, price, support boundary, and what changes from the experiment. Do not extend a failed pilot merely because both sides were busy. An extension is justified only when a specific external interruption prevented the planned behavior and the original question remains intact.

The plan is ready when the buyer knows what is being purchased, the operator knows what they must do, and the founder knows which work is included, how burden will be measured, and what decision occurs at the end. A paid pilot earns its place when the money sharpens the test and the test can still deliver an unwelcome answer.