What Business Processes Should You Automate?
Frequency times duration times error rate. A simple filter for deciding which repetitive work is worth automating - and which is just annoying but not expensive.
The wrong way to choose what to automate is to pick the task people complain about most. Complaints track annoyance, not cost, and those are different things.
A task that happens twice a month and everyone hates is a poor candidate. A task that happens two hundred times a day and nobody mentions because it is just how things are done is often the best one available.
Four questions that filter candidates
How often does it happen? Multiply out to an annual figure. Fifty times a day is roughly twelve thousand times a year. Twice a month is twenty-four. The difference dwarfs almost every other consideration.
How long does each occurrence take? Include the switching cost - stopping what you were doing, opening the system, finding the record. That overhead is frequently larger than the task.
How often does it go wrong? Error rate matters as much as time. Automation that eliminates a recurring mistake can be worth more than the hours saved, particularly if errors reach customers or accounting.
Is the process stable? This is the one people skip. Automating a process that changes every quarter means rebuilding it every quarter. If nobody agrees what the process should be, fix that first - automating an unsettled process locks in the confusion.
A candidate that scores well on all four is worth building. One that fails the fourth is worth revisiting later.
What makes a task technically automatable
Beyond the business case, some tasks are simply more suited to automation than others.
Clear inputs. The task starts with something identifiable - a form submission, an email, a file, a record change.
Repeatable judgement. The decision follows rules, even complicated ones, rather than requiring context that lives in someone’s head.
Defined output. You can state what “done” looks like precisely enough to check it.
Tolerable failure. If it goes wrong occasionally, you can catch it and correct it without serious consequence - or a human reviews the output before it goes anywhere that matters.
Tasks requiring genuine relationship judgement, negotiation, or knowledge of an unwritten exception are poor candidates. Tasks where a mistake is expensive and irreversible need a human in the loop regardless.
Categories that reliably pay off
Data entry and transfer between systems. Anything where a person reads from one screen and types into another. The most common and most reliable win.
Document processing. Invoices, purchase orders, applications, forms. Extracting structured fields from varied layouts is exactly what language models are good at, and it is work nobody wants.
Triage and routing. Sorting incoming enquiries, tickets or applications by type and urgency, then sending each to the right place with context attached.
Lead qualification. Scoring enquiries against your criteria, enriching them with available data, routing to the right person.
Recurring reports. Assembling the same figures from the same sources every week, with a written summary of what changed.
First-draft generation. Standard replies, meeting summaries, content briefs. A human edits before anything is sent - the automation saves the blank page, not the judgement.
Scheduled checks. Anything a person does periodically to verify something is still true. Machines are better at remembering.
What not to automate
Anything you do not understand yet. If nobody can describe the current process precisely, automation will encode a misunderstanding.
A broken process. Automating a bad workflow gives you a faster bad workflow, now expensive to change. Fix the process on paper first - occasionally that is the whole project.
Genuine relationship work. The follow-up call that saves an account is not a candidate.
Low-frequency tasks, however irritating. The annual compliance return is not worth building for.
Anything with an unclear success criterion. If you cannot say whether the output is correct, you cannot monitor it, and unmonitored automation drifts.
Do the sums before committing
A rough model:
Annual cost of the manual process = occurrences per year × minutes each × fully loaded hourly cost ÷ 60. Add an estimate for errors - rework, corrections, the occasional expensive mistake.
Cost of automating = build cost + annual maintenance. Maintenance is real: APIs change, formats shift, edge cases appear. Budget for it rather than being surprised.
If the automation pays for itself within a year, it is usually worth doing. Between one and two years, it depends on how stable the process is. Beyond two years, be sceptical - the process will probably change before the payback arrives.
The step people skip
Before automating anything, write down the process as it actually runs. Not the official version - the real one, including the exceptions and the things people do without thinking.
This is where most automation projects are won or lost. Documenting the process reveals the edge cases that would otherwise surface halfway through the build, and it frequently reveals that steps exist for no current reason.
We have had projects where writing down the process was the deliverable. The client removed four steps, and the remaining work no longer justified automating.
Start small deliberately
The instinct is to automate the whole workflow. The better approach is to take the single worst step and automate that.
You learn how the data actually behaves, you find the edge cases early on something small, and you deliver value in weeks rather than months. If it works, extend. If it does not, you have lost very little.
Large automation projects that attempt everything at once tend to reveal - at the point of integration - that a system does not expose the data anyone assumed it did.
A short prioritisation exercise
List every repetitive task in one part of the business. For each, note frequency per year, minutes per occurrence, and roughly how often it goes wrong. Multiply out the annual hours. Sort by that number.
The top three will usually be obvious in hindsight and were not obvious before, because the highest-cost tasks tend to be the ones so routine that nobody thinks about them.
Then apply the stability question to those three. Whichever is both expensive and stable is where to start.
We look for automation that pays for itself and say so when it will not. Describe a task your team repeats and we will tell you whether it is worth building. More on AI automation.