Which work is worth automating

Two axes decide most of it

Put any task on two axes: how often it happens, and how much the inputs vary between instances.

• High volume, low variance. Invoices from the same twelve suppliers. This is the sweet spot for plain code, and it is where automation pays.
• High volume, high variance. Support emails from strangers. This is where a model earns its cost, and where you will need everything in the rest of this course.
• Low volume, low variance. Runs four times a year. Write a checklist. The build cost will never come back.
• Low volume, high variance. A person does this. Automating it is a hobby.

Most failed automation projects are the bottom-right quadrant with a budget attached.

The arithmetic people skip

A task takes fifteen minutes a week. That is thirteen hours a year. The build takes eight hours. Payback in about seven months, which sounds fine.

Now add the term nobody writes down. Any automation touching an external API breaks around three or four times a year, and each break costs roughly an hour to diagnose and fix. Real saving: thirteen minus four, so nine hours a year against an eight-hour build plus your attention forever.

That is still positive, and it is much thinner than the pitch. Be honest about it, because the honest version still wins often, usually for a reason other than hours. Automation makes a task get done consistently, and at all, at 6am on the Monday after a long weekend. That is frequently worth more than the time.

Three questions about being wrong

Before you automate, price a mistake:

1. How visible is a wrong output? A wrong number in a report someone reads is caught. A wrong tag on a record nobody opens is not.
2. How reversible is it? A draft is free. A sent email is not. A payment is not.
3. How many happen before anyone notices? This is the one that hurts. A 2% error rate is nothing at ten a week and a catastrophe at ten thousand a night.

Cheap, visible, reversible errors: automate freely and fix as you go. Expensive, invisible, irreversible: either do not, or put a person in the path, which is module four.

The tasks that look automatable and are not

• Work whose real content is an undocumented decision. If nobody can write the rule down, you cannot encode it, and a model will guess at it convincingly.
• Work whose input format changes because a human keeps changing it. You are not automating a process; you are chasing one.
• Work that exists so that somebody is accountable for having looked. Automate the looking and you have removed the thing the work was for. The output was never the point; the reader was.

Instrument before you build

Almost everyone is wrong about how often the task happens. Log it for two weeks first: a line in a text file each time somebody does it, with how long it took. Two weeks of that has killed more bad automation projects than any amount of argument, and it gives you the denominator you will need later when you want to say whether the thing worked.

Then automate the version you measured, not the version you remember.