Automation Payback Calculator
Enter your own figures. Nothing here is pre-filled with an industry average, a salary benchmark or a typical maintenance rate, because those numbers would be invented and you would end up making a decision on them. Every value below comes from you; the page only does the arithmetic.
Currency is whatever you type. If you enter hourly costs in pounds, the money outputs are pounds.
The starting values are placeholders to show the shape of the output. They are not a recommendation, a benchmark, or a typical case — replace all seven with your own before reading anything into the result.
What it computes
Weekly frequency becomes a monthly figure using the calendar year divided into twelve equal months, so a task run every weekday lands slightly above four weeks’ worth rather than exactly four.
Gross saving is the time removed per run — minutes now minus minutes after — multiplied by runs per month and priced at the operator rate.
Net monthly saving subtracts maintenance, priced at the engineering rate, because the hours spent keeping an automation alive are real hours that otherwise went somewhere else.
Break-even divides the one-off build cost by the net monthly saving. It is measured from the day the automation goes live, not from the day work starts on it. If you want the calendar answer, add the build duration yourself.
First-year net is twelve months of net saving minus the build cost. A negative figure means the first year loses money even though later years may not, which is a legitimate thing to accept deliberately and a bad thing to discover afterwards.
The input people want to skip
Minutes after is the one that decides most cases, and it is the one most often left at zero.
Automation seldom removes a task completely. Somebody checks the output, processes the items the automation refused, restarts it after a failure, and answers questions about what it did last Tuesday. If nobody can name who does that and how long it takes, the estimate is not ready. Setting this field to zero does not make the supervision disappear; it just moves it out of the calculation and into somebody’s week.
Maintenance is the second candidate for wishful thinking. It is not a defect rate that decays as the code matures — it is the ongoing cost of every integration point continuing to work while the systems on either side of it change without consulting you.
What it deliberately does not model
Ramp-up, while the automation runs alongside the manual process and both are paid for. Failure cost, when an automated mistake is repeated a hundred times before anyone notices. The value of the observations a person made while doing the task by hand. Any benefit that is not time: consistency, auditability, latency, out-of-hours coverage, or no longer depending on one person who knows how.
That last omission matters most. Plenty of automation worth building fails this arithmetic outright, because the reason to build it was never hours saved. Use the calculator to test cases argued on hours. Do not use it to kill a case argued on something else.
Reading the result honestly
The output carries the precision of its worst input, which is usually the frequency estimate or the build effort. Self-reported durations for routine work are unreliable, and build estimates are famously optimistic — so the useful exercise is to run it three times: once with your figures, once with frequency and savings on the pessimistic side, once with build effort and maintenance on the pessimistic side.
If break-even stays comfortable across all three, the decision is easy. If it swings from months to never, the number you are least sure about is the one worth measuring properly before anyone writes code.