THE STARTING POINT
Plan an AI automation pilot with clear inputs, expected outputs, human review and fallback rules. Start with one task and a practical evaluation checklist.
Describe the task precisely.
Start with one repeatable activity. Record its inputs, expected output, exceptions and the person responsible for the result. If the task cannot be described clearly, spend time understanding it before choosing an automation method. Some requirements may fit straightforward rules better than an AI-based approach.
Define what a useful result looks like.
Create representative examples that the team can review. Include awkward cases, incomplete inputs and situations that should be escalated to a person. Agree how results will be assessed before extending the workflow. The evaluation should reflect the actual task, rather than an impressive but unrelated demonstration.
Keep review and access explicit.
Decide which outputs require human approval and which information the workflow can access. Discuss failure handling and the route for correcting an output. Avoid granting broader access simply because it is convenient during a prototype. Ownership of the final decision should remain visible.
Review the pilot before expanding.
Compare the pilot with the current workflow against the criteria you agreed. Record limitations and outstanding questions. A broader rollout is a separate decision, informed by the pilot’s results, operating requirements and the people who will support it.
Scope the pilot before selecting a tool
Choose one task with a clear start and finish. Observe how a person handles it today, including the checks they perform before acting. Identify whether the proposed automation prepares information, recommends a decision or performs an action; these require different review boundaries.
Build a small, representative evaluation set with agreed expected outcomes. Test incomplete inputs, ambiguous requests and cases outside the intended scope. Record incorrect outputs and the work needed to correct them. Compare the pilot with the existing process using the same task definition, then decide whether to revise, expand or stop. Keep any production rollout separate from the initial experiment.
A one-page automation opportunity sheet
Complete this sheet with the person doing the task and the person who would operate the automation. It should expose uncertainty before a technical demonstration.
- Task boundary: trigger, required inputs, intended output and actions the automation must never take.
- Current process: responsible role, checks, common exceptions and existing escalation routes.
- Candidate method: simple rules, assisted drafting or another approach, with the reason for considering it.
- Evaluation: representative cases, unacceptable errors and the person reviewing each result.
- Operating plan: access, monitoring, fallback, correction ownership and expected running costs.
- Decision gate: evidence needed to continue, revise the scope or end the pilot.
Avoid automating an unclear decision
If staff disagree about the correct outcome, resolve the rule or policy before asking a tool to reproduce it. A model cannot settle an unowned business decision merely by generating a confident answer.
Do not assess only successful outputs. Review incorrect actions, uncertain cases and time spent checking results. Keep access restricted to the information needed for the pilot, and avoid presenting a prototype demonstration as evidence that the wider workflow is ready to operate without supervision.
Does automation always need AI?
No. A stable task with explicit conditions may be better served by rules or an ordinary software workflow. Consider AI where the task warrants evaluation, and compare it against a simpler baseline rather than assuming the more complex option is preferable.
ILLUSTRATIVE PLANNING EXAMPLE
Example: routing incoming support requests
A support team wants to route enquiries by subject. Define the available categories and give the pilot a representative set of anonymized messages. Include messages covering two topics and requests that do not fit any category. Decide which uncertain results return to a person rather than moving straight into a queue.
Record the routing decision, reviewer correction and reason for escalation. Use that evidence to decide whether to adjust the task, change the method or stop the pilot.
TAKE THE NEXT STEP
Your discovery checklist
- What is the specific task?
- What would count as an unacceptable output?
- When must a person review it?
- Who owns access and operation?
FURTHER READING
Official resources to explore
Explore the related official guidance below. The templates and examples are practical starting points to adapt to your own project.