AI Automation ROI: The Payback Math Before You Sign

You are about to sign off on a build, and the price looks reasonable, but nobody has actually shown you the maths on whether it pays back. That gap is where money disappears. The good news is the calculation fits on a napkin. Annual saving equals hours saved per run, times a loaded hourly rate, times runs per year. Net benefit is that saving minus the build and run cost. Below is how to run it on your own numbers before you commit a cent.

If a builder will not do this sum with you, in the open, before you sign, that tells you most of what you need to know. The number should never come first. The payback should.

The Bottom Line

• The whole calculation is one line: hours saved per run, times your loaded hourly rate, times runs per year, minus build and run cost.
• Use a loaded rate, salary plus super plus on-costs, never bare salary, or you will undercount the return badly.
• Find your inputs from how the work runs now: time one real run, count how often it happens, add up the true cost of the hour.
• If the maths only works when you assume everything goes perfectly, treat that as a warning and walk.

What Is The AI Automation Payback Formula?

The formula is two lines, and it should sit at the top of any proposal you take seriously. Annual saving equals hours saved per run, times your loaded hourly rate, times runs per year. Then net benefit equals that annual saving, minus the build cost plus the annual run cost. That is the whole thing.

Most quotes skip it entirely, which is how a clever demo turns into five figures with nothing to point at. The formula forces three honest inputs onto the table: how much time the work actually eats, what that time truly costs, and how often it happens. Get those three right and the answer falls out. Get them wrong and no amount of clever wiring saves you.

A quick note on the run cost. Every build carries a small ongoing figure, tool subscriptions plus AI usage, so you subtract a year of that, not just the upfront price. We cover what those numbers usually look like in what AI automation costs in Australia. The point here is the sum, not the sticker.

How Do I Find My Real Inputs?

Your three inputs come straight from how the work runs today, not from a guess. Time one real run with a stopwatch, count how often it happens across a year, and work out what the hour genuinely costs once you load it. Rough is fine. Written down beats precise-but-imagined every time.

Start with hours saved per run. Watch the task once, end to end, and time it honestly, including the bits people forget: the re-checking, the chasing, the copy-paste between two systems. If a job takes twenty minutes but happens because someone first spent ten minutes hunting for the data, your real figure is thirty.

Next, runs per year. A daily task is roughly 250 working days. A task that fires every time a lead comes in might run 40 times a week. Count the trigger, not the calendar. This number is usually where people undercount, because the small jobs that run constantly add up faster than the big ones that run rarely.

Last, the loaded hourly rate. This is the one almost everyone gets wrong. Do not use bare salary. Add super, then the tools and software that person needs, then the genuine on-costs of employing them. For a sense of the base, the Australian Bureau of Statistics puts full-time adult average weekly earnings at about $2,051 as of November 2025, which is roughly $54 an hour before you add a cent of super or overhead. The loaded figure for a real employee usually sits well above the headline. If the task lands on the owner, the rate is higher still, because owner hours are the scarcest in the building.

Choosing what to point the sum at matters as much as the sum itself. What to automate first covers picking the task that actually pays.

A Worked Example (Illustrative, Not A Client Result)

Here is the formula running on round numbers. This is illustrative, not a client result. Swap in your own and the answer changes, but the shape holds. Picture one repeating job that eats five hours a week, done by someone with a loaded cost of $70 an hour, automated for a few thousand up front plus a small monthly run cost.

Run the sum. Five hours a week is 260 hours a year. At $70 an hour loaded, that is $18,200 of time going into a single repeating job. Say the build costs $6,000 and runs for $150 a month, so $1,800 a year. Net benefit in year one is $18,200 minus $6,000 minus $1,800, which is $10,400. In year two, with no build cost to repay, it is $18,200 minus $1,800, which is $16,400.

So the build clears its own upfront cost in roughly four months, then keeps paying every year after. That is the test you are looking for: payback inside a year on recovered hours alone, with everything past that as profit. If your numbers land there, the case is strong before you have counted a single second-order win.

