How to calculate the return on an automation project
A simple formula, the costs almost everyone forgets, and the benefits that don't fit a spreadsheet but decide whether the project was worth it.
April 8, 2026 · Diego Osvaldo Díaz · 3 min read · Updated on
The return on an automation is calculated by comparing the project's total cost against the annual saving it generates: hours freed and valued, errors avoided, and operating costs that disappear. The formula is simple; what usually goes wrong is what gets counted on each side.
The formula
Annual return = (annual saving − annual cost to operate) ÷ initial investment. If the result is 1, the project pays for itself in a year. If it's 2, in six months.
The formula isn't the point: what matters is that both numbers feeding it are complete.
The cost side: what gets forgotten
- Development or licensing, which is usually the only thing counted.
- Mapping and designing the workflow, before any code is written.
- Preparing and migrating the existing data.
- Training the team that will use it.
- The infrastructure it runs on, month after month.
- Maintenance and later evolution.
- Your own team's time during implementation.
That last item is the most ignored and sometimes the most expensive: if three people spend an afternoon a week for two months validating and testing, that's real time that has to be counted.
The saving side: how to value it
Freed hours are valued at the real cost of an hour, not salary divided by hours. Gross salary has to carry social charges and indirect costs on top.
And one distinction changes the calculation: freeing hours that get reassigned to higher-value work isn't the same as freeing hours of someone who will be there anyway. In the first case the saving is real; in the second, the benefit is extra capacity without hiring, which also counts, but counts differently.
Errors avoided
This item is rarely calculated and is usually large. Estimating it takes two figures: how many errors occur per period and what each one costs, counting detection time, correction, and the consequences for the customer.
What doesn't fit the spreadsheet
There are real benefits that don't translate easily into a number, and it's better to list them separately than to invent a value for them:
- Capacity to grow without adding administrative structure.
- Full traceability for audits and disputes.
- Customer response time, which affects sales.
- Less dependence on one specific person being available.
- Information available to decide with, instead of reconstructing it.
Measure afterwards, not only before
The upfront calculation is an estimate; the one that matters is the one after. That's why the baseline has to be recorded before implementing: how long it took, how many errors there were, how many hours it consumed. Without that first snapshot, nothing can be proven later and the discussion becomes an opinion.
Return is calculated as annual saving over total investment, including mapping, data, training, infrastructure, and your team's time on the cost side. Value hours at real cost, estimate errors avoided, and list the non-numeric benefits separately. And measure the baseline before you start.
Frequently asked questions
How long does an automation take to pay for itself?
It depends on process volume and project cost. High-volume, low-complexity workflows usually pay back quickly; those needing many integrations take longer and are best done in stages.
How do I value the hours saved?
At the real cost of an hour, adding social charges and indirect costs to gross salary. And distinguish between hours reassigned to higher-value work and extra capacity without hiring: they're different benefits.
Which costs are most often forgotten?
Upfront mapping, data preparation, training, monthly infrastructure, and your own team's time during implementation.
What if the return can't be calculated?
That usually means the baseline is missing. Before implementing, record how long the current process takes, how many errors it produces, and how many hours it consumes.