Scope a Paid Pilot

A paid pilot is a small, bounded piece of real work that tests whether a buyer will pay, whether you can deliver, and whether the result creates a reason for more work. It is not a free custom project with a promise of future payment. Nor is it a miniature version of a large agency contract with every possible feature included.

The pilot should be short enough to start soon, small enough to deliver well, and real enough that the buyer receives something useful even if no second engagement follows. Both sides should know what the pilot is testing.

This chapter uses the one-page offer from the previous chapter and turns it into a controlled first engagement.

Decide What the Pilot Is Testing

Write one primary learning question. Common questions include:

• Will a buyer pay for this defined result rather than ask for a free sample?
• Can the result be delivered within the promised time with acceptable quality?
• What does the buyer do with the result, and what questions remain?
• Does the workflow expose a privacy, access, or review problem that must be solved before repeat work?
• Does the direct cost and delivery time leave room for a sustainable price?

Do not claim that one pilot proves a market. It is one observation. The value is that it replaces speculation with a paid transaction, a completed result, and a record of what happened.

Use One Trigger and One Job

Scope from the buyer's actual trigger:

• The next event.
• The next month-end close.
• A backlog created by one named team.
• A new customer onboarding cycle.
• A single report that must be repeated.

The pilot should begin with a real input that already exists or will exist on a known date. If the buyer cannot identify the input or the deadline, the problem is not operational enough for a short test.

Keep one primary job. A pilot that includes research, strategy, implementation, training, and ongoing support cannot reveal which part creates value or which part caused delay.

Set the Pilot Boundaries

A practical pilot statement includes:

• Start condition: what must be true before work begins.
• End date or number of business days.
• Deliverable and format.
• Input volume and source.
• Review rounds and response deadlines.
• Customer responsibilities.
• Exclusions.
• Acceptance evidence.
• Price and payment timing.
• Pause, cancellation, and change rules.

Use both a date and a cap where possible. "Two weeks, with a maximum of one transcript and four approved sequences" is easier to manage than "about two weeks." It gives the work an edge even when the buyer moves slowly.

Make the First Milestone Small

Break the pilot into three or four visible states:

1. Kickoff and input check: Confirm the result, input quality, access, and owner.
2. Draft or first result: Produce a reviewable artifact early enough to correct course.
3. Review and correction: Address comments within the agreed limit.
4. Handoff: Deliver the final files, evidence of completion, and a short learning note.

The first milestone is not a free sample. It is the beginning of paid work. Its purpose is to catch missing data and mismatched expectations before they consume the whole schedule.

For a complex pilot, add a stop point after the first milestone. If the input is unusable or approval cannot be reached, stop without pretending the original promise is still possible.

Define Customer Dependencies

Delivery speed depends on the buyer. State what you need:

• A named reviewer.
• A decision within a stated number of business days.
• Clean access to approved source material.
• Confirmation that a data set can be used.
• A response to one blocking question.
• A final acceptance decision.

If the buyer misses a dependency, the timeline should move by the same amount or the scope should change in writing. This protects both parties from treating an internal delay as a delivery failure.

Keep a dependency log with date, owner, request, response, and effect on the timeline. The log is more useful than a memory of a friendly conversation.

Control the Inputs

The pilot should use the least sensitive information necessary. Decide:

• What data is required.
• Why each field is needed.
• Where it may be stored.
• Who may access it.
• Whether an AI provider may process it.
• How long it will be retained.
• How it will be returned or deleted.

Do not accept a "send everything and we will figure it out" input. If a sample can answer the question, use a redacted sample first. If the buyer needs a result on the full data set, confirm the required security and contractual conditions before receiving it.

Set a Review Limit

Reviews can expand without a visible boundary. Define:

• The number of review rounds.
• The response time for each round.
• Who has authority to consolidate feedback.
• What counts as a correction versus a new request.
• What happens after the final round.

A useful rule is that approved scope changes are written down, priced, and scheduled separately. The rule should apply to you as well. Do not add a new deliverable merely because it is easy to squeeze in; that hides the true cost of the offer.

Measure Delivery as You Go

Track these headings from the first day:

• Start and finish time.
• Customer-facing work.
• Internal review and correction.
• Administrative time.
• Direct tool or production costs.
• Customer waiting time.
• Rework and reason for rework.
• Inputs that were missing or unusable.
• Questions the buyer asked.

Keep the record simple enough that you will actually use it. A spreadsheet or text log is enough for one pilot. The purpose is to see whether the price and process can survive repeat delivery, not to create unnecessary administration.

