Four Questions That Break Most Automation ROI Numbers
Any vendor can produce a payback number. Four questions decide whether it survives contact with your actual operation - including when the vendor is us.
The number is a forecast
Every automation proposal ends with a number. Forty hours a week saved. Payback in four months. A percentage next to the word "efficiency".
The number is a forecast produced by the party that benefits from it looking good. That is not a reason to walk away, and it is not usually dishonesty either. Most inflated payback numbers are assembled from pieces that are each defensible and together add up to fiction.
Four questions take most of them apart. They work on any vendor, including us, and asking them the same way every time makes answers comparable across proposals.
One: whose hours, by name?
"Saves the team 40 hours a week" is not an answer. Which roles, doing which steps, how many times a week?
The reason to insist on names and roles is that the cost of an hour varies by a factor of five inside the same company, and the vague version quietly averages them. An hour of a licensed specialist reviewing something is not an hour of an assistant retyping an address, and a proposal that saves a lot of the second while claiming the rate of the first will look excellent on the page and disappointing in the ledger.
Then ask for the loaded cost rather than the salary: employer taxes, benefits, tooling, and the fraction of paid hours that is actually productive. The loaded figure is usually 1.3 to 1.6 times the raw hourly rate, and using the raw one understates the saving. Both errors happen; they just point in different directions and rarely cancel.
Two: do the saved hours turn into anything?
This is the question that removes most of the number, and it is the one almost nobody asks.
Twenty minutes a day returned to thirty people is 250 hours a month on a slide and, in most companies, nothing at all in the accounts. Nobody is dismissed, nothing extra is sold, and the time is absorbed by whatever else was already waiting. It is a genuine improvement in how the job feels. It is not payback.
Hours become money in two ways, and it is worth naming which one applies before signing:
| Route | What has to be true | Example from our deployments |
|---|---|---|
| Capacity you sell | You were turning work away | Rental firm absorbed 2.5x peak volume without hiring |
| A cycle that closes faster | Slow cycles were costing conversions | Brokerage cut the deal cycle from 14 days to 5 |
| Headcount you do not add | A hire was actually planned and budgeted | The plan exists in writing before the project starts |
The rental example is the cleanest one we have. Booking-to-dispatch went from 4 hours to 3 minutes, and peak-season bookings that used to be refused for lack of turnaround could suddenly be accepted. The hours themselves were incidental. The brokerage case is the second route: response time fell from 6 hours to 8 minutes and the cycle from 14 days to 5, and shorter cycles convert better because fewer buyers cool off in the gap.
If neither route applies, the honest description of the project is that it makes the work better, which is a legitimate thing to buy. It should just be bought with that expectation and not against a payback schedule.
Three: what volume does the number assume?
Automation economics are a fixed build cost divided by throughput, so the payback period moves violently with the volume assumption and barely at all with anything else.
A process that runs 400 times a month and saves 15 minutes each time is straightforward. The identical process at 80 times a month carries the same build cost against a fifth of the benefit, and it usually fails honest arithmetic even though the per-instance saving has not changed.
So: take the volume from your own systems rather than from an interview, use a slow month rather than a good one, and ask for the payback period at half the assumed volume. If the case only survives at the optimistic number, what is on the table is a bet on growth dressed as an efficiency project. That may still be worth taking, but it should be taken knowingly.
Four: who pays for it after go-live?
Build cost is quoted. Running cost usually is not, and it is where four-month payback becomes eleven-month payback.
Ask for a monthly figure covering all four of these, then multiply by twelve and add it to the build cost before dividing anything:
- Model and infrastructure per unit of volume, at your real volume.
- The people time spent on cases the system escalates, at the honest escalation rate. Any automation that hands uncertain cases to a human is spending that human's time by design, and keeping a person in the loop for anything binding is a deliberate choice with a price attached.
- Maintenance when the world moves: a supplier changes a form, a regulator adds a field, a channel changes an interface.
- The process owner's continued involvement after handover. An automation nobody owns degrades quietly, and the dashboards keep looking healthy while it happens.
What a good answer looks like
Worked honestly, the arithmetic is short. One process. Its volume from your own system, taken from a slow month. Minutes saved per instance, by role, at loaded cost. A named route by which those minutes become revenue or avoided cost. Twelve months of running cost added to the build cost. Divide.
Our own projects put one to three processes into production in two to four weeks, and payback usually lands in three to six months. That range holds because we only sign the ones where the saving has a route to the accounts — which is also why roughly one job in three ends at the diagnostic stage without a build. The audit that decides which is which is deliberately cheaper than the build it might cancel.
After go-live, three numbers tell you whether the forecast was real: hours actually freed by named people, the cycle time before and after, and the error rate on the automated step. Measuring those on a schedule is what converts a forecast into a fact, and the schedule should be set before anyone signs.
Ask us the four questions
We hand over the spreadsheet with the inputs visible, because a number the operator cannot interrogate is a number the operator cannot defend to their own board six months later.
Bring the four questions to whoever is quoting you next, whether that is us or somebody else. Any vendor who can answer all four in specifics has done the work. Any vendor who cannot has given you a decoration, and the fastest way to find out which you are holding is to ask about volume at half.
01Why should I distrust an ROI number even from a vendor I like?+
Because the number is a forecast, and the person producing it is the person who benefits from it being attractive. That is not an accusation of dishonesty; it is a description of where the incentive sits. Most inflated payback numbers are not invented, they are assembled out of defensible-looking pieces: an optimistic hourly volume, a headline salary rather than a loaded cost, minutes saved across a wide group that never turn into anything, and a build cost quoted without the running cost that follows it. Each piece is arguable on its own and the total is nonsense. The defence is not scepticism about the vendor, it is a fixed set of questions asked the same way every time, so that the answers become comparable between vendors and between projects. Ask them of us too. If a vendor cannot answer all four in specifics on a call, the number was decoration.
02What is the difference between hours saved and money saved?+
Hours saved become money in exactly two ways, and it is worth being blunt about which one applies before signing anything. The first is capacity you sell: the same team handles more volume, and the extra volume has revenue attached. An equipment rental company we worked with went from 4 hours to 3 minutes between booking and dispatch and used that to absorb 2.5 times the peak-season volume without hiring, which is real money because peak-season bookings were being turned away before. The second is a cycle that closes faster and therefore closes more often: a brokerage went from a 14-day deal cycle to 5 days, and shorter cycles convert at a higher rate because fewer buyers cool off in the gap. Everything else, particularly twenty minutes returned to thirty people who then do something unmeasured with it, is a real quality-of-life improvement and a fictional line in a business case. Count it as morale, not as payback.
03What running costs do proposals usually leave out?+
Four, in our experience, and they are the difference between a project that pays back in four months and one that pays back in eleven. First, model and infrastructure cost: every automated decision has a per-unit price, and at real volume that price is a monthly line item, not a rounding error. Second, the human in the loop: any automation that escalates uncertain cases to a person is spending that person's time by design, and the escalation rate has to be estimated honestly rather than assumed to be near zero. Third, maintenance when the surrounding world moves: a supplier changes a form, a regulator changes a field, a channel changes an API, and someone has to notice and fix it. Fourth, the cost of the process owner staying involved after handover, because an automation nobody owns degrades quietly and the reporting keeps looking fine while it does. Ask for these as a monthly figure and add twelve of them to the build cost before dividing.
04How much volume sensitivity should I demand before signing?+
Ask for the payback at half the assumed volume, and treat the answer as the real answer. Automation economics are dominated by fixed build cost divided across throughput, so the payback period is extremely sensitive to the volume assumption and almost nothing else. A process that runs 400 times a month and saves 15 minutes each time is a straightforward case. The same process at 80 times a month has the same build cost spread across a fifth of the benefit, and it usually fails honest arithmetic even though the per-instance saving is identical. This is the single most common reason a project that looked good on paper disappoints, and it is trivially avoidable: take the volume from your own systems rather than from an interview, use the low month rather than the good month, and ask what happens if the volume never grows. If the case only works at the optimistic volume, it is a bet on growth wearing the costume of an efficiency project.
