Is This Automation Worth Building? An ROI Framework

Most automations that get built quietly cost more than they save. Building one feels productive, so people skip the math and start writing code. But the check is faster than the code. Before you build, you can estimate in an afternoon whether an automation pays back, and most of the ones people propose do not.

#The two numbers that decide it

Start with time saved per run times runs per year. A task that takes 10 minutes and happens twice a week saves about 17 hours a year. A task that takes 2 hours but happens once a quarter saves 8 hours a year. The dramatic-sounding one saves less.

Then estimate the real build cost, and be honest about it. It is the hours to write the thing plus the hours to keep it alive when an input format changes or an API deprecates a field. A rough rule that has held up for me: maintenance runs 20 to 50 percent of the original build cost every year, forever. An automation that took 3 days to build costs you a day or two a year just to keep running.

#Frequency times stakes

Time saved is only half the picture. The other half is what happens when the automation is wrong. Sort the task on two axes: how often it runs, and how expensive a wrong output is.

High frequency, low stakes is the sweet spot. Sorting inbound leads, renaming files, posting a daily digest. These run constantly and a mistake is cheap to catch and undo, so the savings compound. High stakes, low frequency is the trap. Sending a contract, issuing a refund, deleting production data. It runs rarely, so you save little, and a wrong call is expensive, so you end up building guardrails that cost more than the task ever did. Automate the boring high-frequency work. Leave the rare, expensive decisions to a human who is paying attention.

#The costs the math misses

Two things wreck the payback and never show up in the first estimate. The first is the flaky tail. An automation that handles 90 percent of inputs sounds great until the other 10 percent land on a human, who now has to notice the failure, figure out what the bot did, and finish by hand. That is sometimes slower than doing all of it manually, because the human lost the context.

The second is trust erosion. The first time an automation silently does the wrong thing, people stop trusting it and start double-checking every run. Now you are paying for the automation and the manual review on top of it. An automation nobody trusts costs money and gives nothing back.

#The bottom line

Most automation proposals die at the napkin math, and that is a win. The five minutes you spend estimating is the cheapest part of the whole project, and it saves you from the expensive part: maintaining a thing that never paid for itself. Build the high-frequency, low-stakes, easy-to-verify ones. Be suspicious of the impressive-sounding automation that runs twice a year.