Time tracking is evidence, but it is not perfect. Record how you measured it and note estimates. If you use an AI tool, include the time spent checking, correcting, and preserving sources.

Choose a Pilot Price Deliberately

The pilot should be paid. A price below cost can make a buyer look committed while teaching you the wrong economics. A high fixed price with an unclear result creates risk for both sides.

For the first few pilots, use a fixed price for a fixed result where possible. Estimate the internal floor from delivery time, direct costs, administration, review, and contingency. Then compare that floor with the value evidence and alternatives gathered from the buyer.

Do not promise a revenue increase, hours saved, or legal compliance to justify the price. If the buyer gives you a value estimate, record it as their estimate. A pricing method is explained more fully in the next chapter.

Design the Learning Note

At handoff, deliver a short note covering:

• What was promised.
• What was delivered.
• What evidence shows completion.
• What the buyer must still decide or do.
• What exceptions or unresolved items remain.
• What the next small result could be, if the buyer wants one.

The note should not turn into a hidden sales pitch. Its first job is to make the completed work easy to evaluate. A next-step option can follow once the buyer has confirmed the result.

A Worked Paid Pilot

The following is an illustrative composite. It continues the offer from the previous chapter but does not describe a real client.

Nina's full offer is $1,450 for twelve follow-up drafts across four customer moments. She decides that the first paid pilot should test the most important uncertainty: whether the buyer will pay for source-checked drafts and whether the workflow can fit inside five business days.

The pilot statement is:

> Nina will prepare twelve follow-up email drafts across four customer moments from one approved workshop transcript and one program-notes file. The buyer will identify the moments, remove unnecessary personal details, and complete two reviews by the stated dates. Nina will deliver an editable document and a source-note file by the end of the fifth business day after a complete input check. The buyer will confirm the four sequences and note any unresolved corrections. The pilot excludes sending, list management, legal review, public posts, and a guaranteed response rate. The illustrative fee is $1,450, with the payment schedule stated in the written agreement.

The pilot has four milestones:

1. Input check on day one.
2. Drafts shared on day three.
3. Corrections completed after the first review.
4. Final handoff on day five.

Nina logs time and questions. She discovers that most of the work is not drafting; it is checking names, dates, and claims against the transcript. She adds a source-check column to the handoff and records that the review round took longer because two customer moments were described differently by different staff.

The learning is useful even if the buyer does not continue. Nina now knows that the workflow needs one approved moment list, a privacy check, and a clear review owner. She can revise the next offer with evidence instead of guessing.

Stop Conditions

Write down when the pilot should pause or stop:

• The buyer cannot provide lawful access to the required source.
• Inputs are materially different from the agreed scope.
• The buyer requests a regulated decision or action outside your competence.
• A privacy or security issue appears.
• The customer cannot name an approval owner.
• The promised result becomes impossible within the calendar.

Stopping is not a failure if it protects the quality and legality of the work. Explain the condition, preserve the evidence, return or delete data as agreed, and discuss whether a revised pilot is appropriate.

Your Chapter Exercise

Take the one-page offer and build one pilot around it:

1. Write the primary learning question.
2. Select one trigger, one input, and one primary job.
3. Define the start condition and end date.
4. List the deliverable and acceptance evidence.
5. Add two review rounds, their owners, and response times.
6. List exclusions and customer dependencies.
7. Set a price and payment timing.
8. Add a change rule and at least three stop conditions.
9. Estimate the time and direct cost you will track.
10. Ask a peer to identify any sentence that could mean two different things.

Chapter Deliverable

Create a one-page pilot brief containing:

• Learning question.
• Buyer, trigger, and current workaround.
• Deliverable, deadline, and acceptance evidence.
• Inputs, privacy limits, and customer responsibilities.
• Milestones, review rounds, and change control.
• Price, payment timing, and stop conditions.
• Metrics you will record at handoff.
• A data return or deletion plan.

Source and Decision Caution

A paid transaction is useful evidence, but it does not establish a large market, durable demand, or a safe business. Record the sample size and the conditions under which the pilot occurred.

Contract, payment, consumer, tax, privacy, security, and professional-licensing rules vary by jurisdiction. Use appropriate template review and qualified advice for the actual agreement, especially when a pilot involves sensitive data, regulated activity, or a consequential decision.

AI outputs can contain fabricated citations, personal information, or instructions that look authoritative. Verify source material, use approved tools, and keep a human accountable for final quality. Do not upload client data to a service that the buyer has not approved.

The next chapter turns the pilot economics into a price that reflects the result, the risk, and the accountability attached to delivery.