Scope an AI trial by defining one recurring task, its permitted inputs, an accepted result, a reviewer and a stop/go decision before buying tools. Through CPLT, I start with a free 45-minute remote scoping call and a one-page written note. Paid work has an agreed written scope and price. Include model/API usage, human review and operation in the full cost; a trial does not promise savings.
Which recurring task is worth examining?
Describe the work as an action with a beginning and an end: “Prepare a draft reply from an approved handbook for a person to check.” “Introduce AI across the business” is too broad to establish what was completed or what changed.
Record what triggers the task, who performs it today, how often it occurs and what happens when it is delayed. Use observed volumes and effort where available. Mark estimates as estimates and agree how to measure the missing baseline before comparing a trial with current work.
Start with the free task questionnaire. Describe the process without sending confidential documents in the initial enquiry. A scoping conversation can establish what needs investigating; it cannot establish performance on data that has not been tested.
What goes in, and what counts as finished?
Name the inputs and the output. An input might be a request and an approved source document. An output might be a draft that preserves the source's conditions and clearly identifies missing information.
Separate producing a draft from completing the business task. A reply waiting in a review queue is unfinished work, even if the model produced it quickly. Agree who may accept the result and what evidence they need to make that decision.
For an internal knowledge assistant, use the separate acceptance-check guide to specify source, access, missing-information and conflicting-version cases. This scoping guide establishes the task boundary; those tests establish how a proposed assistant would be judged.
Which data and actions are permitted?
List the sources the trial may use, the people allowed to access them and the systems that may receive their contents. Include model and embedding APIs, connected tools, logs and backups. A private workspace does not by itself establish a private data boundary.
Start with read-only retrieval or drafting where that fits the task. Sending a message, changing a record or approving a request each needs its own permission and acceptance checks. Do not treat permission to find information as permission to act on it.
If personal data is involved, review the API contract and data-processing questions before using it. Private hosting is optional and should follow the requirements, including who can operate it; it is not a substitute for deciding access and retention.
Who owns human review and exceptions?
Name the reviewer, the decisions reserved for them and the route for incomplete or disputed work. Agree what happens when the reviewer is unavailable. A queue without an owner can move effort around without making the task easier to complete.
Record when the workflow must pause: an unreadable input, an unresolved source conflict, missing permission or a proposed action outside scope. Keep a manual way to complete the task while the issue is investigated. Include review and correction effort in the trial record.
What should the one-page scope contain?
The initial note should make the next decision clear. A paid trial may need more detailed acceptance cases and delivery terms before work begins.
| Scope item | What to write down |
|---|---|
| Task and owner | Trigger, current process, frequency and person responsible. |
| Inputs and data boundary | Permitted sources, user access, processing routes and retention questions. |
| Output and acceptance | What a usable result contains, who accepts it and what remains unfinished. |
| Actions and human review | What the tool may do, what needs approval and where exceptions go. |
| Trial boundary | Agreed cases, duration or volume limit, excluded work and change procedure. |
| Full cost | Build price, model/API usage, hosting, review, correction, maintenance and support. |
| Stop/go decision | Evidence needed to continue, reasons to revise or stop and who decides. |
| Handover | Operating owner, runbook, source updates, access management and recovery procedure. |
Fictional illustration, not a customer case or an executed trial: a workshop coordinator wants draft answers to questions about booking changes. The proposed trial uses an invented handbook and fictional requests. It may draft a reply with its source, but it may neither approve a booking change nor send a message. The coordinator reviews each draft; missing rules return to the coordinator. No result, time saving or accuracy rate is claimed by this example.
How much should the trial cost in full?
Agree a limit on paid work and usage before starting. Count implementation, model/API usage, hosting, human review, correction and operation. Consumer chat subscriptions and API usage are different purchases; verify the accounts, keys and billing needed for the proposed setup.
Use the cost per accepted result method for the calculation and treatment of unsuccessful attempts. Compare equivalent work at the required quality. Time released is capacity; cash is saved only when spending falls. Faster drafting alone establishes neither saving nor payback.
When should you continue, revise or stop?
Write the decision criteria before seeing the trial's output. Continue only when the agreed evidence supports a useful result, acceptable full cost and an operating arrangement the team can maintain. A successful demonstration is not a commitment to expand the scope.
Revise the scope if the main obstacle is an unclear source, missing permission or an unowned review step. Stop if the task cannot be judged, the required data route is unacceptable or the total effort does not justify the proposed approach. A shared document, template or existing tool may be enough.
At handover, record limitations, operating responsibilities and the checks to repeat when sources, models or integrations change. Passing the initial cases does not guarantee future behaviour.
What happens in CPLT's free scoping call?
I work remotely from the EU, one engagement at a time. Bring one recurring task to a free 45-minute scoping call; you receive a one-page written note on fit and next steps. No confidential files are needed for the first conversation.
The note may recommend an existing tool, a change to the process, a bounded trial or no build. A trial or build is a separate paid decision, with written scope and price, agreed human checks and handover with a runbook. See CPLT's assistant and automation services for the delivery options.