The first task has to be repeatable and reviewable
First-pass analysis of code defects, tidying project material, ticket triage and fixed-format reports are the easiest places to establish a baseline.
Prefer work the team does every week, with stable inputs and a clear definition of done, where the owner can judge whether a result is acceptable and a failure will not disrupt production.
Rolling out to the whole company at once, or connecting many systems at the same time, makes it hard to tell whether a problem belongs to the product or to the process.
Record how the work is done today
Without a baseline, the end of the pilot can only be judged by impression. Observe the current process a few times and record:
- total time from receiving the task to finishing it;
- hands-on time and waiting time;
- how often it is reworked, and the common errors;
- the cost of current tools, models and execution resources;
- who accepts the result, and what counts as passing.
Where quality resists a single score, use a checklist instead: fields complete, sources checkable, format correct, key conclusions confirmed by the owner.
Run it for four to six weeks
A demo can pick ideal inputs; daily work cannot. A continuous run meets unusual inputs, permission requests, model variation and failed tasks, and it also shows whether people choose to keep using it.
Every run links to the task, the originator, the project, the model, the usage and the result. The team reviews rework, failure causes and new requests that fall outside the agreed boundary each week. Which dimensions usage has to carry is covered in managing multi-model usage, quota and cost.
Acceptance covers efficiency and control together
Compare time, rework, cost and pass rate on the terms set beforehand. Then check whether identity is clear, whether permissions can be withdrawn, whether usage attributes to the task, and whether there is a way to pause or take over when something goes wrong.
Expand if the result fits, adjust and retry if it does not. When the data says the scenario is wrong, stopping is also a result.
What a pilot should leave behind
- a named team and business owner;
- one or two frequent, reviewable tasks;
- the baseline and the risk boundary recorded beforehand;
- configured projects, people, models, tools and permissions;
- a continuous run with a weekly review;
- acceptance on the original terms;
- a written conclusion to stop, adjust or expand.
Common questions
How should the first pilot task be chosen?
Pick work the team does every week, with stable inputs and a clear definition of done, where the owner can judge the result and a failure will not disrupt production.
What has to be recorded before the pilot starts?
Total time from receiving to finishing, hands-on and waiting time, rework frequency and common errors, the cost of current tools and models, and who accepts the result on what terms.
Why run it for four to six weeks?
A demo can pick ideal inputs and daily work cannot. Only a continuous run meets unusual inputs, permission requests, model variation and failures, and shows whether people keep using it.
Is efficiency enough at acceptance?
No. Also check whether identity is clear, whether permissions can be withdrawn, whether usage attributes to the task, and whether there is a way to pause or take over when something goes wrong.
Tell us how the work is done today
Describe the current process and the thing that is hardest to keep track of, and we will confirm the pilot scope and what it delivers.
Ask about a pilot