Choose a piece of work your team can define, review and own. A focused pilot should give you evidence for the next decision.
- Choose one recurring task
- Name an operating owner
- Agree the test before building
Start with a recurring piece of work
Describe the candidate in one sentence: who receives what input, what they produce and who accepts the result. Preparing a reviewed case summary is easier to scope than improving customer experience. Look for repeated friction that staff can show you in actual work, such as searching for information, reconciling inputs or preparing a draft. Check whether a clearer process, a rule or existing software could address the problem before deciding AI belongs in it.
Find the owner before the tool
Choose a person who is accountable for the operational result and can explain what good work looks like. They should help select examples, approve the acceptance criteria and decide whether the workflow is ready for wider use. Identify who will maintain source information, handle exceptions and help staff after launch. If ownership is unresolved, make that a prerequisite to the pilot. A sponsor who likes the idea may still need an operating owner to run it.
Compare value, feasibility and consequences
Consider the volume of eligible work, the effort it consumes and what an improvement would allow the team to do. Then examine data access, integration requirements and the difficulty of reviewing an output. Ask what happens if the result is wrong or a connection fails. A narrow task with accessible inputs and a reversible human review step can be a practical starting point. Record unresolved dependencies instead of hiding them inside a single opportunity score.
Prepare the test before the build
Collect representative examples with permission to use them. Include routine work, incomplete inputs, uncommon cases and situations where the system should ask for help. Keep some examples separate from those used to refine the workflow so the evaluation tests unfamiliar work. Define an accepted outcome, the permitted error level, review responsibilities and a stop condition. Record baseline handling time and corrections. The evaluation should reveal whether the process is useful at the required quality standard.
Keep the first scope easy to inspect
Limit the initial workflow to a defined group, input set and output. Make the human handoff visible and provide a fallback for work the system cannot complete. Test that the result reaches the place where staff need it, with enough context to act. Include training and operating instructions in the scope. Watch people use the workflow: awkward inputs, unclear ownership or extra checking can undo an apparently useful technical result.
Expand when the evidence supports it
At the agreed review point, compare accepted outcomes, staff effort, elapsed time and total cost with the baseline. Separate measured results from projections and ask whether the team can keep the workflow running. Review unresolved failures and the burden of maintaining sources or integrations. Choose the next step with the operating owner: improve the current scope, expand carefully or stop. The first workflow should leave you with evidence for that decision and a clearer understanding of what the team needs next.
Bring these five things
to the first conversation
Use this as a preparation checklist with the person who owns the work.
Further reading
Related guidance from the organizations below.
