Interactive calculator
AI ROI Calculator: estimate the value of a better workflow
Model annual value from hours recovered, loaded labor cost, conversion improvement, and implementation cost using your own assumptions.
Introduction
What this calculator is for, and what it is not.
Most AI business cases are built backwards. Somebody decides the initiative is worth doing, then assembles the numbers that support it, and the resulting model is unfalsifiable because every input was chosen to produce the conclusion. This calculator is arranged the other way around: put in the four numbers you can actually defend, and see whether the arithmetic still works.
The model is deliberately simple. Annual recovered labour value is people multiplied by weekly hours saved, multiplied by loaded hourly cost, multiplied by fifty-two weeks. Subtract the first-year implementation cost and you have a net figure. There is no discount rate, no productivity multiplier, and no adoption curve, because every one of those would give you another place to hide an assumption.
That simplicity is the point. If the case only works with a compounding factor applied to a speculative baseline, it does not work. Use this to find out whether the honest version of your numbers clears zero, then validate the hours input against reality before you commit to anything.
The problem
The problem this is trying to surface.
The single most common defect in an AI business case is an unmeasured baseline. Someone estimates that the team spends ten hours a week on a task, the estimate is plausible, and it is never checked. But estimates of one own repetitive work are unreliable in both directions, and the entire model rests on that one number. If it is wrong by a factor of two, so is the conclusion.
The second defect is counting recovered hours as recovered money. Saving each of ten people three hours a week does not produce thirty hours of new output unless there is genuine demand for that capacity and the freed time is actually redirected. Sometimes it is. Often it becomes slack, which has value but not the value in the spreadsheet.
The third defect is undercounting implementation cost. The software price is easy and it is rarely the largest line. Setup, data cleanup, integration work, process redesign, training, and the internal time spent managing the change routinely exceed the licence fee, and they are the costs most often left out because nobody wants to own them.
You're likely here because
- You have been asked to justify an AI initiative and are not sure what the honest number is
- The vendor business case assumes hours you have never actually measured
- Nobody can say what the current process costs, only that it is annoying
- You want to know which workflow is worth automating first
How the inputs work
What each input does to the result.
Every input is something you supply, so the result is only as good as the honesty of the answers. Knowing how each one is weighted is what makes the output arguable rather than opaque.
Step 01
Count the people in the workflow
Only the people who regularly perform the work, not the whole department. Inflating this number is the fastest way to produce a model that does not survive contact with finance.
Step 02
Estimate hours saved conservatively
Use a figure you would be comfortable defending after two weeks of measurement. If you have not measured, halve your instinct — the estimate is almost always high.
Step 03
Use a loaded hourly cost
Salary plus taxes, benefits, and overhead. Using base salary alone understates the value of recovered time; using a blended executive rate overstates it dramatically.
Step 04
Include the full first-year cost
Software, setup, services, integration, and internal change time. The licence fee is usually the smallest component and the only one people remember.
Step 05
Read the net figure as a screen, not a forecast
The output tells you whether the case is plausible enough to pilot. It is not a projection, and it should never be presented as one.
Step 06
Validate before you commit
Measure the actual hours for two weeks, then re-run the model. A case that survives that check is worth acting on; one that does not was never real.
Implementation path
What to do with the result.
- 01
Pick one workflow with a clear trigger and a measurable completion event. A model built across a whole department averages away the thing you needed to see.
- 02
Measure the current hours for two weeks before trusting the estimate. This is the single highest-value step and the one most often skipped.
- 03
Use a loaded hourly cost from finance rather than a salary figure from memory.
- 04
Add every first-year cost you can name, including internal time. If the case only works when internal time is free, it does not work.
- 05
Run a bounded pilot on the one workflow and compare actual cycle time and exception volume against the baseline you took.
- 06
Re-run the model with the measured numbers before extending to a second workflow.
Controls
Controls that matter.
Control 01
A measured baseline rather than an estimated one before any commitment
Control 02
Implementation cost that includes internal change time, not just licence fees
Control 03
One workflow with a defined completion event, so the result is attributable
Control 04
A stated assumption list, so anyone reviewing the case can challenge the inputs directly
Examples
How teams read this in practice.
Patterns that recur when this is scored honestly, and what each one is actually telling you.
The model only works at ten hours
A case clears zero at ten hours saved per person and goes negative at four. That sensitivity is the finding: the decision depends entirely on an unmeasured input, so measure it before proceeding rather than after.
Implementation cost was the licence fee
A model counts the subscription and omits integration, cleanup, and internal change time. Adding those often moves a comfortable case to a marginal one, which is worth knowing in advance.
Recovered hours have nowhere to go
Ten people save three hours a week each and the team has no backlog of higher-value work waiting. The hours are real; the revenue is not. Say so in the case rather than letting the number imply otherwise.
The negative result is the useful one
A model that does not clear zero has told you something valuable for the cost of five minutes. Reduce scope to the highest-friction step, or pick a different workflow, rather than adjusting the inputs until they agree with you.
Limitations and considerations
What this tool cannot tell you.
- This is a directional estimate, not a forecast. It depends entirely on inputs you supply, and it should never be presented to a board as a projection.
- The model counts recovered labour value only. It does not attempt to value faster cycle time, fewer errors, better customer experience, or reduced key-person risk, all of which can matter more.
- It assumes recovered hours are redeployed to work of comparable value. Where that is not true, the figure overstates the benefit and should be discounted explicitly.
- It applies a flat annual run rate with no adoption ramp, so first-year value in a real rollout is typically lower than modelled.
- It excludes ongoing cost beyond year one, and excludes the risk that the process changes underneath the implementation.
- No calculator substitutes for a measured baseline. The most important number in the model is the one you are most likely to be guessing.
FAQ
Questions about this tool.
How is the number calculated?
People multiplied by hours saved per person per week, multiplied by loaded hourly cost, multiplied by fifty-two weeks, minus the first-year implementation cost. That is the whole model. It is deliberately simple so there is nowhere to hide an assumption.
Why is there no adoption curve or discount rate?
Because both are places to bury optimism. A flat model produces a figure you can argue about directly. If a case only works once a compounding factor is applied to an unmeasured baseline, the case does not work.
What hours figure should I use?
One you would be comfortable defending after two weeks of measurement. If you have not measured, halve your instinct — estimates of one own repetitive work are reliably high, and this is the input the entire result hinges on.
What counts as implementation cost?
Software, setup, services, integration work, data cleanup, training, and the internal time spent managing the change. The licence fee is usually the smallest of those and the only one people remember to include.
What if the result is negative?
That is a useful answer, delivered cheaply. Reduce the scope to the single highest-friction step, choose a workflow with a clearer completion event, or accept that this one is not the place to start. Do not adjust inputs until the model agrees with you.
Can I use this for a board paper?
Use it to screen a case, not to present one. For anything with real money attached, replace the estimated hours with two weeks of measurement and state your assumptions explicitly so they can be challenged.
Start with ARIA
Ask ARIA to act on the result.
A score is a starting point. Describe the outcome you want and ARIA works out the capabilities, systems, and data needed to get there.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Validate the assumptions with one bounded workflow.
Describe the workflow on the public ARIA path, or check whether the operating foundation underneath it is ready before you commit budget.