What is worth automating, with the arithmetic

Automation sold as hours saved is usually hours moved. The time comes off the task and goes onto building, checking and repairing the thing that does the task, and whether that is a good trade depends on facts nobody looks at first.

The arithmetic, before anything else

Illustrative, but run it with your own numbers before you build anything.

A job takes twenty minutes and happens twice a week: about thirty-five hours a year. Automating it takes two days to build, and then perhaps an hour a month keeping it working as the inputs change and something upstream is renamed. That is sixteen hours of building plus twelve of maintenance in the first year, against thirty-five saved. Worth it, but not dramatically, and only if it keeps working.

Now the same job once a month: about four hours a year, against the same twenty-eight. It loses, badly, and it will keep losing every year because the maintenance does not go away.

This is why the honest first question is frequency, not difficulty. The jobs worth automating are the dull frequent ones, not the annoying rare ones, and instinct points the other way because the rare ones are the ones you resent.

What makes a job a good candidate

• It happens often and the same way each time.
• The input arrives in a predictable shape.
• You can tell quickly whether the output is wrong.
• Being wrong occasionally is survivable and visible.
• Nobody outside sees the result before you do.

The last two carry most of the weight. An automation whose mistakes are silent accumulates them, and you find out from a customer.

Failure modes to design for

1. 01It will break quietly. Something upstream changes a field name, and the automation keeps running and produces nothing useful. Make it tell you when it produces nothing, not only when it errors.
2. 02It will be wrong in a new way. Plan a spot check: a fixed number of outputs read in full every week, regardless of whether anything looked wrong.
3. 03It will outlive your memory of how it works. Write down what it does, what it touches and how to turn it off, in the same place as the thing itself.
4. 04It will become load-bearing. Before it does, know what happens to the business on the day it stops.

Start at the ugly end

The best first automation is almost always something nobody would demo: renaming and filing things, pulling the same figures into the same sheet, turning a week of notes into a list. Unglamorous, frequent, easy to check, and harmless when it fails. The impressive ones that answer customers and make decisions are the ones to build fifth, once you know how this tool fails in your hands.

The order to build things in

Most automations that get abandoned were built as one piece. Built in stages, each stage is useful on its own and you find out early whether the thing works at all.

1. 01Do the job by hand once more, writing down every step including the ones you do without thinking. This is where you discover the job has four exceptions you never mentioned to anyone.
2. 02Automate the gathering only. Get the inputs into one place, reliably, and keep doing the rest by hand. If this stage fails, nothing downstream was ever going to work.
3. 03Add the drafting, with the output going to you rather than onward. Run it alongside doing the job by hand for a fortnight and compare the two.
4. 04Only then connect the output to anything, and only if the fortnight gave you no surprises.

The fortnight of running both is the step everyone skips and the one that pays. It is the only way to find the exception that happens twice a month, which is exactly the frequency at which an exception is both common enough to matter and rare enough to miss in a day of testing.