Here is the direct answer: automation ROI is (total benefits minus total costs) divided by total costs, expressed as a percentage. The formula is simple. What trips most businesses up is not the maths. It is filling in both columns with honest numbers before anyone has committed to anything.
This post covers the formula, what belongs in each column, a real before-and-after example from my own work, and the rule I apply when the numbers say stop.
TL;DR
Automation ROI is (total benefits minus total costs) divided by total costs. Benefits should include time saved, error reduction, and capacity to scale. Costs should include everything, including the things nobody mentions in the vendor demo. If you cannot name a measurable target before starting, do not start. Run the numbers first. Then decide.
Photo: Pexels
What automation ROI actually tells you
ROI is a ratio. It tells you how much value you are getting back for every euro you put in. An automation ROI of 200% means you get three euros back for every one euro spent. A ROI of negative 20% means you lost money. Simple.
The formula:
If your benefits total €60,000 and your costs total €20,000 over a 12-month period, your ROI is 200%.
The catch is that most businesses get both numbers wrong. Benefits get overestimated. Costs get underestimated. By the time implementation is done, the spreadsheet that promised 300% ROI is delivering 40%. (The spreadsheet does not apologise. It just sits there looking very confident in its original assumptions.)
The 12-month window is the right frame for most SME automation projects. Long enough to see real savings. Short enough to hold the business case accountable.
What goes in the benefits column
This is where most calculations go wrong, in the optimistic direction. Benefits are real only if someone was doing the work manually before, the time is genuinely freed up after, and you can put a number on it.
Time savings
Take the number of hours per week spent on the task manually. Multiply by the fully-loaded hourly cost (salary plus overheads, usually 1.3 to 1.5 times gross salary). Multiply by 52. That is your annual labour saving.
The rule of thumb: assume you will recapture about 70% of the theoretical time saving, not 100%. People do not magically fill freed-up time with productive work on day one. There is overhead, transition, re-learning. Use 70%.
Error reduction
If the manual process produces errors at a known rate, calculate the cost to fix them: rework time, credit notes, customer service calls, audit findings. These are real costs. They often dwarf the labour saving, and they are almost always left out of the first draft of the business case.
Capacity to scale
If the manual process is a bottleneck on revenue, automation removes the ceiling. A team processing 200 invoices per week by hand cannot process 400 without hiring. After automation, they often can. That scalability has real value, even when it is harder to put on a spreadsheet.
What does not belong
- "Productivity gains" that nobody will actually use
- Assumed headcount reductions you are not actually making
- Future benefits from a system that does not exist yet
- Speculative downstream revenue ("if we use the time savings to grow revenue by...") — one degree of speculation is enough
What goes in the costs column (and what people bury)
The costs column is where things get creative, in the wrong direction.
Implementation costs
In my experience across 100+ projects, a well-scoped SME automation project runs €5,000 to €15,000. That includes scoping, build, testing, and training. Write that number down before you hear the vendor's pricing. It will help you calibrate what is realistic.
Ongoing costs
Software subscriptions, API fees, maintenance, monitoring. These are annual, not one-off. Calculate them per year and include them in your 12-month cost figure. Most vendors do not lead with this number in the demo.
Internal time
Your team will spend time on this project. The person who knows the process has to explain it, review it, test it, and sign off on it. That time is not free. Budget 20 to 40 internal hours on a typical SME project. Cost those hours at the same fully-loaded rate you use for the benefits column.
Exception handling
Automated processes break on exceptions. A vendor invoice in an unexpected format. An approval that needs a judgment call. Someone has to handle those. Most implementations see 5 to 15% of transactions needing human review after automation. Include the time for that in your annual cost.
Change management
If your team does not understand what changed and why, they will work around the automation, or use it incorrectly, or both. I have watched this happen. You do not need a six-month change programme for a process automation project. You do need a proper walkthrough, a clear escalation path, and someone on the team who owns it. Budget accordingly. This is the one people always forget to include, and the one that most often causes the real cost to exceed the estimate.
Photo: Pexels
The construction company that did the numbers properly
The clearest automation ROI example from my own work was not dramatic. No AI. No machine learning. Just an honest before-and-after.
A construction company was processing 200 invoices per week across a 4-person finance team. All manual: processing, matching, chasing approvals, filing. The team was at capacity and the business was growing.
Before we touched anything, we ran the numbers. Cost of manual processing per invoice (time, overheads): approximately €8 to €12. Annual processing cost for 200 invoices per week: roughly €83,000 to €125,000. The team wanted to scale to 400+ invoices per week as the business grew. That would have meant hiring two more people at significant cost.
After automation: same 4-person team. Processing capacity up to 500 to 800 invoices per week. Manual effort down 60 to 80% per person. No new hires needed to scale.
The implementation cost: within the €5,000 to €15,000 range. Payback period: under three months. Year-one ROI: clearly positive, and specifically calculable, which is what made the business case straightforward to approve.
The reason it worked: we ran the numbers first, not last. By the time I quoted the project, the client already knew the answer was yes. The maths had done the work. The meeting was fifteen minutes.
You cannot calculate ROI on a process you have not mapped
Here is the thing that trips most ROI calculations up before they start.
If you do not know what your process actually is, you cannot estimate how long it takes, how often it fails, or what it costs. And if you cannot estimate those things, you cannot fill in either column of the ROI calculation with honest numbers.
I have seen businesses come in with "we want to automate our onboarding process." When I ask how long onboarding currently takes, the answers range from "about a week" to "it depends" to "honestly, I am not sure." You cannot calculate ROI on a process nobody can describe.
The fix is not complicated. Spend half a day mapping the process. Write down every step, who does it, how long each step takes, and where it breaks. I wrote about how to do this in my process mapping guide. It takes a few hours and it changes the quality of every conversation you have with every vendor afterwards.
Once you have the map, the ROI calculation becomes straightforward. Without it, you are guessing on both sides of the equation. (The cost of not mapping first, in my experience: about 12 weeks of rework after go-live. Do the maths on that one before you decide the mapping is not worth the afternoon.)
Photo: Pexels
Why automation ROI disappoints more often than it should
In 100+ automation projects, I have watched well-intentioned business cases fail to deliver. The reasons are consistent.
Scope was wrong from the start
The automation was built for the happy path. Nobody accounted for exceptions, seasonal spikes, or the 15% of cases that look slightly different from the norm. When those cases arrive, manual intervention fills the gap and the projected time saving disappears.
The process was not documented before automation
This is the most common failure mode. If the process had undocumented steps or workarounds that nobody mentioned during scoping, the automation inherits those problems at speed. Garbage in, garbage out, but faster.
Benefits were counted at 100%, not 70%
Theoretical time savings are not actual time savings. People do not instantly repurpose freed-up time into productive output. The realistic recapture rate is 60 to 80%. Build that into the model from the start, not as a post-implementation excuse.
Nobody owns the output
Automation that nobody monitors is a liability, not an asset. There needs to be one named person who reviews exceptions, gets alerted when something breaks, and makes the call to escalate. Without that, problems compound silently until someone notices the numbers are wrong.
The vendor demo was the business case
A slick demo is a best-case scenario with clean data, no exceptions, and a sales team who have rehearsed it forty times. It is not a business case. Build your own numbers. Do not accept the vendor's projections as the baseline for your investment decision.
The McKinsey Global Institute consistently finds that the gap between projected and realised automation benefits comes down to implementation quality, not the technology itself. Better scoping, better documentation, better ownership. The formula is simple. The discipline is not.
When the numbers say stop
My rule, applied consistently across 100+ projects: if a project costs more than €5,000 and you cannot point to a measurable ROI target before starting, kill it.
Not pause it. Not "let us see how it goes." Kill it, go back to the process, understand what you are actually trying to achieve, and return when you can describe a specific outcome in a specific time frame.
This sounds harsh. It is not. It is the single most useful thing a business can hear before committing budget to an automation project.
Projects that run long, go over budget, and fail to deliver are almost always the ones that started without a clear ROI target. The scope drifts because there is nothing to hold it in place. Features get added because nobody can say "that is outside the brief." Everyone is busy, but nobody is accountable for a specific outcome.
A measurable ROI target is not a guarantee. But it is the thing that keeps a project honest from week one to go-live.
And honestly: if the honest numbers say the ROI is marginal, listen to them. A basic workflow automation that saves two hours a week for one person is not a €15,000 project. Sometimes the right answer is a €0 solution: a well-configured email rule and a shared folder. I have talked clients out of projects for exactly this reason. I reckon that is a feature of a good consultant, not a bug. See also my post on how to choose automation software for a framework on when to buy something and when to keep walking.
How to build your business case in an afternoon
You do not need a consultant to build an automation ROI business case for an SME project. Here is the process.
Map the process
Time each step. Write down who does it, how often, and where it breaks. If you skip this step, every number that follows is a guess.
Calculate the annual cost of the current process
Hours per week times fully-loaded hourly rate times 52. Add error correction time. Add any bottleneck cost if the process is currently limiting growth.
Get a realistic implementation quote
€5,000 to €15,000 is the range for most well-scoped SME projects. Add annual software costs. Add 20 to 40 hours of internal time at your own fully-loaded rate.
Apply the 70% recapture rule
If the time saving is 10 hours per week, count 7 hours in your calculation. Build the conservative number into the model, not the optimistic one.
Calculate ROI over 12 months
(Year 1 benefits minus Year 1 costs) divided by Year 1 costs, times 100. If the number is negative or near zero, the project does not make sense at this scope. If it is clearly positive, you have a business case worth defending.
Name the owner
One person. Named. With a clear escalation path. If you cannot name that person before starting, go back to step one. Automation without an owner is a timer, not a solution.
I have had this conversation about 100 times. The pattern is consistent: the businesses that run the numbers first make better decisions, faster. The ones that skip straight to the vendor demo spend the next six months second-guessing themselves. Run the numbers first.
If you want more on the surrounding decisions, the posts on business process automation and process mapping before automation cover the work that needs to happen before the ROI calculation even starts. Read those first if the numbers keep coming out fuzzy. The problem is almost always upstream.
For a thorough breakdown of how the ROI calculation connects to process maturity, the BOC Group write well on this if you want a second perspective from a different angle.
Frequently asked questions
What is the formula for automation ROI?
ROI = (Total Benefits - Total Costs) / Total Costs x 100. Calculate over a 12-month window. Benefits include time savings at fully-loaded hourly cost (discounted to 70% of the theoretical saving), error reduction, and scalability value. Costs include implementation, annual software subscriptions, internal time during the project, and ongoing exception handling.
What is a good ROI for automation?
A well-scoped SME automation project should return positive ROI within 12 months. A project costing €5,000 that saves 10 hours a week at €35 per hour fully loaded returns roughly €9,000 in year one after applying a 70% recapture rate. That is about 80% ROI in the first year, and savings compound from there. If the honest numbers cannot reach positive territory in 12 months, the scope or the process is wrong.
How long does automation take to pay back?
For well-scoped SME projects in the €5,000 to €15,000 range, payback typically runs 3 to 9 months. The faster the payback, the higher the transaction volume being automated. Invoice processing on 200+ transactions per week can pay back in under three months. A lower-volume administrative process might take closer to 12 months. The calculation is project cost divided by monthly savings.
What should I include in an automation ROI calculation?
Benefits: time saved (at fully-loaded hourly cost, discounted to 70% of theoretical saving), error reduction cost, and capacity to scale without hiring. Costs: implementation, annual software subscriptions, internal time during the project, and ongoing exception handling. Do not include headcount reductions you are not actually making or speculative downstream benefits.
Why does automation ROI often disappoint?
The most common reasons: scope did not account for exceptions and edge cases, the process was not properly documented before automation, benefits were counted at 100% rather than the realistic 60 to 80% recapture rate, and nobody was assigned to own the output after go-live. All of these are avoidable with a proper scoping process before implementation starts.
Is automation ROI only about saving on labour costs?
No. Labour saving is usually the most visible benefit but rarely the only one. Error reduction, compliance improvement, and the ability to scale without proportional headcount increases can each be worth more than the direct labour saving. In high-volume transaction processing, the scalability benefit is often the largest number in the calculation.
Can small businesses calculate automation ROI before investing?
Yes, and they should. The calculation does not require specialist software or a consultant. Map the process, time each step, calculate the annual cost, get a realistic implementation quote, and run the ROI formula. It takes an afternoon. If the numbers do not work, you have saved yourself a significant sum and several months of disruption.
When should I not proceed with an automation project?
When you cannot name a specific, measurable outcome before starting. When the honest ROI calculation is negative or near zero over 12 months. When the process has not been documented and nobody can describe what it actually involves. When nobody has been identified to own the output after go-live. In any of these cases, pause the project, address the gap, and return when the foundation is solid.
Tijdo Koster
Automation consultant since 2009. 100+ projects. Still answers his own emails.
If you have made it to the bottom and your main takeaway is that I just talked you out of a project, that is not an accident. The most useful thing a consultant can do is tell you when the numbers do not add up. Saves everyone time. Including mine.
More on the blog if you want to keep going. The products page has the toolkit for when the ROI calculation says go and you want an opinionated view on which tools to actually buy. The dad jokes about spreadsheet optimism are distributed evenly throughout.