Which task makes a good first pilot?
Begin with a list of recurring tasks, and for each one note what starts it, what information comes in, what should come out and who is responsible for it. This simple inventory quickly shows which tasks are well defined and which depend on judgement that has never been written down. The same inventory is the starting point for small business automation, where one person often covers several roles.
For a first pilot, favour a task where examples are easy to find and the team can say clearly what correct work looks like. Note how often exceptions occur: a task where most cases follow the same pattern is easier to test than one where every case is unusual. Also check whether the result can be reviewed before it reaches a customer or changes a business record. If a mistake can be caught at that point, the pilot can run safely while the team learns. This is how we pick the starting task in AI workflow automation projects.
A bounded task also makes vendor demonstrations easier to judge, and it is a good starting point for AI consulting. A tool that looks impressive on generic examples tells you little. The same tool completing a real, limited piece of your work, with your documents, your formats and your awkward cases, tells you whether it is worth continuing. For an overview of where AI usually fits first, see AI solutions for business.
How do you compare the process before and after?
Measure the whole process: preparation, processing, checking, correction and handover. Automation often shrinks one manual step while adding review or correction somewhere else, and if you measure only the step that was automated, the result will look better than reality.
So keep two figures apart: the reduction in a single manual step and the total effort needed to run the workflow. The second is the one that matters for the decision. Add the costs the pilot brings with it, such as software, integration work and ongoing support, so the comparison reflects what the business would really take on.
Use your measured inputs to build a scenario, then check actual runs against the same definitions once the pilot is live. If the definitions shift between the estimate and the measurement, the comparison loses its meaning. And as with any automation case, keep released capacity separate from cash savings: freeing up hours is valuable, but it is not money saved until someone decides how those hours will be used or which costs will go down.
What should the pilot decision be based on?
Before the pilot starts, choose test examples that cover ordinary work as well as the difficult cases your team already knows about: unusual formats, incomplete inputs, the requests that always raise questions. A pilot tested only on clean examples will disappoint as soon as it meets everyday work.
Decide in advance which errors are serious enough to block release, who reviews outputs the system is unsure about and how a failed run is put right. Name the person responsible for day-to-day operation before the pilot is extended; otherwise the workflow tends to drift once the project team moves on.
The final review should answer three questions: what needs improving, whether to go ahead and which dependencies are still open, such as access to systems, data preparation or staff training. Keep the limits of the evidence in mind as well. Passing a small set of examples is encouraging, but it tests those examples only and guarantees nothing about every future case, so plan monitoring for the first period of wider use.
Checklist: choosing a pilot
- Document the trigger, the inputs, the expected outcome and the person responsible for the task.
- Measure review and correction as part of the workflow, not as an afterthought.
- Test on representative examples and on the difficult cases your team already knows.
- Settle the acceptance criteria, the recovery procedure and who runs the workflow day to day.
Example: fields from supplier emails
AI reads supplier emails and fills in the relevant fields, a reviewer checks them, and approved records go into a staging queue, not straight into the main system. The test compares the full processing time and the accuracy of each field with the manual process the team used before. Invoices and other attachments follow the same pattern in AI document processing.
Direct updates without a person in the loop are considered only later, once the team has evidence from real runs and has settled on a control design: which checks run automatically, which cases still go to a reviewer and how errors are corrected. Only then does it make sense to move on to AI agent development, where the system acts on its own within set limits.
Read next
- How to map a business process before you automate it
- How to measure automation ROI: time, quality and running cost
- Automation savings calculator
