Cost per task: the only automation metric that matters

Automation gets sold with two numbers, and both are nearly useless. The first is hours saved, which nobody ever reconciles against payroll and which quietly assumes the freed hours turn into something valuable. The second is a return-on-investment percentage, which is usually a spreadsheet of assumptions stacked on other assumptions.

There is a better number, and it is boring. Cost per task. What does it cost your business to process one invoice, onboard one client, publish one article, deliver one weekly report? That number exists today, whether or not anyone has calculated it, and it will exist after automation. The whole case lives in the gap between the two.

Calculating the before

Take the people who do the work. Use their full cost, salary plus everything that rides on it, not the base figure. Work out how much of their time the process consumes, honestly, including the chasing, the corrections and the handovers that never appear in the job description. Divide by the number of units produced. Most firms have never done this sum, and most are surprised by the answer. A task that feels small often costs twenty or thirty pounds a unit once the interruptions are counted.

Calculating the after

The automated version has four ingredients. Model inference, which is metered and visible. Infrastructure, which is modest for most workflows. Human review time at the approval gates, which is real work and must be counted. And the build cost, amortised over a sensible horizon rather than pretended away.

Then add the fifth ingredient people forget: the cost of errors. If the system gets one task in two hundred wrong and each miss costs an hour of cleanup, that belongs in the unit price. A cheap system with an expensive error rate is not cheap.

How to use the number

Measure the baseline before anything is built, because afterwards it is gone. Run the automated version in shadow mode alongside the current operation and let the two numbers sit next to each other for a few weeks. If the automated cost per task is clearly lower with quality held level, cut over. If it is not, you have learned something valuable for the price of a pilot instead of the price of a migration.

The decision rule is short. Automate when the cost per task falls, quality holds, and the volume justifies the build. Decline when it does not. Everything else in the sales deck is decoration.