When automating a task pays off
Automating a task pays off when the time it gives back in a year beats the cost of building it plus the cost of keeping it alive. Quick math: times per week × minutes each × 52 ÷ 60 = hours per year; multiply that by what the hour is worth and compare it to the build cost, then add 20% to 30% of that build cost every year for maintenance. If it doesn't pay for itself inside twelve months, don't build it yet.
Four numbers, ten minutes, no spreadsheet
Pick one concrete task. Not "admin," not "following up with customers": one thing that starts and ends. Copying approved estimates into the invoicing sheet. Sending tomorrow's appointment reminder. Moving web form entries to wherever you actually look at them. If you can't describe it in one sentence with a verb in it, it isn't a task yet, it's a department, and departments don't get automated.
Now the four numbers. How many times a week it happens: count last week, not the week you picture in your head. How many minutes each time: count the ramp-up and the wrap-up, not just the typing, because switching windows and remembering where you left off is time too. What that hour is worth: if an employee does it, their loaded hourly cost, not salary divided by contract hours; if you do it, your billable rate. What it costs to build and to keep running: this is where almost everyone gets it wrong.
Times per week, times minutes, times 52, divided by 60: that's hours per year. Twelve times a week at five minutes is 52 hours a year. At forty dollars an hour, that's north of two thousand dollars sitting there doing nothing. That number is what everything else gets measured against.
Maintenance is half the math and nobody counts it
An automation isn't a finished build, it's plumbing. The app it reads from changes its export format. Your email provider starts filing the messages under Promotions. Somebody adds a field to the form and the flow quietly starts writing data into the wrong column. None of that is anyone's fault: it's what happens to anything that depends on systems you don't control.
Rule of thumb: budget 20% to 30% of the build cost, every year, just to keep it alive. If it costs a thousand dollars to build, count on two or three hundred a year in checks, fixes and adjustments. Add the subscription for whatever runs it, which is almost always priced per seat or per number of runs, so it grows as your business grows. Then add the line people forget most: your own time spent confirming it still works. An automation nobody watches is an automation that already broke and hasn't told you yet.
The most expensive hidden cost is silent failure. A manual task you skip is obvious the same day. An automated flow that stopped sending the reminder shows up three weeks later, when someone asks why nobody is confirming appointments anymore. That's why anything touching money or customers needs an alert when it fails, and building that alert is part of the build cost, not an extra.
The threshold: one hour a week, twelve months to pay back
Here's the line I use: if the task doesn't eat at least an hour a week, don't automate it yet. An hour a week is roughly 50 hours a year, and that's the floor where the savings survive maintenance. Below that, one bad surprise, an update that breaks the flow and two hours to fix it, wipes out the entire year of gain.
The second filter is payback time. Divide the full first-year cost, build plus maintenance, by the annual dollar savings. If that comes out past twelve months, the answer is not yet. It isn't wrong forever: it's that if the task hasn't settled into a stable shape, you'll pay twice, once to build and once to rebuild. When volume climbs, the same math will say yes, and that's when you do it.
There's one real exception. If the task is small in time but expensive when it goes wrong, the kind where a miss costs you a customer, a fine, or an invoice nobody ever sent, run the math on the cost of the error instead of the minutes. There you're not buying time, you're buying the mistake not happening. Everything else goes through the math above, no exceptions.
Delete and simplify first: both cost nothing
The cheapest option is always for the task to stop existing. Before the math, ask why it's there at all. Plenty of weekly reports get opened by one person out of habit and change zero decisions. Plenty of double-entry steps exist because two years ago somebody picked two tools that didn't talk to each other, and one of them isn't even in use anymore. Deleting a task costs nothing, happens today, and has no maintenance.
If it can't be deleted, the next step down is simplifying it. Sometimes that's three fewer fields on the form, or a saved template, or doing once a week what currently happens five scattered times. Cutting twelve weekly runs down to two is often worth more than automating all twelve, and it makes the automation cheaper if you build it later. And neither one, deleting or simplifying, is solved by a tool: it's solved by someone deciding what stops existing.
Only once a task survives both questions and clears the threshold is it worth building. If you're starting out and don't know which one to pick first, the order in where a small team should start automating helps. And if the thing eating your week is chasing leads and estimates scattered across notebooks and texts, read when a business actually needs a CRM first, because automating on top of a mess only makes the mess move faster.
Frequent questions
How do I value my hour if I'm the owner and don't pay myself a salary?
Use your billable rate, or what it would cost to hire someone to do that exact task, whichever is higher. Don't use zero just because no check gets cut: while you're entering data you're not selling or estimating, and that's the real cost. For a local service owner, somewhere between thirty and eighty dollars an hour is usually realistic depending on the trade.
Is it worth automating something I only do once a month?
Almost never on time savings alone. Twelve times a year at thirty minutes is six hours, and any serious build plus its upkeep eats that in year one. The exception is when the monthly task is critical and you keep forgetting it, or a mistake there costs real money; in that case automate only the reminder, which is cheap, and keep doing the task by hand.
What does it cost to maintain an automation each year?
Count 20% to 30% of the build cost per year, plus the subscription for whatever runs it, which is usually billed per seat or per number of runs and grows with your volume. Then add your own time checking that it still works. If an automation has no alert to tell you when it breaks, its real cost is higher, because you'll pay it in errors you find out about too late.