A good first pilot is bounded and testable.
Look for a workflow that occurs often enough, uses accessible information and has a clearly defined output. Your team must be able to distinguish correct from incorrect. For example, start with draft answers on one approved topic rather than an agent expected to resolve every employee question independently.
An AI pilot tests an assumption. It does not yet prove benefits across the company. Choose a scope that allows errors to be identified, effects contained and outcomes compared with the current workflow.
Six questions to select a workflow.
1. Frequency and effort: how often does the task occur, and where does time go? Distinguish searching, transferring, deciding and approving. A rare problem may matter but provide too few comparable cases for an initial test.
2. Need for interpretation: do inputs vary and require context? If inputs and rules are already unambiguous, first consider a form or deterministic automation. Using a language model is not an end in itself.
3. Sources and access: is the information current, discoverable and approved for this purpose? Clarify permissions and interfaces before implementation. Missing knowledge should be recorded as an unresolved prerequisite.
4. Assessable output: can a responsible subject-matter expert judge whether a draft is correct and complete? Define typical cases, missing information, conflicting sources and failure cases. Successful technical execution alone is not a quality criterion.
5. Bounded effects: can the pilot prepare work before making binding changes? Define approvals, handovers and a way back. Consequential decisions require separate assessment and should not be included in a first pilot without review.
6. Ownership and capacity: who maintains sources, checks results and decides the next step? Without clear ownership and time for testing, even a technically simple task is a poor starting point.
Three possible starting points, each with a boundary.
HR knowledge: prepare expense-policy answers from a current, approved source and cite it. Personal exceptions go to HR. Maintained content and appropriate access permissions are prerequisites.
Order confirmation: compare order details with messages and flag a different delivery address. An authorised person confirms the change. A plausible address suggestion is not verification.
Invoice approval: bring together invoice, purchase order and goods receipt, flagging missing evidence. The pilot prepares the review; payment and bank-detail changes are not automatically included. These three workflows are illustrative examples, not reports of completed client projects.
Describe the pilot on one page.
Record the task, start and end, data sources, allowed actions, exclusions and owners. Add test cases and name the person who will accept the result. Use only data approved for the intended test.
Define the decision before testing: which errors are unacceptable? What quality is required? How much extra review is acceptable? What would indicate that deterministic automation or better data is the more suitable next step?
When to expand and when to stop.
Expand only when the bounded workflow meets the agreed criteria and operational ownership is in place. Unresolved permissions, undetectable errors or missing subject-matter ownership call for adjustment or a pause. A stopped test can still be a valuable decision.
Compare handling time, rework, quality and handovers with the baseline. Document the cases tested and those still untested. This makes the limits of the pilot’s conclusions clear.