Measuring Automation ROI Honestly, Not With Vendor Maths

Almost every automation business case I have reviewed opens with the same line: we automate this process, we save 40 hours a month, at a loaded rate of AED 150 an hour that is AED 72,000 a year. It looks precise. It is usually fiction. Saved minutes are not money until something in the budget actually changes. This is a framework for building an automation ROI number that survives contact with finance, and later with audit.

Why hours saved times hourly rate lies

The standard calculation multiplies time saved by a loaded hourly rate and calls the result a benefit. The hidden assumption is that the freed time converts into cash. It rarely does on its own. If a clerk who spent 40 hours a month re-keying invoices now spends those 40 hours doing something else, the payroll cost has not moved by one dirham. You have redistributed effort, not released money.

Time saved becomes money in exactly three ways, and only three:

• A headcount is removed. A role is genuinely taken out of the budget, or a contractor is stood down. This is real, cashable, and rare.
• A vacancy goes unfilled. Someone leaves or the team was about to grow, and the automation means you do not backfill or do not hire. Cash you would have spent, you now do not.
• Freed capacity absorbs growth. Volume rises 20% but the team stays the same size. You avoided the cost of scaling. Real, but only if the growth is real and the team genuinely would have grown.

This is not pedantry. It is the difference between a case a CFO signs and one a CFO quietly discounts by 70% because they have been burned before. Naming the mechanism is the single most credible thing you can do.

Say which of the three you are claiming

Each mechanism carries a different burden of proof, and each fails in a different way. Headcount removal is the strongest claim but the hardest politically; nobody wants their name on the line that eliminates a role, so it quietly becomes "redeployment" and the cash evaporates. Vacancy avoidance is the cleanest to evidence because you can point to an open requisition that was closed or a leaver who was not replaced. Growth absorption is the most abused, because "we would have hired three more people" is trivially easy to assert and almost impossible to prove after the fact.

Write the mechanism into the case in plain words next to the number. "This releases AED 90,000 by not backfilling one FP&A analyst role when the current analyst moves in Q2" is a sentence finance can test. "This saves 600 hours" is a sentence finance ignores. If you are early in your automation programme and unsure how much of this you can honestly claim, the sequencing question is worth its own read in the automation maturity model, and the selection question in the workflow automation buyer's guide.

A taxonomy of benefits and the evidence each needs

Not every benefit is a cash saving, and pretending they are the same is how business cases lose credibility. Separate them into four types. Each is legitimate, but each needs its own kind of evidence to survive an audit or a post-implementation review.

The discipline here is to never blend types into one headline number. A steering pack that says "AED 1.2m of benefit" without saying how much is cash and how much is avoidance is asking to be disbelieved. A pack that says "AED 300k cash releasing, AED 500k cost avoidance, AED 400k risk reduction" invites a grown-up conversation about how much of each the board is willing to bank.

A worked three-year model, honestly costed

Take one real process: supplier invoice matching in accounts payable, currently done by two clerks doing manual three-way matching. We automate the match. Here is the model built properly, with every cost that vendor slides tend to omit.

Optimistic three-year net is roughly AED 198,000 positive, with payback inside year two. That is the number a vendor puts on a slide. Now add reality. The 15% maintenance figure vendors quote is low for anything touching an ERP; a realistic figure for an integration that breaks whenever the supplier master or the ERP is patched is closer to 30% of build cost per year, plus the benefit rarely lands at 100% because the clerks still handle exceptions the bot cannot match.

Realistic three-year net is about AED 24,000 negative. The same automation flips from a clear winner to a marginal loss purely by costing maintenance honestly and discounting the benefit to what actually lands. Neither table is dishonest; the gap between them is the sensitivity band, and showing both is what earns trust. Present a single point estimate and you are asking the board to gamble on your most optimistic assumption without telling them it is optimistic.

The measurement discipline

A number is only as good as the measurement behind it. Three habits separate a defensible benefit from a guess.

1. Baseline before you build, not after.

You cannot prove a saving if you never measured the before. Capture the current cycle time, volume, error rate, and effort while the manual process is still running. Once automation is live, the old baseline is gone forever and any "before" number you produce is a reconstruction nobody can audit. If you take one thing from this article, it is: measure first, build second.

2. Agree the metric with finance in writing.

Before a line of code is written, sit with finance and agree exactly what will be measured, how it converts to money, and what evidence will count at review. Get it in an email or a one-page memo both parties keep. This kills the most common failure mode: you claim a saving, finance uses a different definition, and the benefit is disputed into nothing at the post-implementation review.

3. Instrument the process so the number comes from the system.

The benefit figure should be pulled from the system logs, not from a survey asking staff how much time they think they save. Self-reported time savings are inflated and unauditable. If the automation platform records volume processed, exceptions, and cycle time, your benefit number is a query, not an opinion. Low-code platforms make this instrumentation straightforward; Microsoft documents the analytics and monitoring surface for exactly this in its Power Platform guidance .

A one-page benefits register and three claims to avoid

Everything above collapses into a single artefact you maintain for the life of the automation: a benefits register. One row per benefit, reviewed at each steering meeting. If a benefit is not in the register with an owner and an evidence source, it is not a benefit, it is a wish.

And three claims to never put in a steering pack, because each one invites the audience to distrust the whole document:

• "We saved X hours, therefore we saved X dirhams." Not until a headcount, vacancy, or growth mechanism is named. Otherwise it is redistributed effort.
• "The payback is under a year." Almost never true once honest maintenance and partial benefit realisation are in the model. State the realistic case, not the optimistic one.
• "This benefit is guaranteed." Nothing in a forecast is guaranteed. Give a band and an owner, and let the board decide how much to bank.

Conclusion

Automation can absolutely pay, and often does. But the number in the business case has to be honest, or the whole programme loses credibility the first time a claimed saving fails to appear in the accounts. Name the mechanism. Separate the benefit types. Cost maintenance at a real rate. Baseline before you build, agree the metric with finance in writing, and read the benefit from the system. Do that, and you will lose a few marginal cases you should never have run, and you will win the trust to run the good ones at scale.