How Do You Estimate What an Automation Will Actually Save?

How do you estimate what an automation will actually save?

Time the manual task honestly, multiply by real frequency, then subtract build time, run cost, and the maintenance the automation creates. Most estimates skip the last three. What is left after subtracting them is the real number, and it is usually smaller and slower to arrive than anyone expects.

I get asked for this number before almost every automation project. A founder has a process that feels wasteful, someone has told them Zapier or Make can fix it, and they want to know whether it is worth the money before they commit.

The honest answer is that you can estimate it well, but only if you are willing to count the costs that automation advocates tend to leave out. Here is how I do it.

Why do automation savings estimates come out wrong?

Three reasons, and they stack. People guess at how long the manual task takes instead of timing it. They assume the automation runs perfectly from day one. And they count the build as a one-time cost when it is really a small upfront cost plus an ongoing one that never fully goes away.

The guessing problem is the biggest. Ask anyone how long it takes them to move a lead from a form into a CRM and tag it correctly, and you will get an answer that is either wildly high or wildly low. High because they are remembering the worst instance. Low because they are picturing the happy path and forgetting the three times a week the data is malformed.

The perfect-run assumption is the sneakiest. An automation that works on a clean test record behaves differently against six months of real data. I have written about what breaks first when an automation scales, and the pattern is consistent. Volume does not break the logic. Edge cases in the data break the logic, and volume just makes you meet them sooner.

What should you measure before you build anything?

Four things. How long one run of the manual task takes, measured with a timer and not from memory. How many times it happens in a month. Who does it, and what their hour is worth to the business. And how often the manual version goes wrong, because errors have a cost too.

Measure the first one across at least ten real instances, spread over a normal week. Not a demonstration. Ask the person who actually does the work to note the start and stop time while they do it as usual. You will almost always find the task is faster than they claimed and more frequent than they realised.

The frequency number needs the same discipline. Pull it from the system of record rather than asking. If it is leads, count the rows. If it is invoices, count the invoices. If nobody can count it, that itself is a finding, and it usually means the process is less standardised than the person describing it believes.

The value of the hour is where people get squeamish. You are not valuing the person. You are valuing what else that hour could produce. A founder's hour spent copying rows between Airtable and HubSpot has a different opportunity cost than an operations coordinator's, and the automation case looks very different depending on whose hour you are buying back.

How do you turn a time saving into a number you can defend?

Multiply measured minutes per run by measured runs per month, convert to hours, and multiply by the loaded hourly value of whoever does it. Then apply a haircut, because you will not eliminate the task completely. I use two thirds as a starting assumption for a well-built automation.

The haircut is the part people argue with, so let me defend it. Automations rarely remove a process. They remove the boring middle of it. Someone still checks that the run happened. Someone still handles the records the automation flagged as uncertain. Someone still fields the occasional question about why a record looks odd.

Two thirds is not a law of nature. It is a starting assumption I have landed on after six years and more than seventy projects, and I adjust it up when the process is genuinely mechanical and down when it involves judgement. If the process requires a human to decide something subjective, you are not automating it, you are assisting it, and the haircut should be closer to half.

What does the automation itself cost to run?

Platform fees, and they are metered in units that do not map neatly to your process. Zapier's pricing page defines a task as being counted "whenever Zapier successfully completes a unit of work for you", with the free plan including 100 tasks a month. One business event can consume several tasks.

Make counts differently again. Make's help documentation defines an operation as a single module run to process data or check for new data, with a module's operation count depending on the number of bundles it processes. Trigger modules run once regardless of how many bundles they return, and router modules and error handlers do not count as operations. Make has also introduced credits as a billing unit, where most actions consume one credit and some advanced features using Make's AI Provider consume more.

