Automation ROI calculator
The work today
Everyone who spends time on it, not just one team.
Time on this task alone.
Salary plus employer costs.
What the project would cost
Be pessimistic. Usually under 50 %.
Build, integration and rollout together.
Licences, hosting, maintenance.
Hours freed per year
1,175
Value, net of running cost
$58,500
Pays for itself in
12.3 months
- Hours freed
- 10 people × 5 h × 47 weeks × 50 % = 1,175 h
- Value of those hours
- 1,175 h × $60 = $70,500
- Year one, everything deducted
- $70,500 − $12,000 − $60,000 = -$1,500
This is an estimate, not a forecast and not a promise. It is your assumptions multiplied together, shown step by step so you can argue with each one. The number that is wrong is almost always the automatable share: measure it on a sample of real cases before you trust any of this.
This tool multiplies six numbers you supply and shows every step, which is the whole of what it does. It does not know your industry, it holds no benchmark, and it contains one constant: a working year of 47 weeks, being 52 less five for leave and public holidays. Using 52 would inflate every result by about a tenth, which is why the figure is stated here rather than buried in the code. The output is not a forecast and not a promise. It is the consequence of your own assumptions, laid out so that you can argue with each one separately instead of arguing with a total. If the result surprises you, the input to re-examine is almost never the hourly cost. It is the share of the work you believe can be automated, which is the number people are most confident about and most often wrong about.
How to get the automatable share right
Every other input on this page is either known or knowable. The number of people is a fact. The hourly cost is in a payroll system. The project cost is a quote. The automatable share is a judgement, it dominates the result, and it is routinely overestimated by a factor of two.
The reason is a specific and understandable error. When people picture the task, they picture the standard case, because that is what comes to mind. The standard case usually is automatable. What consumes the time is the exceptions, and exceptions are exactly what does not come to mind when you are asked to estimate.
The fix takes about an hour and is worth more than any refinement to this model. Take twenty real cases from last month, at random rather than chosen. For each one, decide whether the system would have handled it end to end with no person checking the output. Count. That fraction is your automatable share, and it is usually somewhere between a fifth and a half where the first guess was three quarters.
What this calculator deliberately leaves out
Adoption risk. The largest omission. A system that works correctly and goes unused returns nothing while continuing to cost the recurring fee. The calculator cannot see that risk, which means the result should be read as the ceiling of what is available if adoption succeeds rather than as an expected value.
The freed hours not converting to money. Freeing 1,200 hours across ten people does not reduce a payroll. It gives ten people about two and a half hours a week back, and whether that becomes value depends entirely on what they do with it. Organisations that have decided in advance what the freed time is for realise the value. Organisations that have not tend to find, a year later, that the time was absorbed.
Quality changes in either direction. Automation sometimes improves outcomes in ways worth more than the time saved, and sometimes degrades them in ways that cost more. Both effects are real and neither is estimable in advance without measuring, so putting a number on them here would be inventing one.
Second-year economics. The model shows year one. From year two the project cost is gone and only the recurring cost remains, so a project that looks marginal in year one is often clearly worthwhile across three. The payback figure captures this, but the first-year total does not, and reading only the total understates most real projects.
Reading the result honestly
A payback under twelve months means the project is defensible on cost alone, and the decision moves to whether it can actually be delivered. A payback between one and three years means the project has to be justified on something other than the arithmetic, which is legitimate: quality, risk reduction, or a capability the organisation wants to build. A payback that never arrives means the recurring cost exceeds the value, and no amount of execution fixes that.
The case worth pausing on is a payback of about five months on a first project. That result is usually produced by an automatable share that has not been measured. Measuring it, using the twenty-case method above, is a better use of an hour than any further work on the model.
What we use this for
We put this on the site because it is the first conversation we have with most companies, and because it is short enough to have honestly. A great many automation projects are worth doing and a meaningful minority are not, and the second group is easier to identify before the build than after it.
If the arithmetic here says a project is not worth it, that is a useful answer and we would rather you had it from a calculator than from us after six weeks. If it says the opposite, the next question is not how much it is worth but whether it can be delivered inside your organisation, which is a different question and the one our work is actually about.
