How many hours will automation actually save us?
Take the runs per month, multiply by the minutes each takes, and then cut the result by the share the automation will not handle. That last step is the one everybody skips, and it is why quoted savings and real savings diverge.
A document process running 300 times a month at 9 minutes is 45 hours. At a realistic 85% straight-through rate, the automation removes about 38 of them and the remaining 7 move into a review queue. Thirty-eight is the honest number. Forty-five is the number in most proposals.
The second correction is that saved hours are rarely saved salary. Removing 38 hours a month across four people does not remove a person; it removes the reason you needed the next hire. That is a real benefit and a different one, and conflating them is how automation projects end up judged a disappointment despite working perfectly.
The arithmetic, with the correction
Three lines, and the third is the one that gets left out.
Gross hours = runs per month × minutes per run ÷ 60
Net hours = gross hours × straight-through rate
Monthly value = net hours × fully loaded hourly cost
Worked, for invoice processing:
| Runs per month | 300 invoices |
| Minutes each, today | 9 |
| Gross hours | 45 |
| Realistic straight-through rate | 85% |
| Hours the exceptions still take | 45 × 15% = about 7 |
| Net hours saved | about 38 |
| Loaded cost per hour | $45 |
| Monthly value | about $1,700 |
Against $3,500 setup, with no monthly fee on pay as you go, payback lands inside three months. Note that the answer barely changes whether you assume 85% or 90%. When a case is this strong, precision does not matter. Precision matters when it is marginal, which is exactly when people stop doing the arithmetic.
After tuning: 75–90% for document work with varied inputs, 90–98% for rule-based routing where all the data is structured, and near 100% for a simple two-system handoff with no judgment in it. Anyone quoting 100% on the first two has not counted the exceptions.
Getting the inputs right
The arithmetic is trivial. The inputs are where estimates go wrong, in a consistent direction.
Runs per month: count, do not estimate
Pull the actual number from the system for a full month, including the bad week. People estimate volume from memory and memory averages away the peaks, which is where the pain actually is.
Minutes per run: time it, and include the interruption
Ask someone to time themselves for a week rather than recall it. Two systematic errors run in opposite directions. People understate, because they time the typing and not the finding, the checking, the waiting for a page to load, or the going back because something was wrong. And people overstate the batch, because doing forty at once is faster per item than doing one.
Include the switching cost. A task that takes four minutes but arrives unpredictably nine times a day costs considerably more than 36 minutes, because each arrival interrupts something else. This is real and it is the reason frequent small irritations are often better first automations than one big monthly job.
Loaded hourly cost: not the salary divided by hours
Salary plus employment taxes, benefits, equipment, software seats and the share of overhead, divided by actual working hours after holiday and sickness. For a US administrator, $35 to $55 is a reasonable range. Using the bare salary figure understates by roughly a third.
Straight-through rate: assume you will not reach 100%
Ask the vendor for their expected rate and what happens to the remainder. If the answer is 100%, or there is no answer for the remainder, the estimate is fiction. See straight-through processing.
The hours are the smaller half
For several common automations the time saved is genuinely not the main benefit, and evaluating on hours alone will make you reject good projects and approve weak ones.
- Collections chasing saves four to ten hours a month. Collecting a week earlier improves working capital by a multiple of that, and it compounds.
- Lead routing saves a modest number of hours. Responding in under a minute instead of four hours changes conversion, which is a revenue number rather than a cost one.
- Invoice matching saves hours and stops duplicate payments and missed early-payment discounts. The second category is frequently larger and is invisible in an hours model.
- Anything that runs when someone is away. Continuity has no line in the arithmetic and is often the reason the business actually wanted it.
Make these arguments explicitly rather than smuggling them in as an optimistic hours estimate. A project justified honestly on working capital survives scrutiny; the same project justified on inflated hours does not.
Judging a vendor's number
Four questions that separate a measurement from a sales figure.
- "Where did the volume come from?" A system export, or somebody's recollection.
- "Is that gross or net of exceptions?" If they have not heard the distinction, it is gross.
- "What straight-through rate are you assuming, and what happens to the rest?" There should be a number and a review queue.
- "Who measured the baseline?" A saving claimed without a baseline is not a saving, it is a hope. If nobody timed the process before, nobody can tell you afterwards whether it worked.
That last one cuts both ways, and it is why we measure the baseline during scoping even when the case looks obvious. Without it there is no honest way to tell you later whether the thing you bought did what it was supposed to.
Want the number for your process rather than an example?
Tell us the volume and the systems on a call. We measure the baseline during scoping so there is something real to judge the result against later.
You will talk to Fayez or Kareem. Nobody else.