How to Calculate Automation ROI Before You Start the Project

A friend who runs a business asked me something last week, roughly: "If I automate one of my processes, how do I know it'll actually pay for itself? I'm worried I'll just burn the budget and the system ends up unused."

Good question, and honestly it's the one I get most often from prospective clients too, just phrased differently each time. Instead of answering it one chat at a time, I figured I'd write down how I actually work through it whenever someone asks.

ROI itself is just comparing two numbers

The formula isn't complicated:

ROI (%) = (Total Benefit − Total Cost) ÷ Total Cost × 100%

What makes it hard isn't the formula, it's filling in those two numbers honestly. People tend to jump to "this will definitely pay off" without fully counting the cost side, or the benefit side ends up being a feeling like "it seems faster" instead of an actual number.

The cost side: don't just count what's visible

The most obvious cost is just the one: what it costs to build the system. Two others usually get missed:

• Running costs. Hosting, API costs if AI is involved, subscriptions for supporting tools. This runs every month, not just once.
• The team's adjustment cost. Time spent learning the new system, plus the temporary dip in productivity during the first few weeks. It's real, even though it rarely gets logged as a cost.

If you only count the build cost, the ROI on paper looks better than it actually is.

The benefit side: turn it into numbers, not "it seems faster"

This is the part that stays vague most often. Three things are the easiest to convert into Rupiah:

1. Time saved. Hours saved, times the number of people, times the cost per hour for each person (salary divided by working hours per month).
2. Fewer human errors. How often mistakes happen each month, and what it costs to fix them (time, complaints, or direct losses).
3. Extra capacity without hiring. If the automation lets the team handle more volume, that's equivalent to the cost of a hire you didn't have to make.

Other benefits like "customers are happier" or "the team is less stressed" are real, but I deliberately keep them separate, since they're hard to turn into a solid number. Fine to note as a bonus, but they shouldn't be the main reason in the ROI math.

Let's run the numbers on a project I actually worked on

So this isn't just theory, here's one real figure. In the automated document verification case study, which I cover in more depth in How I Cut Operating Costs From Tens of Millions to Hundreds of Thousands, the cost of four admin roles for one process was around Rp15–25 million (roughly US$900–1,500) a month. Once the automation went live, the system cost dropped to under Rp200 thousand (about US$12) a month, with one admin still running it and checking the results.

Monthly cost of the document verification process, before vs after(Rupiah)

• Before: four admin rolesRp15–25 million
• After: system (API) costUnder Rp200 thousand

That's a real figure, but to show how a payback period actually gets calculated, here's a simple illustrative example: say the system cost Rp15 million (about US$900) to build, a one-time cost, and it saves Rp5 million (about US$300) a month. The payback period is just division:

Rp15 million ÷ Rp5 million a month = 3 months

That means the first three months are "paying it back," and month four onward is pure savings. The shorter the payback period, the easier the decision gets, because the risk is smaller.

Be suspicious of the "automation ROI can hit 300%" figures floating around online

While researching this article, I deliberately went looking for outside benchmarks to compare against. What I found made me hesitant to use any of it: figures like "300% ROI," "payback in 4 months," and similar claims show up across a lot of blogs, but trace them back to their original source and the methodology is usually unclear, or they're attributed to research institutions that never actually said that.

ROI varies wildly depending on which process gets automated, so a generic number from the internet will never actually fit your specific business. What matters more is having your own cost and benefit numbers for your own business, not borrowing someone else's.

What people usually miss when calculating ROI

• Being too optimistic about time saved. It's safer to use a conservative number than the best-case scenario.
• Only calculating annual ROI, forgetting the payback period. A 50% ROI over a year sounds good, but a 10-month payback period is a very different story from a 2-month one.
• Not counting the cost of doing nothing. If the process stays manual, the cost of its errors keeps running every month. That's a cost too, even if it never comes out of the project budget.

On how to decide which process is even worth automating in the first place, I go into more depth in Not Everything Needs AI. According to BCG's "Where's the Value in AI?" report, companies that actually get value from AI put the largest share of their resources, 70%, into people and process, not algorithms or tools. So when you're counting costs, remember that process and people are part of the investment too, not just the price of the tools.

Back to the original question

So if someone asks me that again, here's my answer now: calculate the upfront cost, the running cost, and the team's adjustment cost first. Then turn the benefits into numbers, time saved, errors reduced, extra capacity, using conservative figures. Divide the upfront cost by the monthly savings to get the payback period. If the numbers make sense for your business, start. If they don't, that's a valid answer too, it just means it's not the right time yet, not that automation itself is a bad idea.

If you're at that stage and want help running the numbers for a specific process in your business, tell me about it, and we'll work through it together.