Use this brief when you have a plausible software or AI option and need to decide whether a bounded trial is worth running. It helps a business owner and delivery team agree what the pilot can establish, who checks the work and how to return to the current process. It helps structure the decision; specialist review may still be needed for consequential uses.
Go to the copyable pilot brief
Choose the decision the pilot will inform
Write down what you may authorize after the test: a wider trial, a purchase, further development or a decision to wait. Then name the uncertain assumption that could change that choice. “Try the technology” is too open to tell you whether the test was useful.
Describe the user, task and current result. Record a small baseline using the same kind of work the pilot will handle. Count the effort spent checking and correcting outputs as part of the new process. A faster first draft can still leave the task slower overall.
Limit the people, data and consequences
- Choose one workflow and an explicit group of users. List the actions they may take and the actions that remain outside the trial.
- Use synthetic or otherwise permitted data. Obtain the necessary permission before using real customer, staff or sensitive information; a small pilot is still a use of that information.
- Set a maximum duration, cost and staff effort. Reserve time for review and cleanup.
- State which outputs may leave the test environment and who must approve them. An internal draft and a customer commitment have different consequences.
Make human review part of the work
Name the person who checks an output, the reference they will compare it with and how a disagreement is resolved. For a runtime AI feature, include ambiguous input, unsupported answers and cases where the system should ask for help. For software built with AI but using ordinary business rules at runtime, verify the rules and resulting records in the same way you would for any application.
Choose reviewers who have the authority and time to make the decision. “A human will review it” is incomplete if the reviewer cannot see the evidence, cannot reject the output or has no time allocated.
Decide what happens when the normal path fails
Select a few exceptions that could change the decision: missing information, a rejected request, interrupted saving, an uncertain result or an unauthorized action. State what the user should see, who handles the case and where the unresolved work is recorded. Keep a manual route available for the bounded task.
Before a retry, establish whether the first action took effect. Where an action could create a duplicate or a customer commitment, pause for reconciliation if that cannot be determined. Do not make the first user invent the recovery procedure.
Agree the next-step and stop criteria in advance
Use observable criteria linked to the task, plus limits on errors and review effort. Record expected behavior and actual observations separately. Specify who may pause the pilot, how users return to the previous process and how any records created during the trial will be reconciled.
A successful small test can justify another bounded step. It cannot establish performance for every user, security for untested roles or readiness for a more consequential use. If the result is unclear, narrow the question or extend the evidence deliberately rather than moving the goalposts.
Worked hypothetical example: drafting service replies
This example and every quantity below are invented. They are proposed test choices, not a client story, observed result or recommended universal threshold.
A service team wants to know whether a drafting assistant could reduce the work of answering routine delivery questions. The current option is a staff-written reply using the same approved reference notes. The first test uses 12 synthetic inquiries, including four with missing or conflicting information. No reply may be sent to a customer.
One support reviewer compares each draft with the reference, records corrections and measures the combined drafting-plus-review time. A second reviewer resolves disputed answers. The assistant must leave uncertain cases for a person rather than inventing a delivery commitment.
The proposed decision rule is a wider supervised test only if every final reviewed reply is correct, no unsupported commitment is proposed, and total staff effort is lower than the comparison task. An unsupported commitment or data-access error pauses the test. If output quality is acceptable but review takes longer, the team revises the scope or keeps the current process. These are conditions agreed before a test, not findings.
Copy the pilot brief
Select and copy the plain text into your own document. It remains usable without JavaScript, a download or an account. Keep confidential details out of a shared brief.
Decision this test could change:
User and task:
Current process and comparison evidence:
Uncertain assumption:
Smallest workflow and allowed users/actions:
Excluded uses and outputs:
Permitted data and access owner:
Duration, cost and staff-effort cap:
Expected output and comparison reference:
Reviewer, authority and allocated review time:
Exceptions to exercise and their owners:
What happens when the result is uncertain:
Proceed to the next step if:
Revise or stop if:
Pause authority, fallback and record reconciliation:
Observed results and untested areas:
Decision owner, review date and next action:Turn the brief into a decision
Read the brief back to the people doing the work. If a critical field is unknown, name the person and evidence needed to resolve it before the affected action. At the review, compare the observations with the original criteria and choose proceed, revise, stop or gather more evidence. Keep the limits beside the decision.
Compare the investment options before choosing a pilot
Read about the promise when AI work crosses applications
Use the interactive companion
The builder follows the guide’s model. Your answers remain in this tab. The complete plain worksheet above remains available without JavaScript.