Two cautions on the example. Use your real loaded rate, because $70 was picked for the maths, not for you. And use your real runs per year, because that one number swings the answer more than any other. Plug in twice the runs and the build pays back in two months. Plug in half and it might not pay back at all. That sensitivity is exactly why you measure, rather than vibe it.

What Wins Does The Formula Miss?

The formula counts recovered hours, and that is the floor, not the ceiling. The bigger wins almost never show up in the sum, because they are about outcomes, not minutes. Faster replies that win deals you would have lost. Fewer dropped balls. Owner hours handed back. The day you take two weeks off and nothing breaks.

Think about lead response. If quotes currently go out a day late and a build sends them in minutes, the formula only captures the admin time saved. It misses the deals that close because you got there first. Same with follow-up: a job that never falls through the cracks is revenue the spreadsheet never knew it was losing. We break that revenue-versus-hours split down in do AI agents deliver real ROI.

Then there is the win no formula touches: away-from-desk autonomy. The real prize is not shaving an hour off a task. It is being able to step out for a fortnight and have the business keep running without you holding it up. That does not fit in a cell, but it is the number most owners are actually chasing once they are honest about it.

Here is the discipline that keeps you sane: make the build pay for itself on recovered hours alone, then treat every second-order win as upside. If the hours-only maths already clears, the rest is gravy. If it only works once you count the soft wins, you are leaning on the numbers you cannot prove yet.

When Is The Maths A Warning?

The clearest red flag is a build that only pays back if you assume everything goes perfectly. Real automations hit edge cases, settle slowly, and need a few weeks before the team trusts them. If the case collapses the moment you add a sensible margin for that, the case was never really there.

Watch for these signals. The maths only works at the most optimistic runs-per-year, not a realistic one. The saving leans entirely on second-order wins you have not measured, with thin recovered hours underneath. The task runs rarely or changes every time, so the formula is being stretched to fit something that genuinely needs a person. Any one of those, slow down. All three, walk.

The other warning lives in the run cost, not the build. If an ongoing fee rivals the build price every single month, the payback never compounds, because you are repaying the saving in perpetuity. A healthy build pays once and runs cheap for years. Once you have run it live, how to measure ROI after it goes live shows how to check the real number against the one you signed on.

Run the sum on conservative inputs. If it still clears inside a year on hours alone, sign. If it needs perfect assumptions to work on paper, it will not work in practice. The maths is doing its job either way.

Frequently Asked Questions

What Inputs Do I Need To Calculate Automation ROI?

Three. Hours saved per run, which you get by timing one real run honestly. Runs per year, counted off the actual trigger, not the calendar. And the loaded hourly rate of whoever does the work now, meaning salary plus super plus tools plus on-costs. Rough numbers are fine, as long as you write them down and use yours.

Why Use A Loaded Hourly Rate Instead Of Salary?

Because bare salary undercounts the cost of an hour badly. A person costs their employer far more than their wage once you add super, the tools they need, and the real on-costs of employing them. Using salary alone makes every build look like worse value than it is, and quietly talks you out of automations that would clearly pay back.

How Fast Should An AI Automation Pay Back?

A build aimed at a real, frequent task usually clears its upfront cost inside a year on recovered hours alone, often inside a quarter. Anything past that is profit, plus the second-order wins the formula misses. If the payback stretches well beyond a year even on optimistic inputs, the target is probably wrong, not the price.

What If The Numbers Only Work With Perfect Assumptions?

Walk, or at least slow down. Real builds hit edge cases and settle over weeks, so any case that collapses the moment you add a realistic margin was never solid. Run the sum on conservative inputs instead. If it still clears inside a year on hours alone, you have a genuine return rather than a hopeful one.

If you want a straight read on whether a build actually pays back in your business, we will run this sum with you on your real numbers, in the open, before anyone builds a thing. No homework, no surprise bill, no lock-in. Get In Touch.