The economics of automation, in brief

01Start from the problem, not the tool

Most automation decisions start in the wrong place. A task is repetitive, a tool makes it easy, a competitor has done it, a demo looked impressive, and so the company automates. None of these is an economic reason. The economic question is narrower: does this particular system, with its build and running costs, beat this particular use of these particular people?

Asked that way, automation becomes a decision about reallocation: freed hours are worth only what they are spent on next. The question also separates speed from value. Automation can make a task that should not exist more efficient, so the company does the wrong thing faster. Michael Hammer built the reengineering movement on this point in 1990, arguing that IT spending had disappointed because companies used it to speed up old processes instead of questioning them.^[1] An automation that changes nothing about how people and money are used has, economically, produced nothing.

02Hours saved are not cash

This is the mistake underneath most business cases. A workflow saves a coordinator ten hours a week. The coordinator costs 60,000 a year, so the case claims 15,000 a year in savings. The arithmetic is right and the economics are wrong, because the coordinator is still on the payroll. What the company bought is ten hours of capacity, and capacity is worth whatever it is used for: close to the claim if it clears a backlog that was delaying invoices, nothing if it disappears into more meetings.

An automation can produce six kinds of value, and only the first is cash in its own right.

Several of the usual selling points (lower labor cost, higher productivity, growth without hiring, more capacity) are the same freed hours seen from different angles, so count them once. The row most often missing from a first draft is quality. Once someone prices the mispriced quotes, duplicate payments and wrong shipments, it is often the row that turns a marginal case into a clear one.

In the full paper: Chapter 1 and Chapter 2.^[2]

03Doing nothing has a price

The option that gets the least scrutiny is the one most companies choose: carry on as before. But the status quo is a cost nobody has to sign for. Manual work grows with volume, and faster than volume once it needs a second person, a handover and a spreadsheet to track the spreadsheet.

Three hundred orders a month at ten minutes each is 50 hours. Three thousand is 500 hours: three people, and a process nobody designed that falls over whenever one of them is on holiday. The arithmetic never changed; the volume did, and nothing in the monthly reporting noticed. Meanwhile, a founder who spends Friday afternoons on invoicing pays with the sales call that never happened.

The opposite mistake is just as real. A process one competent person handles in two hours a week is not a crisis. Estimate the cost of doing nothing the way you would any other cost, and if it turns out to be small, leave the process alone and look again next year.

In the full paper: Chapter 3.

04What to automate, and what to leave alone

The folk rule says to automate whatever is repetitive. It is wrong often enough to be dangerous. A task done a thousand times a month with stable rules and cheap mistakes is an excellent candidate. A task done ten times a month whose mistakes cost tens of thousands may be a better one. A task done a thousand times a month that needs a judgment call every time may be the worst on the list.

Three sets of questions decide it:

• Value. How much volume, how many hours, whose hours, and what does one mistake cost?
• Feasibility. Is the work done one way? How often does a case not fit the rule? Is a person deciding, or just executing?
• Cost. How many steps, systems and people are involved, and how often do the rules change?

The exception rate settles the economics more often than any other number. At one case in a hundred, the manual fallback can be informal. At one in five, it needs its own staff and its own design. Judgment often hides behind repetition, too. A credit controller sending fifty reminders a week is really deciding, fifty times, whether this customer needs a reminder, a call or a hold on the account. Automating the email is easy; automating the decision is a different project. Careful case studies of early process automation found the successes where volume, standardization, clear rules and process maturity were all high, and the disappointments where those conditions had been assumed rather than checked.^[3]

In the full paper: Chapter 4, with the full candidate table and a triage score.

05When to automate: follow the volume

Automation swaps variable cost for fixed cost, and a fixed cost is only worth paying when enough volume passes over it. That is why the same automation can be a mistake at one scale and the best investment the company makes at another.

Automate too early and you pay the fixed cost before the volume exists, and freeze a process the company is still learning. Automate too late, the more common and more expensive error, and you have scaled the process by hiring and overpaid on every unit since volume passed break-even.

Headcount is the wrong measure. A five-person shop shipping two thousand orders a day has more reason to automate fulfillment than a hundred-person consultancy sending twenty invoices a month. It is the process, not the company, that has to reach scale. These are the signs that it has:

• The process has a stable definition and a known list of exceptions.
• Volume is measured, and rising.
• The next step would otherwise be a hire.
• Someone has put a price on the errors.
• One named person owns the process.
• The tools are mature enough that other companies have paid for the learning curve.

In the full paper: Chapter 5.

06The business case on one page

Start with the total cost of ownership over three years, and expect the first draft to be too low. It counts the items with price tags, while much of the money goes on the items without them:

