How Do You Estimate the Time an Automation Will Save Before You Build It?

How do you estimate the time an automation will save before you build it?

Count how often the task happens, time how long it takes a person today, and multiply. Then subtract the time the automation will still need from humans, such as reviewing exceptions and fixing failures, plus the cost to build and maintain it. What remains is the honest estimate, and it is usually smaller than the first guess.

Every automation pitch includes a time saved number, and most of them are invented on the spot. "This will save the team ten hours a week" sounds great, but nobody checked how often the task happens or how long it really takes. When the number is wrong, the project either disappoints or never gets the priority it deserves.

This is the method I use to estimate time saved before building anything, the traps that inflate the number, and how to turn the estimate into a decision.

Why should you estimate time saved before building?

Because the estimate decides what to build first and whether to build at all. Teams usually have more automation ideas than time. A rough but honest estimate of hours saved, set against build and maintenance cost, ranks those ideas. Without it, the loudest request wins, not the most valuable one.

The estimate also sets expectations. If you tell a sales leader an automation will save their team ten hours a week, they will look for those hours. If the real number is three, the project looks like a failure even though it works perfectly. A careful estimate protects the project's reputation.

And it creates a baseline for later. Once the automation is live, you can compare actual results with the estimate and learn how good your estimates are. I covered that after the fact measurement in how to measure whether an automation actually saves time. Estimating first makes that comparison possible.

What inputs do you need for a good estimate?

You need four inputs: how often the task happens, how long one instance takes today, what share of instances the automation can handle without a person, and how much human time the automated version still needs. Each input should come from observation or data, not from memory.

Frequency is usually easy to find. Count form submissions, new deals, support tickets, or whatever triggers the task over the last few months. CRM reports, form tools, and spreadsheets typically have this data. Use a real count rather than a guess, because people are notoriously bad at estimating how often routine tasks happen.

Duration is harder. Ask the person who does the task to time the next ten instances, start to finish, including switching between tools. Do not ask them to estimate. Estimates tend to leave out the small steps, like copying a value from one tab to another or checking a second system, which is exactly the work automation removes.

How do you account for exceptions and edge cases?

Estimate what share of instances the automation can fully handle and what share will still need a person. Then add the human time for those exceptions back into the calculation. An automation that handles most cases but sends a meaningful share to manual review saves far less than one that handles nearly everything.

Exceptions come from messy inputs: incomplete forms, unusual requests, duplicate records, and data the automation was not designed for. Look at a sample of recent instances and sort them into "routine" and "needs judgment." That ratio is more reliable than any assumption.

Review time matters too. Many automations should have a person check their output, especially ones that touch customers or revenue. If someone spends a minute reviewing each result, that minute stays in the calculation. Removing a ten minute task and adding a one minute review is still a strong win, but it is not ten minutes saved.

What costs should you subtract from the time saved?

Subtract the build time, the ongoing maintenance time, and the time spent on failures. Build time is a one off cost. Maintenance and failure handling are ongoing, and they are the costs most estimates forget. An automation that saves two hours a week but needs an hour of upkeep is barely worth it.

Maintenance includes updating the automation when tools change, fields get renamed, or business rules shift. It also includes monitoring: someone has to notice when it breaks. For a simple automation, this might be a few minutes a month. For a complex one touching several systems, it can be hours.

Failure handling is the hidden cost. When an automation fails, someone has to investigate, fix it, and clean up the data it affected. A fragile automation that fails often can cost more time than it saves. That is one reason I sometimes recommend not automating at all, which I explained in when not to automate a workflow.

How do you turn the estimate into a decision?

Compare net hours saved per month against the build cost and calculate how long it takes to pay back. If the payback period is short and the task is stable, build it. If the payback is long or the process keeps changing, wait or simplify the process first. Rank competing ideas by payback.

The formula is simple. Monthly hours saved equals frequency times duration times the automatable share, minus review time, minus exception handling, minus maintenance. Payback in months equals build hours divided by monthly hours saved. Put each candidate automation in a row of a spreadsheet and sort by payback.

Time is not the only value. Some automations matter more for speed or accuracy than for hours saved. Routing a lead in seconds instead of hours may not save much staff time, but it can win deals. Note those benefits in a separate column so they are not lost, and weigh them alongside the hours. I described how I weigh both in how I decide which automation to build first for a client.

What does a large time saved number look like in practice?

Large numbers come from high frequency tasks that touch many people over a long period. Ajust, where I run automations in production on Airtable and WhaleSync, counts 25,000+ cases delivered, 400,000+ people helped, and 50,000+ hours saved. Numbers like that come from steady volume over time, not from one dramatic workflow.

The lesson from projects like that is about compounding. A task that takes a few minutes, repeated thousands of times, adds up to an enormous amount of time. That is why frequency is the most important input in the estimate. A rare task, even a painful one, rarely produces a big total.

It is also why accuracy matters at scale. When an automation runs thousands of times, a small error rate becomes a lot of cleanup. At the scale of 400,000+ people helped, every exception path and every review step has to be designed carefully. At high volume, the exception handling is the product.

What mistakes inflate time saved estimates?

The common mistakes are guessing frequency instead of counting it, estimating duration instead of timing it, assuming the automation handles every case, ignoring review and maintenance time, and counting saved minutes that were never really spent. Each one makes the number look better than reality.

The last one is subtle. Sometimes a task is technically manual but rarely done properly, so automating it creates new value rather than saving existing time. That is fine, but call it what it is. Claiming time saved for work nobody was doing sets up a disappointing comparison later.

Another trap is double counting. If two automations both claim to save the same person's time on overlapping tasks, the total can exceed the hours that person actually works. Add up the estimates for one role and check that the total is plausible before presenting it.

What should you do next?

Pick the automation idea your team is most excited about. Count how often the task happened last month, ask someone to time ten instances, and sort a sample into routine and exceptions. Then run the formula, subtract build and maintenance time, and compare the payback against your other ideas.

My view is that an honest estimate is more persuasive than an exciting one. A modest number backed by real counts and timings gets approved faster, gets built with clearer goals, and holds up when someone checks the results six months later.

If you want help estimating the value of your automation ideas, or building the ones that clear the bar, reach out. Let's chat about which tasks are really worth automating in your team.