THE PRACTICAL GUIDES
Plan a first AI pilot with a clear handover
A useful pilot answers a specific question: can this approach improve this workflow under the conditions your team actually works in? Define that question before selecting tools or commissioning a build.
Write a one-page pilot brief
Name the workflow, its owner, the users and the systems involved. Record a baseline such as handling time, correction effort or completion rate. Describe the proposed change and decide which parts stay under human control. List the cases the pilot will not attempt to handle.
Agree the evaluation before the demonstration
Choose a representative set of examples, including difficult or incomplete inputs. Decide how outputs will be reviewed and which failures require escalation. Include the time spent checking and correcting output when measuring the result. A fast answer that creates substantial rework may not improve the process.
Make operating responsibilities explicit
- Who approves access to systems and data?
- Who checks outputs and handles exceptions?
- Who tracks operating costs and sets usage limits?
- Who maintains integrations and responds when a service changes?
- Who can pause the system and restore the previous workflow?
These questions help define the scope of delivery. A consultant’s governance service label alone does not establish which controls are included in your proposal.
Ask for a handover you can use
Request documentation, configuration and access arrangements, a walkthrough for the people operating the system, and a clear support period. Specify which changes the team can make independently and which need engineering support. Record outstanding limitations alongside successful results.
Decide whether to stop, revise or expand
Compare the pilot against its original measures. Identify whether weak results come from the approach, data quality, workflow design or adoption. Expansion should have its own scope and decision rather than following automatically from a successful demonstration.
Browse strategy, implementation and training providers for the capabilities your pilot needs. Use our checked engagement examples to distinguish discovery from a build.
A worked pilot: draft answers from an internal handbook
This is an illustrative design, not a client case study or a claim about typical performance. Suppose a team wants to reduce time spent finding answers in its current handbook. Start with draft answers for staff review. Exclude external sending, changing records and questions outside the handbook. Require a link to the passage supporting each answer and an explicit handover to a person when the source is missing or conflicting.
Select examples from the work the team actually receives. Include straightforward questions, ambiguous wording, an outdated instruction and a question with no answer in the handbook. Keep a separate set of unseen examples for the final check so repeated tuning does not merely memorise the demonstration.
Measure total handling time
For an invented set of 50 questions, assume the manual baseline averages 8 minutes each: 400 minutes in total. With the pilot, generation and checking average 3 minutes per question, or 150 minutes. Suppose 10 answers also need 6 minutes each of correction: another 60 minutes. Total assisted handling is 210 minutes, leaving 190 minutes saved, or 3 hours 10 minutes, on this test set.
Count correction time only once: this example treats it as additional to the initial check. Record unanswered cases and mistakes separately from time. A faster process that gives an unsafe or unsupported answer does not pass simply because the average improves. Do not multiply a small test's result into an annual saving without checking real workload, adoption and ongoing review effort.
Write the acceptance decision before building
- Evidence: every factual answer must identify a supporting source that the reviewer can open.
- Exceptions: the pilot must route missing or contradictory source material to the named reviewer.
- Quality: agree which errors require stopping the trial, and how lesser errors will be recorded.
- Time: compare total handling time, including checking, corrections and escalation, with the manual baseline.
- Operation: assign responsibility for handbook updates, failed integrations, usage costs and switching back to the manual process.
These are example acceptance topics. Choose thresholds for your workflow and its consequences rather than treating a generic percentage as safe.
Keep a decision record
Download the pilot brief and results record (plain text). Complete the baseline and acceptance sections before work starts. At the review, enter observed results, unresolved failures and the person responsible for each next step. The download is a blank local document; the site does not collect its contents.
Stop if the approach cannot meet an essential requirement. Revise if the cause is understood and another bounded test is justified. Expand only with a new scope covering the wider workload, users and support. A successful demonstration is evidence about that trial, not a production readiness certificate.
Before accepting the governance handover, use the policy-and-register commissioning guide to specify owners, working documents and an exercise your team can complete.
For demand planning, the forecasting commissioning guide adds a dated evaluation boundary, a simple benchmark and an original forecast-error example.
For a knowledge-answering service, the RAG commissioning guide adds citation checks, restricted and missing information, a twelve-case exercise and document-refresh handover.
Editorial guidance with linked sources. Reviewed 2026-09-30.