Automate the second time, not the first

Every organisation has a list of things it would like automated. Almost none of them have worked out which ones pay. The list is usually ordered by how annoying each task is, which correlates with value far less than people expect — the most irritating job in the company is often one that takes twenty minutes a month.

The arithmetic

Four inputs, all of which you already know. Hours the task takes, times per year it runs, the loaded hourly cost of whoever does it, and an honest estimate of the build. Then divide.

annual cost  = hours × runs_per_year × hourly_rate
payback (yr) = build_cost ÷ annual_cost

Worked through: a report that takes 3 hours, produced weekly, by someone at a loaded $40/hour, costs $6,240 a year. A build estimated at $4,000 pays back in under eight months. The same build against a task that runs monthly rather than weekly takes almost three years, and should not be near the top of anyone's list.

$6,240

3h × 52 × $40

7.7mo

Payback on a $4,000 build

$1,440

The same task, monthly

2.8yr

Payback on the same build

Same task, same build, same team. The only variable is frequency, and it moves the decision from obvious to no.

What the arithmetic misses

Two things, one in each direction, and they are the reason this is a starting point rather than an answer.

• —It undercounts error. A manual process has a defect rate, and the cost of a wrong number reaching a customer or a regulator is not in the hourly rate. For anything touching money or compliance, the errors are usually the entire case.
• —It undercounts latency. Work that waits for a person to be available has a queue in front of it. If a lead sits for eleven hours because it arrived at 6pm, the cost is the conversion you lost, not the two minutes of routing.
• —It overcounts the saving. Automating 80% of a task does not free 80% of the time — someone still has to handle the exceptions, and the exceptions are the hard part. Assume you are buying most of it, not all of it.

The rule we actually use

Automate the second time you do something by hand. Not the first — you don't understand it yet. Not the fifth — you have already paid for it four times.

The first run teaches you what the process actually is, including the branch nobody documented. By the second you know enough to build it correctly, and the remaining runs are all profit. Building on the first pass is how you end up automating a process that was about to change.

The corollary is uncomfortable for anyone selling automation: for a genuinely infrequent task, the correct recommendation is to keep doing it by hand. We would rather say that early than take the money and have you discover the payback figure yourself in year three.