Is this task worth automating?
Enter what you can measure in an afternoon. The calculator returns hours back per week, annual value net of running cost, and payback in months - checked at a conservative automation rate as well as your own, because that assumption is where most business cases fail.
Working it out
Adjust the inputs on the left.
The same case at three automation rates
| Automation rate | Hours back / week | Net value / year | Payback |
|---|---|---|---|
| 50% - conservative | - | - | - |
| 60% - yours | - | - | - |
| 90% - optimistic | - | - | - |
Nothing you type is sent anywhere. The figures live in the URL so you can send this result to somebody, and nowhere else.
How this is calculated
Three numbers, then one division. Volume × handling time gives the work the task consumes today. Multiplying by the automation rate gives the share a system could plausibly complete without a person, and the rest escalates and still costs you.
Annual value is those returned hours at your loaded hourly cost, minus twelve months of running cost. Payback is the build cost divided by the monthly net. If the monthly net is zero or negative, there is no payback period at any horizon and the calculator says so rather than printing a large number.
Why it shows you 50% as well
The automation rate is the only input here that is a forecast rather than a measurement, and it is the one every over-optimistic business case gets wrong. A project that only works at the optimistic rate does not work. If the conservative row does not pay back inside a year, treat the case as unproven.
Why volume gets checked
Below roughly fifty instances a week you cannot evaluate the system - differences will not be distinguishable from noise, so you will never be able to say whether it is working. That is a floor on measurability, not on value, and it is why the calculator flags it separately from the money.
What it deliberately leaves out
The exception path. The share that does not automate has to go somewhere and somebody has to handle it, and if that queue is not designed the automation moves work rather than removing it. That cost is real and it is specific to your setup, so it belongs in the running cost figure rather than in an assumption here.
The reasoning behind all of this, including the four shapes worth automating and the four that look automatable and are not, is in Where the hours actually go: finding automatable work.
Next question
Where this answer leads
Also:How many test cases do we actually need?What should our llms.txt contain?
Let's talk
Want the ranked list rather than one task?
The business process automation engagement starts by measuring every candidate - including the ones whose answer is to stop doing them.