I am spelling this out because the mismatch is where budgets die. You think in business events. The platform bills in steps. A single new lead that gets looked up, enriched, routed, written to HubSpot, and posted to Slack is one event to you and several billable units to the tool. Model the steps, not the events, and check the vendor's current pricing page yourself before you commit, because these units and limits change. The same warning applies to n8n, Airtable automations, and anything else in the stack: read the vendor's own docs rather than a comparison blog.

If the step count starts looking ugly, that is a signal rather than a disaster. It usually means the workflow wants to be moved from a visual builder into code, where the same logic runs as one job instead of nine billable steps. I build a lot of those with Claude Code now, which changes the build cost side of the estimate more than the run cost side.

How do you account for the work the automation creates?

Add three ongoing costs: monitoring, so somebody notices when it fails, repair, for the hours spent fixing it when an API changes, and documentation, so the next person can understand it. Budget these as a monthly figure from the start rather than discovering them in month four.

Monitoring is the one people skip and regret. An automation nobody is watching is not saving you time, it is deferring a problem. I have written before about the cost of an automation nobody owns, and the short version is that the cost is not zero, it is just invisible until the day it is enormous.

For repair, I plan on a couple of hours a month for anything that touches three or more third-party tools. Not because something breaks monthly, but because when it does break it rarely takes fifteen minutes. Connections expire. Field names change. A vendor deprecates an endpoint. The work is lumpy, so budget it as an average.

Documentation is cheap if you write it while building and expensive if you write it later. One page saying what this does, what it touches, how to turn it off, and who to call is enough. If you cannot write that page, the automation is more complicated than it should be. Keep it wherever your team already looks, whether that is Notion, a Google Doc, or a README next to the code. From Bengaluru I have watched plenty of good automations die because the only documentation lived in one person's head.

What does a real estimate look like in practice?

Like a smaller number than the pitch, arriving later than promised, but compounding. The automations I built for Ajust on Airtable and WhaleSync have contributed to more than 25,000 cases delivered, over 400,000 people helped, and more than 50,000 hours saved. Those numbers took time to accumulate.

What that project taught me is that the payoff curve matters more than the payoff. An automation that saves a small amount per run, on a process that runs constantly, beats an automation that saves a large amount on something that happens twice a month. The second one is more satisfying to build and worth far less.

For Kismet Health I built HubSpot automations running through Zapier, and the value there was less about hours and more about consistency. Records landed in the same shape every time. That kind of benefit does not show up in an hours-saved calculation at all, which is why I write it down separately rather than trying to force it into the same number.

My pricing is fixed fee, and most of my projects land between one thousand and ten thousand dollars. I quote that way partly because it forces this estimate to happen properly. If I cannot see the saving clearly enough to price the work against it, neither of us should be starting.

When should the estimate tell you not to build?

When the payback is longer than the process is likely to survive. If a workflow will change in three months because the product is changing, or the tool is being replaced, or the team is restructuring, an automation with a six month payback is a loss dressed as an investment.

The other stop signal is a process nobody agrees on. If two people describe the steps differently, you do not have a process, you have a habit. Automating a habit hardens it, and you end up paying to make a bad workflow permanent and harder to change. Fix the process on paper first, run it manually for a month, then automate what survives.

There is a third case that comes up more than I expected, which is the process that is genuinely worth automating but not by you, not now. I keep a short list of the cases where I tell people not to automate, and the most common entry on it is simply that something more valuable is being ignored while everyone debates the automation.

What should you do next?

Pick the one process you are most tempted to automate. Time ten real runs this week. Pull the true monthly frequency from your system of record. Sketch the step count against your platform's billing unit. Then compare that to the build cost and decide with numbers instead of enthusiasm.

If the number comes out marginal, that is useful. A marginal automation is the one to skip, because marginal on paper means negative once real maintenance arrives. The clear wins announce themselves. They are the processes that run daily, follow the same shape every time, and make someone sigh when they open the tab.

If you want help running that estimate, or you want someone to tell you honestly that the automation you are excited about is not worth building, reach out. I would rather have that conversation before the invoice than after. Let's chat.