• Integration, and every later change to the systems it connects
• Maintenance, usually a scarce engineer's recurring time
• Monitoring, and whoever gets the alert at 2 a.m.
• The weeks when the old and new processes run side by side
• Vendor price rises, and the day it stops working

Across 1,471 IT projects, the average cost overrun was 27 percent, and one project in six overran by an average of 200 percent.^[4] So take the outside view: ask what comparable automations actually cost, not what the team that wants to build this one believes.

Then work out five numbers:

• Return on investment, with the period stated and cash kept separate from capacity.
• Payback, which is really a measure of risk. Beyond two years, be suspicious.
• Net present value, for anything long-lived.
• Internal rate of return, but only if there is a hurdle rate and competing projects.
• Break-even volume. If the automation pays from 1,800 invoices a month and you process 1,200, the real question is whether you believe the forecast.

Case A: an invoice automation that pays. It frees 410 of the 500 hours a month three clerks spend on supplier invoices. Two of them are retiring and will not be replaced, so most of those hours become 120,000 a year in cash, and the third clerk now has time to capture 35,000 a year in early-payment discounts. The case returns 118 percent over three years and pays back inside twelve months. Keep all three clerks instead, and the same automation loses money every year. Same technology, same hours, opposite result.

Case B: a lead-routing build that only looks as if it pays. It promised six sales reps 15 hours a week each, and a payback of under three months. Measured, the task took 8 hours, 18 percent of leads still needed a person, the running cost came to 45,000 a year, and headcount did not change. Cash benefit: zero. Presented truthfully, it is a bet on more selling time, with a plan to measure it, not a payback.

In the full paper: Chapter 6, with both cases worked line by line.

07The simplest tool that works, and where AI fits

The most reliable way to lose money on automation is to automate a process that should have been fixed. Ford learned this in the early 1980s. It planned to automate its way to a 20 percent cut in an accounts payable department of more than 500 people, then redesigned the process instead, so that most of the invoice matching disappeared, and cut 75 percent.^[1] So work in order: eliminate the work that does not need to exist, simplify what is left, standardize it, and only then decide whether to automate. For whatever survives, there is a ladder of options, from cheapest to most expensive:

1. Eliminate the task.
2. Change the process.
3. Add a checklist or a better form.
4. Use a feature of software you already own.
5. Build a rule-based workflow.
6. Build something custom.
7. Use AI.

Stop at the lowest rung that solves the problem to the standard the business needs.

AI sits at the top of the ladder. It does not change the arithmetic, but it does change what can be automated: unstructured inputs, documents in any layout, emails that need reading, decisions that depend on context. Using it to assist people pays, especially for novices. Among 5,179 support agents, a generative AI assistant raised issues resolved per hour by 14 percent on average and by 34 percent for the least experienced.^[5]

But AI is not free automation. Its cost is metered and grows with volume, it fails quietly with plausible wrong answers, and it needs evaluation and review that the demo never had. So price it per successful task, not per call. Process 1,000 documents at 0.05 each and the model costs 50. If 15 percent need six minutes of correction at 40 an hour, the corrections cost 600, and each good document really costs 0.65, thirteen times the vendor's price.

Klarna has lived both sides of this in public. In 2024 it announced an assistant doing the work of 700 agents. In 2025 its chief executive said cost had weighed too heavily, quality had suffered, and the company was hiring people again.^[6][7]

The principle, stated once: do not use AI when a simpler, cheaper, more reliable solution delivers the same outcome. A rule that is right every time on the cases it handles, and stops on the rest, is a different asset from a model that is right 93 percent of the time on everything.

In the full paper: Chapter 7 and Part II, including a worked comparison of rules against a model.

08Monday morning

The whole procedure, compressed:

1. Write the problem in one sentence, with a number in it and no technology.
2. Watch the process as it is actually done, and measure a baseline. Self-reported estimates can be off by a factor of two, in either direction.^[8]
3. Price the baseline, including errors and waiting time.
4. Eliminate, simplify and standardize, then price it again.
5. Build a three-year case for the two or three rungs that fit, stating whether the benefit is cash or capacity.
6. Pilot with a kill criterion agreed in advance, measure the same way as the baseline, then scale, improve or stop.

Make sure four groups have a say, because any one of them can sink the project:

• Finance, on whether the benefit is cash, capacity or hope.
• Technology, on what it will cost to run for five years.
• Operations, on whether the process is standard enough.
• The people who do the work, whose adoption decides whether the forecast ever arrives.

After launch, measure outcomes rather than activity: cost per completed task, cycle time, throughput at constant headcount, error rates, and the actual return against the forecast. Counting workflows automated, or hours saved on paper, measures what the company spent, not what it earned. The test is the one this note started with: is the organization economically better off?

In the full paper: Part III on implementation, measurement and common mistakes, and Part IV on strategy and the future.