Short answer
Measure the process before you change it — volume, elapsed time, error rate, and who touches it. Count the full cost, including the internal hours spent specifying and testing, ongoing maintenance, and the cost of wrong outputs. Then claim only returns that show up somewhere real: a hire avoided, volume handled without adding people, revenue enabled, or a genuinely quantified error cost. Time saved that nobody reallocates is a comfort, not a return, and calling it one is why automation programs lose credibility.
The hours-times-rate fallacy
The standard calculation goes: this task took four hours a week, the person costs so much per hour, therefore we save that much per year. It is arithmetically fine and financially meaningless, and any competent finance person will say so within a minute.
The reason is simple. Nobody's salary changed. The four hours went somewhere — into other work, into slack that was always there, into work expanding to fill the time. Unless you can name what those hours now produce, or name the cost that stopped being incurred, no money moved.
This matters beyond bookkeeping. When the first project is justified with a number nobody believes, the second one is harder to fund — regardless of whether it was actually a good investment.
Measure the before, or measure nothing
This is the step that cannot be recovered later, and it is the one that gets skipped. Once the process has changed, the previous state exists only as opinion, and opinion after the fact is systematically generous to the project.
Record four things for two weeks before you build anything.
- Volume — how many times the process runs in a period. Count it; do not estimate it. Estimates are wrong by a factor that is rarely small.
- Elapsed time — from trigger to completion, including the waiting. Waiting is often where the real cost sits, and it is invisible in a time-per-task figure.
- Error rate — how often the output is wrong, and what correcting it costs. If nobody knows, that itself is a finding.
- People touched — how many handovers occur. Handovers are where delay accumulates and where automation usually pays.
Two weeks of honest observation costs almost nothing and is the difference between a claim and a measurement.
The costs everyone leaves out
Business cases tend to count subscription fees and stop. The costs that actually determine the outcome are these.
- Internal specification and testing time. Usually the single largest cost, and almost never counted because it is nobody's invoice. Deciding what the process should be, testing it, and correcting it takes real hours from people who are not free.
- Maintenance. Connected systems change. Something will break two or three times a year and someone will spend a day on it.
- Review time. If a person checks the output, that time belongs in the running cost. An automation with full review is cheaper than manual work only if reviewing is genuinely faster than doing.
- The cost of being wrong. What a bad output costs to detect and undo, multiplied by how often it occurs. For a client-facing process this can dominate everything else.
Many of these are consequences of decisions made during the build. Getting them right early is the subject of automation without developers.
The three forms a real return takes
A return that a finance function will accept takes one of three shapes. Decide which one you are claiming before you build the model, because they are measured differently.
- Cost avoided. A hire you did not make, an overtime bill that stopped, an outsourced task brought back in. The strongest form because the counterfactual is concrete and datable.
- Capacity gained. The same team now handles materially more volume without growing. Real, and only real if the volume actually arrived — capacity for demand that never came is not a return.
- Revenue enabled. Faster response wins deals you were losing, or the automation makes a chargeable service possible. Hardest to attribute honestly, and worth the most when you can.
Anything that does not fit one of these three is a qualitative benefit. Those are legitimate and worth stating — just state them as what they are rather than converting them into a figure through three layers of assumption.
A calculation that survives review
The method in five steps, none of which is clever.
- Write the baseline down before touching the process, using counts rather than recollection.
- Name in advance which of the three return forms you expect, and what evidence would demonstrate it.
- Total the full cost over three years, including internal hours and maintenance, not just fees.
- Run for ninety days after the initial novelty has passed, then measure the same four baseline metrics again.
- Report what you measured, with the assumptions visible and separated from the measurements.
That last point does more for credibility than any number. A case that says "we measured a 40 percent reduction in elapsed time, and we assume — but have not demonstrated — that this converts into capacity" is far stronger than one presenting an unexplained euro figure. The first invites scrutiny and survives it.
Knowing when to stop
Decide the kill criteria at the start, while nobody is attached to the outcome. Sunk cost is the dominant force in automation programs, and it operates most strongly on the person who built the thing.
Reasonable criteria: the error rate has not fallen below the manual process after ninety days; review time exceeds the time the automation saves; the workflow has broken more than a set number of times and each break costs a day; or nobody has used it for a month, which is the clearest signal of all.
Turning off an automation that does not earn its keep is a sign of a healthy program, not a failed project. The failure is the one that keeps running, trusted by everyone, measured by no one.
The same discipline applies to visibility work, where the temptation to report activity instead of outcomes is even stronger — see what generative engine optimization actually is.
Frequently asked questions
Why do time savings so rarely show up in the accounts?
Because saved minutes are not the same as reclaimed cost. Twenty minutes a day returned to five people is real relief and changes no line in the accounts — nobody is paid less, and the time is absorbed by other work. It becomes financially visible only when it removes a hire you would otherwise have made, allows the same team to handle materially more volume, or converts into revenue-producing activity you can point to. Say which of the three you are claiming before you calculate anything.
What costs get forgotten in automation business cases?
Four, consistently. The internal time spent specifying, testing and correcting the process — usually the largest single cost and almost never counted. Ongoing maintenance when a connected system changes. The review time for anything a person still has to check. And the cost of being wrong: what a bad output costs to detect and undo, multiplied by how often it happens. A case that only counts license fees is not a case.
How long should we wait before judging a project?
Long enough to survive its own novelty. The first weeks are unrepresentative in both directions: people are careful, edge cases have not arrived yet, and the person who built it is still watching. Ninety days of steady running is a reasonable point to judge, provided you recorded the before state — which is the step almost everyone skips and cannot recover afterwards.
Is it acceptable for the return to be non-financial?
Yes, if you say so plainly instead of dressing it as a number. Faster response to clients, fewer errors in a process where errors are expensive, and work people stop dreading are all legitimate reasons to proceed. What damages credibility is converting those into a euro figure through a chain of assumptions, then presenting the figure as measured. State the qualitative benefit as qualitative and let it stand on its own.
If you want the baseline measured properly before anything gets built, that is how we start every engagement. Book a call and bring the process you would automate first.
