Automation is sold in hours and bought in pounds, and the translation between the two is where most business cases quietly fall apart. Here is the arithmetic done honestly, including the cases where the answer is don't.
Start with the real hours
The number people quote is the time the task takes when it goes well. That is not the number.
Count the whole loop: the doing, the checking, the correcting, the chasing when a piece is missing, and the switching cost of being interrupted to do it. A ten-minute task that happens six times a day and breaks concentration each time is not an hour a day. It is an hour a day plus the tail of every interrupted thing.
You do not need precision here. You need the right order of magnitude, and the honest figure is usually between 1.5 and 2 times the naive one.
Then convert honestly
The common mistake is multiplying saved hours by a salary rate and calling it a saving. It is only a saving if one of two things is true: someone leaves and is not replaced, or the freed hours go to work that produces money.
Neither is automatic. If four hours a week come off an already-busy person's plate and get absorbed by other work, you have bought capacity — which is real and worth having, but it does not show up in the accounts and you should not pretend to your board that it will.
So write the case in the honest form: this removes N hours a week; those hours will go to X; here is what X is worth. If you cannot name X, say that too. "Capacity" is a legitimate answer. "Cost saving" usually is not.
Count the error side, because it is often bigger
The hours are the visible half. The error cost is frequently larger and almost always left out.
A mistake in a manual process costs the correction, the apology, sometimes the customer, and occasionally a regulatory conversation. If you handle regulated or financial data, a single reportable error can cost more than the entire automation project.
You will not have a precise figure. Use the last one that happened. What did it cost in time and money to put right? How often does that happen? That is your number, and it is defensible because it is a real event rather than an industry average.
The one-off costs people forget
Build cost is the obvious one and rarely the surprise. The surprises are: the data cleanup you discover you need once you look properly, the process decisions nobody had ever written down and now must, the training, and the parallel-running period where you do both.
Budget the parallel run. It is how you find out the automation is wrong before it is the only thing doing the job, and skipping it is the single most common reason automation projects get switched back off.
When the answer is don't
The process is about to change. New system next year, new regulation, restructure. Automate after, not before.
The volume is low. Below a few times a week, the payback stretches past the point where anything in the business is still the same.
The judgement is the job. If the human is deciding rather than transcribing, automating the transcription is worth doing and automating the decision is not.
It is a symptom. If the manual work exists because two systems were never connected, connecting them is the project. Automating the copying is treating the symptom and locking in the cause.
The honest summary
The arithmetic is simple: real hours plus error cost, against build cost plus the run cost nobody budgets. If it does not clear that bar comfortably, it is not close — because every project overruns and the ones that only just worked on paper do not work at all.
The good news is that this is a week's analysis, not a quarter's. If you would rather have someone who has no incentive to sell you the build do the arithmetic, that is exactly what the Reality Check is: one week, one number, and "do nothing yet" is an answer it is allowed to give.
This is the part we do — the crossing from a demo to a system that survives production.