You automated a large part of the operation. Robots move goods on the floor, software bots key invoices in the back office, and an AI agent answers routine customer requests. Headcount on that work went down, exactly as the business case promised it would. The cost of running the work went up, which the business case never mentioned.
That is not a contradiction. The case counted the people you would remove and never counted what you would add. Smart automation that is badly implemented adds a second operation beside the first one: people who keep the machines running, work the machines cannot finish, and checks on work nobody trusts. Each of those lands in your operating budget every month, and none of them arrives labelled as a line called automation.
Who Keeps It Running
The people you removed were paid to do the work. The people you add are paid to keep the machine doing it: engineers, integration specialists, a vendor's support contract and somebody on call at night. Per hour, they cost more than the people they replaced, and they are harder to hire, and much harder to cover when one of them leaves for another job.
Then come the running bills. Power for the equipment on the floor, compute and model usage for the software, licences that grow with volume. None of them were in a case that was built as a labour number, so your first sign of them is a variance in the monthly report.
Six Costs The Case Left Out
The known costs are the smaller ones. The expensive ones arrive as work nobody planned for, and you can find each of them in your own operation this month, with no new tools.
- Exceptions. Every process has cases its design did not expect: the carton that does not fit, the invoice with two purchase orders, the customer who asks two things at once. A person handled them. A bot stops or guesses, and when nobody built a path for them, they pile up until someone you thought you had freed spends the week clearing them.
- Errors that travel. A person who types a wrong number usually notices. A bot that reads the wrong field writes it into the next system, which passes it on. Nobody sees it until a customer, a month-end close or an auditor does, and by then the error lives in three places and costs far more to correct than the original work ever did.
- The stop. When an automated process halts, it does not slow down the way a team does; the whole floor stops at once. If nobody wrote down how the work runs by hand, an outage of an hour becomes a lost day of shipments, invoices or answers.
- Security. A bot or an agent usually holds more access than any one employee, and it never sits through an access review. When that access is misused, through a mistake or an attacker, the loss is real money that was never priced as a cost of the automation.
- Duplicated work. Your team does not trust the output, so it keeps its spreadsheet, checks every result by hand, and runs the old process beside the new one. Research on algorithm aversion (Dietvorst, Simmons and Massey, 2015) found people avoid an algorithmic forecaster after seeing it err, even when they have seen it outperform a human forecaster. You pay for the automation and for the people who do not believe it.
- Review that never ends. The system recommends something and nobody can see why, so it waits for approval. That person cannot judge it either, so it goes to a meeting, and now a queue of decisions waits on people who cannot evaluate them.
Most of these are designed in, not bad luck. The ironies of automation (Bainbridge, Automatica, 1983) described the trap: the designer automates what can be automated, and people are left with the hardest tasks and the least practice at them. That is not an argument against automating; it is an argument for designing what your people are left with.
Price The Running Cost
Price the current work per item, not per head: what it costs today to handle one order, one invoice or one customer request. Then list every cost line the automation adds and give each one a monthly number before you sign, and again three months after go-live.
| Cost line | What to measure each month |
|---|---|
| Upkeep | Hours of engineers, specialists and vendor support |
| Running bills | Power, compute, model usage and licences |
| Exceptions | Items handled by hand, and the hours they take |
| Travelling errors | Errors found downstream, and the cost to correct each |
| Stops | Hours stopped, times the cost of one stopped hour |
| Duplicated work | Hours your people spend checking or redoing output |
| Review queue | Decisions waiting on approval, and their average wait |
| Access | Systems the automation can change, and who reviews that |
If cost per item rose after go-live, the table shows which line did it: fix that line. You pay that list either way; the only choice is whether you see it before you sign or after.
What A Build Must Prove
Before any automation goes live, whether your own team, a vendor or ML LABS builds it, ask to see these five things working in front of you, rather than promised:
- Every exception has a named path, a queue and an owner who clears it.
- Every record that crosses to another system is checked against its source.
- On failure it stops, says so, and a written manual mode has been practised.
- Its access is no wider than the job it does, and is reviewed like an employee's.
- Every recommendation shows why, so a person can approve it in seconds.
The last one removes most of the duplicated work and the review queue at once. People stop redoing output they can check, and stop escalating decisions they can understand.
When Not To Automate
When nobody can state what one item costs today, there is no way to prove a saving later, and the first piece of work is measuring that cost rather than replacing it. And when volume is small and the exceptions are most of the work, a well-run team is the lower-cost system to run; you should hear that plainly from whoever you ask to build it for you.
First Steps
- Pick the one automation you are least sure about. The one people complain about quietly, or the one whose results still get checked by hand every week.
- Ask three questions. Who still checks or redoes its work? How many exceptions waited last week, and who cleared them? What happened when it last stopped?
- Put a monthly number on each line of the table. Compare the cost per item with the cost per item before it went live, and name the one line that moved it most.
Price One Automation, Line By Line
A fifteen-minute call takes one automation apart line by line: what it costs to run, which line moved it, and what would bring it down. Sometimes the honest answer is that it pays and the cost sits elsewhere; you will hear that plainly, with the numbers behind it.
Where something has to be fixed or built, Engineering puts a builder on your exceptions, checks and manual mode, with targets agreed in writing before each release starts. Where your automation is live and nobody owns its running cost, Advisory answers your cost, risk and control questions each month, so you know which line to fix next.
References
- Dietvorst, B. J., Simmons, J. P., and Massey, C. Algorithm Aversion: People Erroneously Avoid Algorithms After Seeing Them Err. Journal of Experimental Psychology: General, 2015.
- Bainbridge, L. Ironies of Automation. Automatica, 1983.
