Calculating Workflow Automation ROI

Here’s the formula, upfront: ROI = ((hours saved per month × hourly cost of that time) − monthly automation cost) ÷ monthly automation cost, expressed as a percentage. Hours saved is how much time the automation actually removes from someone’s workload. Hourly cost of that time is what an hour of that person’s work is really worth to the business, not just their wage. Monthly automation cost is what the automation costs to build and maintain, averaged over its useful life. That’s the whole formula. Everything else in this post is about getting honest numbers to plug into it.

What Actually Counts as “Hours Saved”

The easy mistake is counting only the raw task time: “this used to take 20 minutes, now it takes zero.” The more honest number includes two things people usually leave out. First, context-switching cost: a 20-minute manual task interrupting someone’s focus doesn’t just cost 20 minutes, it costs the time to mentally return to whatever they were doing before, which is real but rarely tracked. Second, error-correction time: if the manual version produces mistakes occasionally that someone has to notice and fix later, that cleanup time belongs in the “before” baseline too, even though it doesn’t happen on every single instance of the task.

What’s Hard to Quantify (But Still Real)

Some of the real value from automation doesn’t fit cleanly into an hours-saved calculation, and pretending it does usually means either inflating the number dishonestly or ignoring real value entirely. A faster customer response time can mean a measurably different conversion rate, but attributing a specific dollar figure to “we responded in 2 minutes instead of 2 hours” requires data most businesses don’t track precisely. A lower error rate reduces downstream cost (a wrong invoice, a missed follow-up) that’s real but diffuse. And removing tedious, repetitive work from someone’s day has a genuine effect on morale and retention that’s completely real and completely resistant to being expressed as an hourly rate. Name these honestly as additional value rather than forcing them into the formula. The formula handles the quantifiable part, these are the qualitative part, and both matter.

A Worked Example

Here’s an illustrative scenario, not a real client’s numbers. Say someone on your team spends 6 hours a week on manual data entry, moving information from an inbound form into a CRM and a spreadsheet, by hand, with the usual mix of occasional typos needing correction later. That’s roughly 26 hours a month. If that person’s time is worth $35 an hour to the business once you account for salary, benefits, and overhead (not just their base wage), that’s $910 a month in time currently spent on this one task.

Say the automation to replace this costs $400 a month, averaged across the build cost spread over its useful life plus ongoing maintenance. Plugging into the formula: ($910 − $400) ÷ $400 = 1.275, or a 127.5% monthly ROI. The payback period (how long until the automation cost is recovered) is, in this case, less than a month, since the time saved in the first month alone already exceeds the cost. A more expensive or more complex automation might take several months to reach payback instead, which is still often a reasonable outcome depending on how long the workflow will keep running afterward.

Finding Your Own Numbers

Three practical steps before you plug anything into the formula. First, figure out your own real hourly cost of time. Don’t just divide salary by hours worked. Add a reasonable overhead factor for benefits, equipment, and management time, since the raw wage understates what an hour of someone’s time actually costs the business. Second, track the current time spent on the manual process for a real week or two before automating, rather than estimating from memory — people are reliably bad at estimating how long a task they do constantly actually takes, in both directions. Third, get an honest cost estimate for the automation itself before committing, including a realistic maintenance cost, not just the build price — an automation that breaks silently a few months in and nobody notices has a real cost too, it’s just deferred.

When ROI Doesn’t Clearly Favor Automating Yet

Not every process clears this bar, and it’s worth saying so directly. A process that happens rarely (once a quarter, say) rarely justifies a meaningful automation build no matter how annoying it is in the moment, because the hours saved per month work out to almost nothing. A process where the manual version is already genuinely fast and low-error might not have much room to improve. In both cases, the honest answer is to wait until volume or complexity grows enough to change the math, rather than automating something because it’s possible to automate, not because it’s worth it yet.

A Second Example, Where the Math Looks Different

The first example had a clean, fast payback because the time saved was substantial and the automation cost modest. It’s worth looking at a case where the numbers are less flattering, since an honest ROI framework has to handle both. Say a process happens 2 hours a week, with an hourly cost of $30: $240 a month in time. If the automation to replace it costs $300 a month to build and maintain, the ROI comes out negative: ($240 − $300) ÷ $300 = -0.2, or -20%. On paper, this automation doesn’t pay for itself at this volume.

