The usual way business automation starts is backwards: buy a tool, then go looking for a problem. The useful way is to find a task that is (a) repetitive, (b) rule-based, (c) high-volume, and then automate exactly that — end to end, with documentation.
Find the task that qualifies
- Runs on a fixed schedule (daily report, weekly reconciliation, monthly reminder).
- Has clear rules a checklist can describe — “if X, then Y”.
- Involves moving data between tools — spreadsheet to system, email to record.
- Takes someone 30+ minutes a week, every week, year-round.
- Is painful enough that one person mentally owns it and nobody else can do it.
Measure before you build
Time the task for a week. Count the steps, the tools it touches, and the error rate when a human does it. The measurement decides the project’s shape: a document-processing task and a spreadsheet-reconciliation task need completely different automation, and the measurement tells you which one you’re on.
Start bounded, deliver working
- 01Pick one task — not a department, not “digitisation”.
- 02Define the input, the rules, and the output you can verify.
- 03Build the narrow version first — handle the main path correctly before the edge cases.
- 04Run it alongside the human process until results match.
- 05Hand it over with documentation: what it does, how to check it, who to call when it’s wrong.
Where AI actually fits
AI earns its place in the parts that are “judgement-ish but boring”: extracting fields from documents, summarising, classifying, drafting a consistent reply. Rule-based scripting should handle the parts that are deterministic. A good automation design decides that split explicitly — and keeps the parts that must be exact away from the parts that can be probabilistic.
When not to automate
If the task runs once a month, if the rules change every week, or if the output quality is unverifiable — fix the process first, automate later. Automation of a broken process just produces the broken result faster.