What to automate, and what to leave alone

The hardest part of automation is not building it. It is choosing correctly what to build.

Good candidates share four traits:

Repetitive. The same steps, many times. Copying enquiries from a form into a sheet, every day.

Rule-based. You can write down exactly what to do. If it needs judgement that changes case by case, a person is still cheaper than the twenty conditions you would have to encode.

High enough volume to matter. Automating something done twice a year saves nothing and still has to be maintained forever.

Tolerant of a check. Someone can catch it if it goes wrong, or the consequence of an error is small.

Poor candidates, and it is worth being blunt because clients ask for these:

- Work needing real judgement or negotiation.

- Anything where an error is expensive and unrecoverable — sending money, deleting records, messaging customers at scale.

- Processes nobody has written down. If a business cannot describe the process, it cannot be automated. Attempting it means encoding one person's half-remembered version, and it will be wrong.

- Work that is about to change. Automating a process being redesigned next month is wasted effort.

The calculation, honestly. Time saved per run × runs per month, against time to build plus maintenance forever. That last term is the one beginners drop. An automation is not finished when it works; it needs attention every time an API changes, a password expires or a format shifts.

A useful rule: if it saves under an hour a month, do not automate it. Do it by hand and spend the effort where it counts.

And the first question to ask a client is not 'what should we automate?' It is 'walk me through exactly how you do this today.' Half the time the answer reveals a process that should be simplified rather than automated — and saying so is what makes you worth hiring.