Price and scope your first paid pilot with AI
Turn a customer problem into a small paid engagement with explicit scope, a worked pricing example, acceptance checks, and a proposal prompt.

A first paid pilot should make a real buying decision possible and give you a manageable delivery commitment. The buyer needs to understand what they receive. You need to know what you are promising, what it takes to deliver, and what would count as complete.
We will scope a fictional proposal follow-up setup for one independent consultant. This is a teaching example, not a Waymaker offer, a market-rate recommendation, or a forecast of sales. If the problem is still unclear, start with customer interviews.
Before you start
Bring an observed customer problem, a realistic capacity estimate, examples of work you can deliver, and the buyer's current process. Use a document or spreadsheet and your existing AI assistant. Decide which parts you can complete yourself and which require expertise or access you do not yet have.
A pilot can be a service before it becomes software. You might improve a spreadsheet and a follow-up routine before building a dashboard. Choose the form that tests the buyer's problem with the least unnecessary work.
Choose one buyer, problem and deliverable
Write the buyer and the task in plain language: “An independent consultant who loses track of proposal follow-up.” Then describe a deliverable you control: “Set up a simple proposal tracker, draft two approved follow-up templates, and walk through the routine.”
Separate the desired business result from your commitment. The buyer may want more accepted proposals. You can commit to a functioning tracker and a usable routine; you cannot control how prospects decide. Use the result as something to learn about, not a guaranteed outcome.
Ask AI to list what must be true for the pilot to help. If the real problem is a weak offer or slow procurement, reminders alone may not fit. Return to the evidence before writing the proposal.
Draw the scope boundary
Specify what is included, what is excluded, and what the customer supplies. For the example: one tracker in the customer's existing tool; up to ten sanitized sample proposals for testing; two message drafts; one walkthrough; and one consolidated revision round.
Exclude CRM migrations, live bulk sending, prospect research, ongoing sales management, and guaranteed revenue. Those are different commitments. Identify the one person who approves the work and the date by which sample data and feedback are needed.
Write a change rule: if a new request changes the agreed deliverables or effort, record it and agree on scope, price, and timing before doing it. A narrow pilot is easier to buy and evaluate when the boundary is visible.
Estimate the whole job and test a price
Count discovery, preparation, delivery, testing, revisions, administration, and handoff. Include direct tool costs and a reserve for uncertainty. Your own time is a cost even if no cash leaves your bank account. A labor estimate is an internal planning tool, not evidence of what buyers will pay.
In our fictional arithmetic, eight hours at an internal value of $60 per hour is $480. Add $40 of direct costs and a $120 reserve: the planning cost is $640. A hypothetical $800 price leaves $160 before unallocated overhead and taxes. If actual time rises to eleven hours at the same value, that cushion disappears.
Compare the proposal with the customer's alternatives and the value of the specific problem. Ask for a real decision at a clearly stated price. Do not keep discounting in response to every hesitation; the problem may be timing, trust, scope, or fit.
Define acceptance and the delivery sequence
Make completion observable. “A better sales process” is hard to review. “The client can add a proposal, see the next follow-up date, change the status, and find the two approved templates” is testable. Include what happens when a date is missing or a proposal is closed.
Agree on the sequence: review the supplied sample, show a first working version, collect consolidated feedback, apply the agreed revision, and run the handoff. Set delivery dates after confirming dependencies. State payment timing and any cancellation or refund arrangements clearly in the actual agreement.
For the pilot's learning question, record a baseline and a review date with the client. Testing whether they can complete the routine is different from proving a sales lift. Strategyzer's Test Card is a useful reference for separating the assumption, test, measurement, and decision threshold.
Present one clear proposal and learn from the response
Ask AI to turn the approved inputs into a concise proposal, then compare every promise with your scope and capacity. Remove invented guarantees, made-up credentials, unsupported savings, and features you did not agree to deliver.
Present the outcome, deliverables, timing, price, responsibilities, and next step together. If the buyer declines, ask which part does not fit. Record the answer in their terms. Do not interpret silence as a definitive rejection of the problem, and do not treat a friendly conversation as an accepted proposal.
After an actual agreement, follow the delivery guide. At the end, compare estimated and actual effort and decide whether to repeat, narrow, reprice, or stop the offer.
Worked proposal: proposal follow-up setup
A repeatable follow-up routine for one consultant
- Deliverables
- One tracker, two approved message templates, one walkthrough, and one consolidated revision.
- Customer inputs
- Up to ten sanitized examples, access to the agreed tool, and one decision-maker for feedback.
- Schedule
- Five working days after required inputs and access are confirmed; feedback delays require a revised date.
- Example fee
- $800, with payment timing and cancellation terms agreed before work begins. This is an illustrative price.
- Acceptance
- The client can add an item, assign a next action, close an item, and find the approved templates.
- Excluded
- Bulk sending, migration, prospect acquisition, ongoing management, and revenue guarantees.
This outline supports a scope conversation. Add the terms appropriate to the actual engagement before accepting work. Do not let AI fill in commitments that neither party has discussed.
A prompt to adapt
Replace the bracketed inputs with information you can share. Review the result against your sources and the checklist below.
Draft a one-page pilot proposal using only these approved facts: [buyer, observed problem, deliverables, exclusions, dependencies, acceptance checks, schedule, price and agreed payment terms]. Separate the customer's desired business result from our delivery commitments. Mark missing information [TO AGREE]. Flag any scope conflict or unrealistic dependency. Do not invent guarantees, legal clauses, testimonials, discounts, or availability. Return the proposal and a short list of decisions needed before sending.
Your finish checklist
Use these checks before treating the output as ready.
- The buyer and problem are specific.
- Included work, exclusions and customer inputs are explicit.
- The estimate includes testing, revisions and handoff.
- Completion can be demonstrated with a task.
- Price, timing and commitments have been reviewed by a person.
Common questions
Should the first pilot be free?
Choose deliberately. A free discovery conversation can teach you about a problem, while a paid pilot tests a particular buying decision. If you offer an unpaid trial, cap the work and define what you need to learn; do not count it as willingness to pay.
Does one sale validate the business?
It supports demand for that offer from that buyer in that context. Repeat purchases, delivery economics and customers outside your immediate network require further evidence.
Keep the work moving.
Set up a small research, drafting and review workflow with role prompts, a handoff template, tool boundaries, and a worked founder example.