How to Scope an AI Service Pilot: Deliverables, Review and Acceptance Criteria

A useful AI service pilot is a small delivery agreement. It says what you will accept as input, what you will hand over, who checks the work and when to continue, revise or stop. Keep the first delivery small enough to inspect every result.

If you are still unsure whether a buyer wants the outcome, start with the validation guide. This guide answers the next question: can you deliver one agreed result under workable conditions?

Start with a completed pilot brief

Here is a fictional example for a catalog-writing service. The buyer wants ten editable product descriptions from approved specifications. The goal is to evaluate useful drafts and review effort before investing in a store integration.

The quantities, timing and budget are planning choices for this example, not market standards. Replace them with limits that fit your customer and the work.

The brief is useful because it settles ordinary disagreements before they happen. A second language is additional scope. Correcting an invented specification is a defect. Those should not become the same conversation.

Decide when the work is ready to start

Use an input checklist. Confirm the product records, approved sources, permitted claims, brand examples and reviewer are available. Start the delivery clock when that package is accepted, rather than assuming missing information will arrive later.

For a product with no verified dimensions, record “dimensions not supplied” and pause that claim. Do not fill the gap with a plausible number. Ask the buyer whether to supply the missing source, omit the claim or exclude that item from the batch.

Agree on permission to process the material and how it will be stored and retained. Use approved samples while tool settings or contractual protections remain unresolved. A small pilot should not require casually sharing a whole customer database.

Give review a person and a method

The delivery owner prepares the drafts and checks them against the supplied records. The buyer's reviewer then checks usefulness, wording and suitability for the intended job. Name the person who accepts the final batch so a chain of informal comments does not become an undefined approval process.

For this catalog pilot, acceptance could require:

• Every factual statement matches an approved source.
• All ten products have a draft or an explicit blocked status.
• Drafts follow the agreed columns and word range.
• Unsupported claims are corrected before an item is accepted.
• The reviewer records correction time and the reasons for substantial rewrites.

Keep blocking defects separate from preferences. One invented measurement matters even if the other nine drafts look good. If the same failure could affect the whole batch, inspect the other items before delivering them.

A second pilot might need different checks. For meeting summaries, a reviewer could compare every assigned action with the authorized transcript and flag ambiguous speakers. The acceptance method should follow the actual deliverable.

Track time before the ceiling disappears

Include intake, source preparation, generation, checking, revisions, support and exceptions. Separate initial setup from repeat delivery so you can see what a second order would really require.

In a fictional calculation, six delivery hours at an internal $40 hourly cost plus $25 in variable tools totals $265 before acquisition, overhead and taxes. Against a $300 direct-cost ceiling, that leaves $35 of headroom. One more hour would exceed the ceiling.

Agree on what happens before that point: report the cause and propose a smaller batch, revised timing, an approved paid change or a stop. Do not quietly continue and surprise the buyer with a larger bill. Track the buyer's checking time separately; shifting effort onto the customer can make a fast service unhelpful.

Hand over a package someone can use

Deliver editable drafts, their source references, unresolved exceptions and the acceptance record together. Include the agreed retention or deletion date. Make rights to customer inputs, created outputs and reusable materials clear in the agreement.

Acceptance of drafts does not authorize publishing them, sending messages or connecting the workflow to production. Keep the person responsible for that next action explicit. For the catalog example, the ecommerce manager can accept the batch while the store owner separately controls publication.

Agree on a review window and how disagreements will be resolved. Do not assume silence means acceptance. Clear terms make a small pilot easier to manage for both sides.

Finish with a decision

Continue with the narrow offer when the output is accepted, review effort is tolerable and delivery fits the limits. Revise the inputs or scope when the buyer values the result but the process is too expensive. Keep it manual when expert judgment still does essential work you cannot specify reliably. Stop when permissions, inputs or recurring defects prevent a responsible delivery.

Use the accepted record as a build brief: input fields, output format, roles, exception states and cost limits. It tells a developer far more than “automate our catalog.”

If you need help organizing the original idea, view the sample playbook. If the pilot has clarified what deserves software, read the MVP hiring guide. Start your next pilot by agreeing on one deliverable and one completed worksheet.