That doesn’t necessarily mean don’t build it. It means the business case has to come from somewhere other than raw time savings. Maybe the 2 hours a week is specifically the part of someone’s job they hate most, and the retention value of removing it is worth more than $60 a month even though it’s not measurable the same way. Maybe the process is growing in volume and will justify itself in six months even though it doesn’t today. Or maybe, honestly, it’s not worth automating yet, and that’s a perfectly fine conclusion to reach from running the numbers rather than skipping them.

How Automation Cost Should Actually Be Averaged

The formula calls for “monthly automation cost,” but a one-time build fee isn’t naturally a monthly number, and getting this averaging right changes the ROI significantly. If a workflow costs $2,400 to build once, with no ongoing maintenance need, and you expect it to keep running usefully for two years, that’s $100 a month amortized over its useful life, a very different number than treating the full $2,400 as a single month’s cost, which would make nearly any automation look like a poor investment in month one.

If there’s also an ongoing maintenance cost (say $150 a month for monitoring and occasional fixes), that gets added to the amortized build cost, not treated separately, since both are real costs of keeping the automation running. Getting this averaging wrong in either direction (ignoring the build cost because “it’s already paid for,” or treating the full build cost as recurring) is the most common way this formula gets misapplied in practice.

Tracking ROI After Launch, Not Just Before

Most of this post is about estimating ROI before you build something, but the formula is just as useful afterward, and it’s worth actually revisiting it once a workflow has been running for a few months. The “hours saved” estimate going in is often a guess based on how the manual process used to work; after a few months of real data, you’ll often find the actual time saved is higher or lower than estimated, usually because the manual baseline either included more hidden friction than anyone realized, or because the automation itself needed more maintenance attention than expected. Revisiting the real numbers after launch, rather than assuming the pre-build estimate was correct and moving on, is what turns this from a one-time justification exercise into something that actually informs the next automation decision.

ROI Across Multiple Workflows, Not Just One

Everything above treats ROI as a single workflow’s calculation, but most businesses eventually automate more than one process, and it’s worth being aware of how the math compounds. A business that automates five separate workflows, each individually clearing a modest 40% monthly ROI, isn’t just getting five small wins. The cumulative hours saved across all five often frees up enough time that it changes what the team can actually take on, which is a second-order benefit the per-workflow formula doesn’t capture at all. This is part of why it’s worth tracking ROI per workflow but also periodically stepping back and asking what the combined effect across all your automations has actually been, since that combined picture is usually the more persuasive number if you need to justify continued investment to a partner or stakeholder.

When the Formula Undersells the Decision

There’s a specific case worth naming where the formula, taken literally, can lead to the wrong decision: a process that’s currently a bottleneck blocking other work, not just consuming hours. If a slow manual process is the reason a team can’t take on more client work, or the reason customers wait longer than competitors, the ROI isn’t just the hours saved directly. It’s whatever revenue or capacity was being capped by that bottleneck. This is genuinely hard to quantify precisely, which is exactly why it belongs in the “hard to quantify but still real” category rather than being forced into the hours-saved number, but it’s worth explicitly asking “is this process currently capping something bigger than itself” before concluding a marginal ROI number means a marginal decision.

Keep the Formula, Distrust Precision

One last honest note: this formula produces a specific-looking percentage, which can create a false sense of precision about numbers that are mostly estimates. Your hourly cost estimate, your hours-saved estimate, and your automation cost estimate are all approximations, even when the final ROI percentage looks exact to one decimal place. Use the formula to compare options and sanity-check decisions, not as a number precise enough to defend down to the dollar. A workflow with an estimated 150% ROI and one with an estimated 40% ROI are meaningfully different decisions; a workflow estimated at 52% versus 48% probably isn’t a meaningfully different decision at all, even though the formula will happily produce both numbers with equal-looking confidence.

Once you’ve run your own numbers, see our pricing page for what an actual build typically costs, or read Business Process Automation and how we scope a project for what the process looks like before you commit to anything.