Automation ROI: Is It Worth It?

What is the basic formula for automation ROI?

The basic formula is annual hours saved multiplied by loaded labour cost, compared against build cost plus annual running cost. Everything else in this guide is honesty adjustments to that arithmetic.

Start with the labour side, and use the loaded cost, not the salary. An employee's real hourly cost to your business includes superannuation at 12 percent, annual and sick leave, workers compensation, payroll overheads, and the equipment and space they use. A quick, defensible method:

1. Take the salary and add roughly 25 to 30 percent for on-costs. A $70,000 salary is around $88,000 to $91,000 of real cost.
2. Divide by productive hours, not contracted hours. After leave, public holidays, and normal non-productive time, a full-timer delivers roughly 1,700 productive hours a year.
3. Result: that $70,000 admin role costs the business a touch over $50 per productive hour. A $100,000 role lands around $75. The owner's time is worth far more than either, which matters when the process being automated runs through you.

Then cost the process: hours per week it consumes, times weeks per year it actually runs, times the loaded rate of whoever does it. Be honest about the hours. Time a few real runs rather than guessing, because owners reliably underestimate fragmented tasks. Fifteen minutes six times a day is 7.5 hours a week that nobody would ever report as a job.

On the cost side, an automation build for an Australian SME typically runs $8,000 to $25,000 plus GST, and a sound budget adds 15 to 25 percent of the build cost per year for maintenance, monitoring, and platform fees. The full cost structure, including what moves a quote up or down, is covered in what AI automation costs in Australia. With both sides costed, the comparison is simple division. The next section runs it end to end.

A worked example at Australian wage levels

Here is the full calculation for a typical case: an admin employee on $70,000 spends five hours a week processing incoming orders by hand, copying details from emails into the job system and the accounting package.

Step 1: cost the process today. Loaded rate: $70,000 plus 28 percent on-costs is roughly $89,600, divided by 1,700 productive hours, call it $52 per hour. Five hours a week across 48 working weeks is 240 hours a year. Current cost: 240 x $52 = $12,480 per year, every year, before counting the errors that manual re-keying produces.

Step 2: cost the automation. A build of this shape, parsing orders and writing them into two systems with a review queue for exceptions, might quote at $12,000 plus GST. Add maintenance and platform fees at 20 percent of build cost: $2,400 a year.

Step 3: estimate the real saving. Automation will not remove 100 percent of the work. Somebody still handles exceptions and reviews flagged items. Assume 80 percent of the hours go: saving of $9,984 a year, ongoing cost of $2,400 a year, net $7,584 per year.

Step 4: payback. $12,000 divided by $7,584 is about 19 months. From year two onward, the business is roughly $7,600 a year better off, plus fewer keying errors, faster order turnaround, and a process that no longer depends on one person being at their desk.

Is that a good result? It is a solid, honest one. Not the "400 percent ROI" of a vendor slide, but real money on defensible assumptions. As a rule of thumb, a process consuming four to six staff hours a week can usually justify a build at the lower end of the range, with payback of 12 to 24 months. Under two hours a week, the arithmetic gets hard to defend unless errors or delays carry costs beyond the hours, the way missed quotes do in quote follow-up, where the return is recovered revenue rather than saved time.

The hidden costs the simple formula misses

The simple formula flatters automation, so before committing, adjust for the costs that do not appear in the quote. Five recur constantly.

• The last 20 percent of cases. Automating the routine 80 percent of a process is straightforward. The remaining exceptions, the weird orders, the customer who emails photos of handwritten notes, cost disproportionately more to handle. The right answer is usually to route exceptions to a human review queue rather than pay to automate them, but that means the saving is never 100 percent, and you should never model it as such.
• Maintenance is not optional. Connected apps change their interfaces, credentials expire, suppliers alter their invoice templates. A flow that ran perfectly for eight months can stop silently. Budget 15 to 25 percent of the build cost per year, and make sure someone is actually watching the error alerts. An unmaintained automation is a slow-motion write-off of the build cost.
• The review queue is labour too. If a person spends 45 minutes a day checking flagged items, cost those hours honestly against the saving. They are usually well spent, but they are not zero.
• Platform and usage fees. The automation platform, any AI usage costs, and connector subscriptions run monthly forever. Modest individually, they belong in the annual running cost.
• Change management. Staff need to learn the new process and trust it. For the first month or two, many teams quietly run the old manual method in parallel "just in case", which means the saving arrives later than the go-live date. Plan for it rather than being disappointed by it.

None of these kill a good project. A process worth $12,000 a year absorbs them and still pays back. What they kill is marginal projects, the ones that only looked viable because the model assumed 100 percent savings, zero maintenance, and instant adoption. If a project only works on those assumptions, it does not work.

When should you NOT automate a process?

Some processes should not be automated at any price, and recognising them saves more money than any clever build. Five clear cases:

1. The process is still changing. If you have altered how the work runs twice in the last six months, automation freezes a moving target and you pay to rebuild. Stabilise first, automate second.
2. The volume is too low. A task done monthly, however annoying, rarely repays a five-figure build. The arithmetic from the worked example needs frequency. Below roughly two hours a week of labour, look for a cheaper fix: a template, a checklist, a form.
3. The process should be deleted, not automated. A surprising share of SME processes exist to patch a decision nobody remembers making, like a report nobody reads or an approval step for approvals' sake. Automating waste just produces faster waste. Always ask "should this exist?" before "can this be automated?".
4. The variation is genuinely human. If every instance needs judgment, relationships, or negotiation, such as high-value quotes or sensitive customer conversations, automation belongs at the edges (reminders, data prep, logging) rather than in the middle of the interaction.
5. The data underneath is not ready. Automation built on duplicated, inconsistent records executes the mess faster and with more confidence. If your systems disagree about basic facts, that is the first project, not the automation.

There is also a portfolio version of this mistake: automating five processes at once. Every build competes for the same attention during testing and adoption, and five half-adopted automations return less than one that demonstrably works. Prove one, bank the saving, then use the evidence to justify the next. Boring, sequenced, and it works.

How to run the numbers on your own processes

Run the numbers in a fixed order, and let the arithmetic make the decision before any vendor does.

1. List candidate processes. Ask each staff member for the most repetitive thing they do weekly. Ask yourself what work reliably interrupts you. Ten minutes of asking usually produces a better list than any brainstorm.
2. Measure, do not estimate. For the top three candidates, time real runs for a week or two. Count frequency, hours, and how often the process goes wrong. This number is the foundation of everything else, and guessed foundations produce guessed ROI.
3. Apply the formula. Annual hours x loaded rate, versus likely build cost plus 20 percent a year. Model the saving at 70 to 80 percent of hours, never 100. If payback comes out beyond two years, park it.
4. Screen for the disqualifiers. Stable? Frequent? Worth existing? Data underneath it trustworthy? Any no sends the process back to the fix-first pile.
5. Start with one. Pick the process with the best combination of payback and stability, automate it, and measure the actual result against your model for three months. The comparison teaches you more about your business than the build does, and it makes the case for the next project with evidence instead of enthusiasm.

If you would rather have the measuring and screening done for you, that is the first half of what the Business Readiness Audit does: $1,990 inc GST, fixed scope over about two weeks, with written findings that rank your processes by exactly this arithmetic, fully credited toward any engagement within 90 days. Builds that follow typically run $8,000 to $25,000 plus GST through our Business Process Automation work. Either way, do the arithmetic first. Automation bought on numbers pays back. Automation bought on excitement becomes a subscription you forget to cancel.

FAQ

Questions owners ask