Stuart Totterdell
Technical Director
I am going to give you the entire financial case for your next automation project. It fits in one paragraph.
Take the process you want to automate. Count the hours your team spends on it per week. Multiply by the blended cost per hour of the people doing the work. Multiply by fifty-two. That is your annual cost. Now get a quote for automating it. If the project cost is less than the annual cost, the payback is under twelve months. Do it.
That is it. That is the entire business case. And yet most mid-market businesses spend months debating whether automation is "worth it" - commissioning feasibility studies, requesting detailed ROI analyses, forming steering committees, and ultimately deferring the decision because the case was not compelling enough.
The case is always compelling. They just made the calculation harder than it needs to be.
Why the maths is simple
Automation removes manual effort from a process. The value of that removal is the cost of the manual effort it replaces. Everything else is secondary.
If your finance team spends three days per month on manual reconciliation - the daily cost of skipped data and systems integration - and the blended cost of the people doing that work is £35 per hour, the annual cost of that reconciliation is roughly £8,400. If automating the reconciliation costs £15,000, the payback period is twenty-one months. If it costs £6,000, the payback is eight months.
That calculation takes two minutes. It does not require a consultant. It does not require a steering committee. It does not require a twelve-page business case. It requires knowing how long the process takes, what the people doing it cost, and what the business automation would cost to build.
Most businesses have the first two numbers already. They just never ask for the third.
What people add that makes it complicated
The reason automation business cases stall is not that the maths is hard. It is that people add layers to the maths that obscure the obvious.
They add "strategic alignment" - does this project fit the digital transformation roadmap? This question delays the decision by weeks while someone maps the project to an IT and process strategy document that has no bearing on whether the automation saves money.
They add "risk assessment" - what if the automation breaks? What if the process changes? What if we need to maintain it? These are legitimate questions, but they are answerable in an afternoon, not a quarter. And they rarely change the fundamental economics.
They add "opportunity cost" - should we spend this money on automation or on something else? This is a valid question that becomes invalid when the something else is never specified. The comparison is not automation versus an alternative investment. It is automation versus continuing to pay people to do work that a system could do.
They add "change management" - will the team accept it? Will we need training? Will there be resistance? These are implementation questions, not financial questions. They belong in the project plan, not in the business case.
By the time all of these layers have been added, the two-minute calculation has become a three-month exercise. The decision is deferred. The manual process continues. And the business keeps paying £8,400 per year for work that should have been automated six months ago.
The payback threshold
For most mid-market automation projects, the payback period is between three and eighteen months. That is remarkably fast compared to almost any other business investment.
A new hire takes six to twelve months to become fully productive. A new system implementation takes twelve to twenty-four months to deliver measurable results. A marketing campaign may take months to generate attributable revenue.
An automation project that removes twenty hours per week of manual work starts delivering value the day it goes live. The payback clock starts immediately. There is no ramp-up period. There is no learning curve for a system that does the work without human involvement.
If the payback period is under twelve months, the project pays for itself within the financial year. Every month after that is pure return. If the payback is under six months, the project is delivering two-to-one returns within the first year.
By the standards of any investment evaluation framework, these are exceptional numbers. And they are typical for well-scoped automation projects, not exceptional.
The cost of not doing it
There is a calculation that businesses never make, and it is the most important one: the cost of delay.
Every month that a manual process continues to run is a month of cost that could have been eliminated. If the process costs £700 per month in labour and the automation would have removed that cost, every month of delay costs the business £700.
A six-month delay in a decision that was always going to be made costs £4,200. A twelve-month delay costs £8,400. That is the price of the steering committee, the feasibility study, and the deferred decision.
The cost of delay is never tracked. It never appears on a report. But it is real, it is cumulative, and in most mid-market businesses, it exceeds the cost of the automation project itself.
The napkin test
Before you commission a feasibility study, do the napkin test.
How many hours per week does this process consume? What is the blended hourly cost of the people doing it? What would a reasonable automation project cost?
If the annual saving exceeds the project cost, the payback is under twelve months. If the annual saving is double the project cost, the payback is under six months. If the annual saving is three times the project cost, you are losing money every week you delay.
You do not need a business case to tell you this. You need a napkin, a pen, and five minutes.
The financial case for automation is not complicated. It is ignored. And every month it is ignored, the cost of the manual process continues to compound while the decision to fix it waits for a meeting that has been rescheduled three times.
Do the maths. It takes two minutes. The answer is almost always yes.
