Bring your team into the pilot

Begin with their process

Ask people to walk through a normal example and a difficult one. Look for repeated effort and workarounds. Explain the purpose of the test and what it will not decide. Avoid presenting a tool as a finished answer before the team has tried it.

A practical first session

1. Map: Draw the current steps and identify the task you will test.
2. Demonstrate: Use invented examples and show the draft alongside its source.
3. Challenge: Give the tool incomplete or contradictory input. Discuss what reviewers need to catch.
4. Practise: Have each reviewer use the same checklist and compare findings.
5. Agree: Record allowed use, prohibited inputs, the stop owner and the review date.

Make feedback easy

Keep a short log of confusing outputs, corrections and time spent. Encourage people to report problems without pressure to prove that the pilot works. A result that needs too much checking may not be suitable.

Document the working agreement

This pilot supports:
It does not decide or do:
Approved inputs and environment:
Who checks the output:
Who can stop the pilot:
Where issues are recorded:
Manual fallback:
Next review:

Revisit after change

A new task, source document, model or product setting can change the results. Retest representative examples and review the boundary before expanding use.