The Cost of Delaying AI Adoption Is a Run-Rate, Not a Purchase Price

Why does the proposal keep losing to the price tag?

Two different costs are being compared, and only one of them is on the paper in front of you. The process you run manually today is an expense that repeats — it invoices you every month, indefinitely — while the automation you are considering is an expense that happens once and leaves behind something you own. Putting a build estimate next to a licence price is not a comparison; it is two unrelated questions wearing the same format.

The cost of a manual process is recurring and produces no asset; the cost of automating it is one-time and produces one — so the honest comparison is not proposal versus price, it is proposal versus the run-rate of not deciding.

I have watched this argument fail in the same way in three different companies. Someone senior asks for the cost of the AI option, gets a number, compares that number to the zero that appears in the current budget line for "AI," and concludes the safe move is to wait. The zero is an artefact of accounting, not a fact about the business. The manual work is already being paid for, out of a salary line that nobody re-examines because it renews itself quietly every month.

What is actually inside the run-rate of waiting?

Four things, and only the first is easy to see.

The repeated labour cost. Not the salary — the portion of it consumed by this specific process, month after month, at current volume. This is the number that will be identical next year if nothing changes.

The rework cost. Manual steps produce errors at some rate, and errors are re-paid work plus a customer-facing cost that rarely lands in the same cost centre as the original task.

The integration debt. Every month a process stays manual, the surrounding systems are shaped around the manual version: the spreadsheet with three people's names in the header, the mailbox that acts as a queue, the approval that lives in a chat thread. Undoing that later is not free, and it is not part of any build estimate you have been shown.

The compounding gap. An automated process that has been running for a year has a year of logs, a year of edge cases already handled, and a review queue that has been tuned. A process you start next year starts from that first day. Delay is not a pause; it is a different starting line.

How do you turn a manual step into a defensible annual number?

You need three inputs, all of which you already have: volume, minutes per instance, and a loaded hourly rate. The loaded rate is where most business cases go soft, so build it out loud.

Take a base salary of $70,000. Multiply by roughly 1.25 to 1.4 to cover employer taxes, benefits and overhead — that range is a standard payroll convention, not a benchmark I measured, so use your own finance team's multiplier. At 1.3 that is $91,000, divided by 2,080 paid hours, or about $43.75 per paid hour. Then be honest about utilisation: if only two-thirds of a working day is spent on task rather than in meetings and context switching, the effective cost per productive hour is closer to $65. That second step is the one that decides most arguments, because it is the difference between a number that feels small and a number that funds a project.

A worked example. A document-handling step takes 12 minutes of human attention, runs 2,500 times a month, and uses the $65 effective rate. That is 500 hours a month, $32,500 a month, and a $390,000 annual run-rate on one step in one department. Add rework: if 4 per cent of items come back at 25 minutes each, that is another 1,000 items and roughly 417 hours a year, about $27,000 that never appears in a project plan.

Now the automated version, priced the same way I would price it for a client:

The inference line is the one that surprises people, and it is worth sitting with: $600 a year against a $390,000 run-rate. Model cost is not the budget problem in most enterprise processes. It is a rounding error attached to the decision that is actually expensive. If you want the fuller treatment of how to cost a single run — cached input, retries, failed attempts, the difference between marginal and average cost — I have written separately about a per-run cost model that survives a finance review. For the case you are building, the structure above is enough.

Which parts of this are real, and which are rhetoric?

Not all of it is real, and a business case that claims otherwise gets dismantled in the room.

You do not bank the labour in month one. Nobody is fired because a workflow shipped. The $390,000 only converts to money if the freed capacity is absorbed by work you would otherwise have hired for, or if it delays a hire you had already approved. If the same people do the same number of hours and the work simply disappears into the slack, you have bought speed and morale and an error reduction, not cash. Say that out loud in the proposal. It is more credible and it changes what you promise.

A failed build is a real cost. The $40,000 to $70,000 is spent whether or not the thing works, and the political cost of a second failed pilot is usually larger than the first invoice. That is a reason to scope narrowly, not a reason to wait.

The savings are a range, not a figure. I have given you arithmetic from stated assumptions. Your volume, your utilisation, your exception rate and your rework rate will move that table by a lot. Anyone who hands you a single confident number for a process they have not measured is guessing.

Waiting for cheaper models is a bad trade, and here is the arithmetic. If inference is $600 of an $11,900 annual run cost, a 50 per cent price cut saves you $300 a year. A single quarter of delay on the example above costs roughly $97,500 in run-rate. You would need to wait centuries for the price drop to repay the delay. Cheaper models do not change the decision; they change the shape of an already-correct answer.

What does the one-time cost actually buy?

An asset, in the accounting sense: something with a useful life that can be maintained, extended and pointed at the next problem. The integration, the evaluation set, the review queue, the failure taxonomy and the cost model you built for process one are most of what process two needs. In my experience the second automation in the same department costs a fraction of the first, and the third is mostly configuration. The manual process has no equivalent curve — it costs the same on its ten-thousandth run as its first, and when the person who understands it leaves, you pay again to reconstruct knowledge that was never written down.

This is the asymmetry the price comparison hides. A build is a purchase that depreciates into capability. A manual process is a subscription to a problem, renewed monthly, with no termination clause and no asset at the end of it.

What should you do before the next budget meeting?

Do not build a case for AI; build a measurement of one process. Pick the single highest-volume manual step in the department, count the instances for one month, time five of them yourself, and put the loaded rate next to the volume. That number is the run-rate of delay, and it is the only figure in the discussion that nobody can argue with, because it is made of your own payroll and your own data. Then price the build as a one-time cost against it, state the payback in months, and state plainly which savings are cash and which are capacity. If the payback is under a year and the process is genuinely high-volume, waiting is not the cautious option — it is the expensive one, and it is expensive on a schedule you can calculate before you decide.