Which processes are worth automating

Most office work falls into a handful of shapes, and the shape predicts how well it automates far better than the industry does. A sports club, a law firm and a manufacturer all end up building the same six or seven things.

• Gathering numbers and reporting them. The safest category there is, because it only reads. The work is almost never the reporting itself — it is agreeing which system holds the real number before anyone builds a report on top of it.
• Watching for a condition and telling someone. Cheap to build and hard to get wrong, because the worst failure is a message nobody needed. Set the threshold where a person would still have time to act, not where the situation is already lost.
• Keeping two systems in sync. Straightforward in one direction and a source of very confusing bugs in two. Decide which system wins every disagreement before writing a line of it.
• Creating records or documents when something happens. Reliable once the trigger is unambiguous. Most of the difficulty is deduplication: recognising that this event is the same one you already handled, arriving a second time.
• Chasing people for a response, a payment, or a file. High value, because this is the work that quietly does not get done when everyone is busy. It also writes to real humans, so tone, timing and a firm stop condition matter more than the plumbing.
• Checking that two sources agree. An excellent first automation: it only reads, and it produces a list of exceptions rather than taking action. Have it flag the mismatches and leave the fixing to a person.
• Deciding what to do, case by case. The one shape that resists automation — and the one where the work around the decision is almost entirely mechanical anyway.

If a process does not fit any of these, that is worth pausing on. It usually means the process is really several processes that share a name, and each one belongs in a different row. There is a longer list of the specific builds these shapes turn into in 12 automations most companies need.

An automation is a rule written down precisely enough for a machine to follow it. That single sentence settles most candidates. If the person doing the work can explain what they do in a way a new hire could follow, there is a rule and it can be encoded. If the explanation keeps arriving at “it depends”, and the things it depends on are judgement rather than data, there is no rule to write.

The middle case is the common one and the best one: rules plus a short list of known exceptions. That is the normal shape of automatable work, and the right design runs the rules and routes the exceptions to a person instead of guessing at them. A marketing company handling a catalogue of more than a thousand services built exactly this — the system answers what it recognises and escalates the rest to a human, which is how it reaches fifty thousand automated responses a month without pretending it can handle everything.

If nobody can list the exceptions, that is the work to do first. Whoever builds the automation will have to write them down anyway; discovering them in production is simply the expensive way to find out what they were.

Software can only act on what it can read, and this is where ambitious projects quietly shrink. Data in systems with an API or a scheduled export is reachable. Data in screens with no API can sometimes be collected by driving the interface the way a person would, but that breaks every time the vendor changes a layout, so it belongs at the end of the list of options rather than the start. Data on paper, or in someone’s head, is not a candidate for automation — it is a candidate for being put into a system first.

The second condition matters even more and gets skipped even more often: one system has to be the agreed record. Automation copies faster than a person does, including the wrong number. Where two databases disagree, a person notices the discrepancy and asks someone; software propagates one side of it on schedule, and it is believed precisely because software produced it. Naming the system that wins every disagreement is a half-hour conversation that costs nothing, and skipping it is how a company ends up with three dashboards showing three different revenue figures, all of them automated.

Access is the third, and it is the one nobody thinks to check until the build has been scoped. Whether you hold admin credentials, and whether the vendor will open an API at all, decides what is possible far more brutally than any budget does. The integration checklist is the set of questions to put to a system before committing to connect it.

Every automation eventually does the wrong thing. Designing as though it will not is the difference between a system people rely on and one they check every morning by hand, which is worse than not having it. Two questions size the risk.

• Can it be undone? A wrong row in an internal sheet is a correction. A refund issued to the wrong customer is an incident. Irreversibility is on its own a reason to require a person to confirm, whatever the volume.
• Would anyone notice? An error that surfaces immediately is cheap regardless of how bad it is. One that surfaces at month-end, or never, is expensive even when it is small — and that is already true today, with a person doing the work.

Where detection is weak, the check is the first thing to build, before anything that runs faster. And where a run can fail halfway, it has to fail somewhere a person will see it: failure-ready automations covers retries, error handling and what should happen to the run that dies at 2am.

The useful line is not automation versus manual. Almost every process splits into a half that is safe to hand over today and a half that reaches other people. Reading data, producing reports, comparing two sources, alerting your own team and preparing drafts are all safe unattended, because the worst outcome is a number you correct or a message nobody needed.

Four categories earn an approval step regardless of volume: publishing something customers see, sending messages to people, moving money, and removing historical records. Requiring approval is not the same as staying manual, and this is the distinction most people miss. A cleaning services company automated its whole billing chain and kept one button at the end — everything is prepared automatically, an assistant reviews it, and selecting “generate receipts” creates them in QuickBooks. Most of the time saved, almost none of the risk.

Design that approval step so it takes seconds rather than minutes: a queue of prepared items and one button. An approval step people dread is one they eventually rubber-stamp without reading, which is worse than not having it at all.

Four conditions defeat a technically perfect build, and none of them are about the technology.

• A redesign is already scheduled. Building against systems that are about to be replaced means paying for the same automation twice, the second time under deadline because people now depend on it.
• Nobody agrees which number is right. This is not a reason to automate carefully — it is a reason not to automate yet. Fix the record first.
• It runs a few times a year. By the next run something upstream will have changed, and you will be debugging the automation instead of doing the task.
• Nobody owns it when it breaks. Every automation eventually meets a case its rules never covered. Without a named owner, that day is the day it silently goes back to being done by hand — and nobody tells you.

The fifth is judgement, and it deserves better than a bullet. Where a person weighs each case up, encoding that as rules produces an automation that is confidently wrong on exactly the cases that mattered. The work around the decision is a different question and is usually mechanical: collecting the facts, laying them out the same way every time, drafting the routine answer for review. A service for private physicians built precisely that — AI agents interview the patient and process their documents beforehand, the physician receives a structured summary, and every diagnosis stays with the physician. Automate the brief, not the verdict.

When a process passes on rules and data but the last step is one you cannot take back, the sequence matters more than the scope. Build the reporting and the alerting first. They carry almost no risk, they are useful on their own, and they run for a season telling you how often the rules would have been right — which is the only honest basis for deciding when to let the automation act rather than advise.

It also changes the conversation about what to build next. Teams that start with reports discover which numbers they actually look at, and that list is rarely the one they specified at the beginning.

The order that works is: is this the kind of work that can be handed over, which half of it can run unattended, and only then what it would be worth. The automation fit assessment covers the first two — the shape of the work, whether the data is reachable, what a bad run costs, and who keeps it running — and returns a verdict along with a split of what may run on its own and what should stop and ask.

Once you know which parts are worth building, the automation ROI calculator puts a number on them: hours saved, payback period and what it costs to run. Both questions are worth asking, and in that order — a process can show an excellent return and still be the wrong thing to build this quarter.