Run a paid pilot you can learn from.

Know what this pilot can tell you

One payment shows that one customer accepted one offer. It does not establish repeat demand or prove that the work will be profitable. A pilot helps you replace specific assumptions with observations before repeating the offer.

Still deciding what to sell or charge? Define the offer before using this delivery workflow.Price a service, including revisions.

1. Confirm the brief before kickoff

Put the accepted scope, customer inputs, dates, and review process in one place. Ask the customer to resolve any mismatch before work starts.

This brief organizes delivery; it is not a complete service contract. Keep it beside the accepted offer. If inputs arrive late or access is missing, explain the effect and agree on revised dates instead of pretending the original plan still works.

2. Separate completion, usefulness, and economics

Choose evidence for each of these questions before you deliver. Do not use a satisfied customer as a substitute for checking your costs.

Nina promises the agreed setup, not a guaranteed number of hours saved. A working form can pass its completion checks even if too few bookings occur to judge its benefit. Record those as two different results.

3. Write checks the customer can perform

Turn each deliverable into an observable check. Agree on the checks with the customer, then record a result and evidence for each one.

• The intake form contains the approved questions and required fields.
• A sample submission arrives at the destination agreed in the brief.
• Each of the three email templates contains the approved information and clearly identifies anything the photographer must replace before sending.
• The photographer can complete a sample booking workflow using the handoff instructions.
• The collected feedback round has been addressed, with unresolved items listed explicitly.

Use a sample submission without real client details when possible. Record who checked it, when, what happened, and any remaining issue. “Looks good” alone does not show which part was tested.

Atlassian describes acceptance criteria as specific, testable completion conditions agreed before implementation. The checklist here adapts that project-management principle to a small service engagement.Writing acceptance criteria — Atlassian.

4. Record customer use with a consistent method

Define the measure, baseline, and observation window together. Compare similar cases and keep missing observations visible.

Nina and the photographer define administration time as active minutes spent collecting booking details and preparing the three messages. It excludes waiting for replies and unrelated editing work. They use the same timer method before and after the setup, and note unusual cases.

In this fictional pilot, they record five comparable bookings before setup and five afterward. The observation window is separate from the five-day delivery schedule. They agree its end date in advance; if too few bookings occur, the benefit remains unconfirmed rather than being filled in with estimates.

The observed difference is six minutes per booking. These small, hypothetical groups do not prove that the setup caused the difference or predict future savings. Different clients, easier cases, and practice could also affect the result. Ask what the customer actually used and what still required help.

GOV.UK's service-measurement guidance supports establishing a baseline and agreeing how benefits will be measured. Its original context is public services; this example applies the measurement method, not government rules, to a small business.Measuring service benefits — GOV.UK.

5. Keep an issue log during delivery

Record problems against the agreed checks. Separate corrections to promised work from requests for additional work, and confirm the next action.

Use the existing quote to classify an extra request, then calculate and agree on any addition before doing it.How to price a change request.

6. Hand over work the customer can use

Review the deliverables with the customer. Have them try the instructions, then record completion, open items, and the support boundary.

• Share the agreed deliverables and their current locations or versions.
• Provide short instructions for using and editing the setup.
• Confirm that the customer controls the accounts and files they need.
• Review each acceptance check and list any unresolved limitations.
• Observe the customer completing the sample workflow; clarify the instructions where they get stuck.
• Confirm the included support, contact route, and end date. Remove temporary access when the agreed work no longer requires it.

Record the customer's response. If a check fails, state the correction and review date. If the customer has not reviewed the work, record that the review is pending; silence is not evidence that the setup is usable.

7. Compare actual delivery effort with the estimate

Add preparation, delivery, revisions, handoff, and support time. Use the same cost assumptions as the quote so the comparison is understandable.

This modeled surplus includes an allowance for owner compensation and excludes income tax and any omitted costs. It is not accounting profit. The $50 rate, overhead allocation, and 4% fee are assumptions from the pricing example; replace them with your own figures.

8. Close the pilot with an explicit decision

Write separate customer and founder conclusions. Choose a next action from the evidence, including stopping or waiting when that is appropriate.

• Complete and stop: the customer has the agreed result and needs no further work.
• Resolve an open item: name the failed check, correction, owner, and review date.
• Keep learning: identify the unanswered question and a specific observation needed. Agree on any extra work separately.
• Discuss a new engagement: define its value, scope, price, and terms. A completed pilot does not authorize another sale or charge.

Your paid-pilot delivery worksheet

Copy this record for each engagement. Keep observations separate from assumptions and link evidence to the accepted offer.

Pilot question and offer

Uncertainty to test: ____. Accepted offer/version: ____. Customer and owner: ____. Deliverables: ____. Exclusions: ____.

Inputs and dates

Required inputs/access and owner: ____. Agreed start: ____. Delivery: ____. Feedback: ____. Handoff: ____. Support end: ____. Payment arrangements reference: ____.

Acceptance checks

Deliverable: ____. Observable check: ____. Reviewer/date: ____. Result and evidence: ____. Open item: ____. Repeat for each check.

Customer-use measure

Measure and exact definition: ____. Baseline dates/count/observations: ____. Pilot-use dates/count/observations: ____. Missing or different cases: ____. Customer feedback: ____.

Issues and changes

Observation/date: ____. Affected check: ____. Correction or additional request: ____. Owner/action: ____. Agreed scope/timing changes: ____. Status and evidence: ____.

Delivery economics

Estimated hours: ____. Actual hours by activity: ____. Compensation assumption: ____. Expenses: ____. Overhead: ____. Fees: ____. Price: ____. Modeled result: ____. Omitted costs: ____. Cause of any difference: ____.

Handoff

Deliverables and locations: ____. Instructions: ____. Customer access confirmed: ____. Sample workflow result: ____. Limitations/open items: ____. Support boundary: ____. Customer response: ____.

Closeout decision

Customer conclusion: ____. Founder conclusion: ____. What remains uncertain: ____. Next action and owner: ____. Review date: ____. Any further engagement agreed separately: ____.

Plain text. Open it in any text editor or paste it into your notes.

Your next action

Take one accepted offer and write its completion checks. Confirm those checks and the required inputs with the customer before kickoff.

• Price the work and define revision boundaries
• Find a suitable first customer
• Separate demand evidence from assumptions