Most automation ROI calculations ignore what comes after. How to calculate properly: setup, maintenance, monitoring, and how much work genuinely disappears.
Key takeaways
- Automation does not delete work but replaces it - with monitoring, exceptions and maintenance.
- An hour saved is worth something only when it accumulates into a usable block.
- The year-two cost is what decides it, not the build cost.
- Automation that prevents errors is sometimes worth more than automation that saves time.
The usual automation ROI calculation makes two errors: it assumes every saved hour is freed, and it ignores the cost after setup. An honest calculation includes what happens in year two - and that is precisely what decides whether the project paid off.
The three cost components
| Component | What it includes | When you pay |
|---|---|---|
| Setup | Analysis, build, testing, first fixes | One-off |
| Running | Tool subscription, per-action cost | Ongoing |
| Maintenance | Changes, fixes, monitoring, whoever owns it | Ongoing, and unbudgeted |
The third row is absent from most calculations. Automation lives alongside systems that change - a vendor updates a version, a form changes, somebody adds a field - and each such change requires an adjustment.
What goes on the savings side
- Direct hours saved, times the fully loaded hourly cost.
- Errors prevented, times the average correction cost.
- Response time reduced, where it translates into deals.
- Work made possible - what you can now do that you could not before.
The second component is often the largest and rarely calculated. The method is set out in what manual work costs, and it rests on genuinely counting errors for a month rather than estimating.
The common error: assuming every hour frees up
Saving five minutes a day is not a saving but a relief. It is pleasant, but it translates into nothing measurable, because the time disperses.
What does count: a continuous hour a day, or a full day a month. Those are blocks you can decide what to do with. So when calculating ROI, ask not only how many hours were saved but in what shape - and when the answer is "a little each time", the real saving is smaller than the number.
Why preventing errors is worth more
An error costs in three layers: correction time, the direct cost (a redelivery, a credit), and the damage to the customer relationship. Automation preventing one error a week saves more than automation saving ten minutes a day, in most businesses - and none of that appears in a time-focused calculation.
So when comparing two possible automation projects, check not which saves more hours but which prevents more errors that reach customers.
What happens in year two
This is what separates a calculated ROI from a real one. In year two there is no setup cost, but there are three others: ongoing maintenance, changes required when something in the environment shifts, and the running cost. Against that, the saving continues in full.
In most cases good automation repays itself in year one and produces net gain in year two. Automation that has not repaid itself within two years was probably built on a process that should never have been automated - a distinction covered in automating the wrong things.
How to calculate before building
- Measure the current state for two weeks - frequency, time, errors.
- Estimate the saving across the three components.
- Get a full build estimate, including testing.
- Add an annual maintenance estimate - absent a figure, assume a percentage of the build.
- Compare over two years, not one.
- Decide - and write down what will be measured afterwards, so it can be checked.
Point 6 is almost never done, and it is what lets you learn for the next project. With no measurement afterwards, every automation is judged a success in hindsight.
What is left for a person after automation?
That question reveals how much of the saving is real. Even in successful automation three kinds of work remain: exceptions - the cases that did not fit the rule; checking - somebody confirming what should have run did run; and failure handling - when something breaks, somebody fixes it.
Those three are not a failure of the automation but part of it, so they belong in the calculation. In practice, in most good automations they occupy a small fraction of the original time - and that is exactly the saving. In weaker ones they occupy nearly the same time in a different role.
The simple check, two months in: ask whoever previously performed the process how much time they now spend on it. Their answer is more accurate than any report.
What to measure before deciding to build
Three numbers, all collected in a fortnight: how many times a week the process happens, how many minutes it takes on average, and how often per month it goes wrong. Without those three, every ROI calculation rests on estimates - and because estimates tend to flatter the proposed solution, the result is nearly always too optimistic.
Collecting them needs no tool: a short record in a spreadsheet, by whoever performs the work, once a day. What matters is that the same person records the same way throughout, because the comparison after the build will be made against exactly these numbers.
How do you compare two automation options?
Not by which sounds more impressive. Three questions decide it: which touches a process that happens more often; which prevents an error that reaches a customer; and which will need less maintenance when something in the environment changes.
The third gets forgotten and is often counter-intuitive: an impressive automation connecting four systems breaks every time one of them changes, while a simple one touching two holds for years. When maintenance capacity is limited - and in most small businesses it is - the simple one wins even when it saves less.
That is also why it is worth starting with the smallest useful automation rather than the complete one. A narrow automation that runs for a year teaches you what the full version should look like, at a fraction of the cost of guessing up front.
Sources
Frequently asked questions
How much maintenance should we assume?
With no figure from the vendor, a conservative assumption is a percentage of the build cost each year. More important than the number is having some budget: automation with no maintenance budget breaks and nobody fixes it, which is worse than not building it.
What if the calculation comes out marginal?
Check whether the process can be simplified instead of automated. In most marginal cases a process change is cheaper and captures much of the benefit - and it leaves the option of automating later, on a simpler process.
Is an automation tool cheaper than development?
To build, yes; to maintain, it depends. A tool lowers the barrier and suits simple flows; at high volume or with complex logic, running costs and failures can exceed development. The choice mainly depends on volume and complexity.
What do you measure afterwards?
The same three numbers measured before: frequency, time, and errors. If you did not measure before, you cannot know - which is why the first step in the calculation is measuring rather than estimating.
Keep reading
Related service
MVP Development
Turn an idea into a validated product in weeks, not months.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.