Automation ROI is the number every finance director asks for and almost nobody produces honestly. The request sounds simple — tell me what we get back for what we spend — but the moment you try to fill in a spreadsheet you discover that nobody knows how long the process actually takes, nobody has costed the exceptions, and the benefit everyone is counting on is a headcount reduction that will never be signed off. So the number gets rounded up, the business case gets approved, and eighteen months later the savings cannot be found in any budget line.
This guide is a working automation ROI calculator: the formula, the seven inputs it needs, where each input really comes from, two fully worked examples with numbers you can argue with, and the specific mistakes that turn a credible return on investment case into a fiction. It is written for mid-sized UK organisations spending their first serious money on business process automation, not for vendors trying to close a deal.
The framing matters more than the arithmetic. A good automation ROI model is not a persuasion tool that produces a big percentage; it is a decision tool that tells you which processes to automate first, which to leave alone, and when to stop. Our workflow automation and intelligent automation practice sees the same pattern repeatedly: the organisations that get real returns are the ones whose first model was pessimistic enough to be believed.
Table of contents
- What an automation ROI calculator actually has to answer
- The automation ROI formula, written out properly
- Building the cost side of your automation ROI model
- Building the benefit side of automation ROI without inventing numbers
- The seven inputs every automation ROI calculator needs
- Worked example: automation ROI on an invoice processing queue
- A second worked example: automation ROI on employee onboarding
- Payback period, NPV and IRR: three views of automation ROI
- Why most automation ROI numbers are wrong
- The hidden costs that destroy automation ROI
- How process choice changes automation ROI
- Automation ROI by technology: workflow, RPA and AI agents
- Measuring realised automation ROI after go-live
- A 90-day plan to prove automation ROI
- Automation ROI calculator: frequently asked questions
- References and Further Reading
What an automation ROI calculator actually has to answer
Most spreadsheets labelled as an automation ROI calculator answer the wrong question. They compute a percentage for a single process over a single year and stop. That number cannot support a decision, because it says nothing about sequencing, nothing about risk, and nothing about what happens in year three when the underlying system is upgraded.
Four questions, not one
A useful automation ROI calculator answers four things at once. Is this process worth automating at all? Which of the twelve candidate processes should go first? How long before the investment is recovered? And what has to be true for the answer to stay true?
Why the single-percentage output fails
A 340% return sounds decisive until you notice it assumes the process volume never falls, the vendor never raises the licence, and the two people freed up leave the organisation. Change any one of those and the figure collapses. A single percentage hides every assumption that could break it, which is precisely why finance teams distrust automation ROI claims by default.
The comparison that actually gets made
Your business case is not competing against doing nothing. It is competing against every other use of the same money — a warehouse system, two more engineers, a data migration. That means your automation ROI has to be expressed in the same currency as those alternatives, which in practice means payback period and net present value, not a headline percentage.
The honesty test
Before you present anything, apply one test: would you still recommend this if the benefits came in 40% below forecast? If yes, the case is robust. If no, you have not built an automation ROI model, you have built an argument. Every credible business case we have seen survives that question, and most optimistic ones do not.
The automation ROI formula, written out properly
The textbook formula is trivial and misleading in equal measure. Written out with the terms that actually vary, it becomes a tool rather than a slogan.
The base formula
Automation ROI, expressed as a percentage over a defined period, is the net benefit divided by the total cost of that period. Net benefit is gross annual benefit minus ongoing annual cost. Total cost is the one-off implementation cost plus the cumulative ongoing cost across the period. Everything difficult in an automation ROI calculation lives inside those three phrases.
Why the period must be stated
A three-year window and a five-year window produce wildly different answers from identical inputs, because the one-off build cost is amortised across more benefit years. State the period explicitly and use the same one for every process you compare. Three years is the honest default for automation work, because that is roughly how long a process definition survives before the business changes it.
The formula in plain terms
Net annual benefit equals hours saved multiplied by fully loaded hourly cost, plus error-cost avoided, plus any genuine revenue effect, minus annual licence, minus annual maintenance effort. Cumulative automation ROI over three years is three times that net annual benefit, minus the build cost, divided by the build cost plus three years of ongoing cost.
The number nobody calculates
The figure that changes decisions most often is not the percentage — it is the break-even volume. Divide the annual ongoing cost by the net benefit per transaction and you get the number of transactions per year below which this automation loses money. Many pilots sit uncomfortably close to that line, and knowing it is the difference between a considered automation ROI and a hopeful one.
Building the cost side of your automation ROI model
Cost is the side people think they understand, and it is where most automation ROI models are wrong by a factor of two. The licence is visible and usually the smallest component.
Discovery and process mapping
Before anything is built, somebody has to document what the process actually does, including the branches nobody mentions in the workshop. Budget five to fifteen days depending on complexity. Skipping this is the single most reliable way to double your build cost later, and it is why process mining and structured mapping against BPMN 2.0 repay their cost quickly.
Build and configuration
The visible cost. For a moderately complex process this is typically fifteen to forty days of a developer or automation specialist, whether internal or contracted. Internal effort is still a cost — if you exclude it because it is “already paid for”, your automation ROI is inflated by the largest single line in the model.
Licensing and platform
Per-bot, per-user, per-run or per-seat, depending on the vendor. This is the number vendors lead with because it is the only one they control. It is real, it is annual, and it usually rises. Assume a 5% to 8% annual increase unless you have a contractual cap.
Testing, UAT and change management
Somebody has to prove the automation does what the process did, and somebody has to persuade a team to trust it. Five to ten days of testing and a similar amount of communication and training effort is normal. Automation ROI models that omit change management routinely find their benefits unrealised because people quietly kept doing the manual process alongside the automated one.
Maintenance and the true annual burden
This is the line that decides whether your automation ROI survives contact with year two. Every automation breaks when an upstream screen, form or API changes. Budget 15% to 25% of the original build cost per year as ongoing maintenance for screen-driven automation, and 8% to 15% for API-driven workflow.
| Cost line | Typical UK range | One-off or annual | Most common error |
|---|---|---|---|
| Discovery and mapping | £3,000–£12,000 | One-off | Skipped entirely |
| Build and configuration | £9,000–£35,000 | One-off | Internal time counted as free |
| Platform licence | £2,000–£20,000 | Annual | Uplift not modelled |
| Testing and UAT | £2,500–£9,000 | One-off | Compressed to fit a date |
| Change management | £2,000–£8,000 | One-off | Assumed to be free |
| Maintenance | 8–25% of build | Annual | Omitted from year 1 |
| Monitoring and support | £1,500–£6,000 | Annual | Absorbed silently by IT |
The ranges above assume a mid-sized organisation buying at UK market rates in 2026. They are deliberately wide, because a well-scoped API integration and a fragile screen-scraping automation of a legacy portal genuinely differ by that much.
Note what that distribution does to a naive model. If you count only build and licence — the two lines a vendor quote contains — you have captured half the three-year cost and your automation ROI is roughly double the truth.
Building the benefit side of automation ROI without inventing numbers
Benefits are where automation ROI models become fiction. The arithmetic is easy; the discipline is refusing to count things you cannot bank.
Hours saved, measured not estimated
Ask a team how long a task takes and you will get the time it takes when nothing goes wrong. Measure it instead: timestamps in the ticketing system, a two-week tally sheet, or process mining against the underlying event log. The gap between estimated and measured is routinely 30% in either direction, and it is the largest single source of error in any automation ROI figure.
Fully loaded hourly cost, not salary
Divide salary by 1,700 productive hours a year, then add employer National Insurance, pension, software, management overhead and facilities. For a £32,000 administrator the fully loaded rate is usually around £24–£28 per hour, not the £17 the payroll figure suggests. Using the raw salary understates benefit by a third.
The cashable versus non-cashable distinction
This is the distinction that decides whether your finance director accepts the model. Cashable benefit is money that leaves the cost base: a contractor not renewed, an overtime budget cut, a licence retired. Non-cashable benefit is time released back to people who stay employed. Both are real. Only one shows up in a budget.
How to count released time honestly
Released time is worth counting when you can name what it will be used for and somebody has agreed to it. “Two days a week returned to the finance team, which absorbs the acquisition’s transaction volume without a new hire” is a benefit. “Freed up for higher-value work” is not, and presenting it as one is why automation ROI claims have a credibility problem.
Error and rework avoidance
Often the largest genuine benefit and almost always the least measured. Count the current error rate, the average cost to correct one error including downstream effects, and the residual error rate after automation — which is never zero. Our analysis of the cost of downtime and how to calculate ROI works through the same avoided-cost logic in a different setting.
Speed, capacity and revenue effects
Faster cycle time only produces money if something downstream converts it — an invoice paid earlier improving working capital, a quote issued same-day winning more business, a customer onboarded in a day rather than a week reducing drop-off. Model the mechanism, not the adjective. If you cannot name the mechanism, leave the benefit out of the automation ROI calculation.
| Benefit type | Cashable? | Evidence needed | Include in the case? |
|---|---|---|---|
| Contractor or agency spend removed | Yes | Signed decision to end the contract | Full value |
| Overtime reduced | Yes | 12 months of overtime records | Full value |
| Post not backfilled after a leaver | Yes | Agreed establishment change | Full value |
| Rework and error correction avoided | Partly | Measured error rate and unit cost | Full value, net of residual errors |
| Growth absorbed without hiring | Partly | Approved plan showing the avoided post | Full value if the plan is signed |
| Time released to existing staff | No | Named reallocation with an owner | Show separately, do not add in |
| Improved morale or experience | No | Survey or attrition data | Narrative only |
Presenting the last two rows separately rather than folding them into the headline is the single change that most improves how an automation ROI case is received. It signals that you know the difference, which makes the cashable numbers more believable.
The seven inputs every automation ROI calculator needs
Strip away the spreadsheet formatting and an automation ROI calculator has exactly seven inputs. Everything else is derived.
Input one: annual transaction volume
How many times per year the process runs. Take it from the system of record, not from memory, and check whether volume is growing, flat or seasonal. A process running 400 times a year rarely justifies automation; one running 40,000 times almost always does.
Input two: measured handling time per transaction
Minutes of human effort per transaction, measured. Split it if the process has a fast path and a slow path — a weighted average across a 70/30 split behaves very differently from a single mean when you model the exception route.
Input three: fully loaded hourly cost
The blended rate of whoever does the work today, loaded as described above. Use a blend if two grades are involved, and use the rate of the person who will actually stop doing the task, not the average of the department.
Input four: automation coverage rate
The proportion of transactions the automation will actually complete end to end without a human. This is the input people get most wrong. First automations of a messy process land between 60% and 80%, not the 95% the demo implies. Every point of coverage you assume above reality inflates the automation ROI proportionally.
Input five: residual handling time
Exceptions still cost time, and often more time per case than before, because the person picking one up has lost the context they used to build by doing all of them. Model exception handling at 1.2 to 1.5 times the original per-transaction time.
Input six: total implementation cost
Discovery, build, testing, change management, and any integration work on the systems either side. The full one-off figure from the cost table above.
Input seven: total annual running cost
Licence, maintenance, monitoring and support. The recurring figure that has to be beaten every year for the automation ROI to keep improving.
| Input | Where it comes from | Optimism bias | Sensitivity |
|---|---|---|---|
| Annual volume | System of record export | Low | High |
| Handling time | Timed sample or event log | High | High |
| Loaded hourly cost | Finance, not payroll | Understated | Medium |
| Coverage rate | Pilot measurement | Very high | Very high |
| Residual handling time | Exception sample | High | Medium |
| Implementation cost | Quote plus internal days | Understated | High |
| Annual running cost | Licence plus maintenance % | Understated | Very high |
The two inputs marked “very high” in both columns — coverage rate and annual running cost — are where a sensitivity analysis earns its keep. If your automation ROI stays positive when coverage drops ten points and running cost rises 25%, you have a decision. If not, you have a gamble.
Worked example: automation ROI on an invoice processing queue
Numbers make the method concrete. This is a purchase-ledger example built from a composite of typical mid-market UK figures.
The starting position
An accounts payable team processes 18,000 supplier invoices a year. Measured handling time is 6.5 minutes per invoice on the clean path and 19 minutes on the exception path, with 22% going to exceptions. The blended fully loaded rate is £26 per hour. Total annual effort is roughly 2,000 hours, or £52,000.
What automation actually achieves
An OCR-plus-workflow automation reaches 74% straight-through processing after tuning — well short of a demo, entirely normal in practice. The remaining 26% still needs a human, at roughly 1.3 times the original exception time because context is lost.
The benefit calculation
Automated transactions: 13,320 × 6.5 minutes saved = 1,443 hours. Remaining manual work rises slightly on the exception path, costing back about 190 hours. Net saving is roughly 1,253 hours, or £32,578 a year at £26. Error correction avoided adds a further £4,100 based on a measured 3.1% error rate falling to 0.9%, at £62 per corrected invoice.
The cost calculation
Discovery £6,000, build £22,000, testing £4,500, change management £3,000 — £35,500 one-off. Licence £7,200 a year, maintenance at 12% of build £2,640, monitoring £1,800 — £11,640 a year.
The resulting automation ROI
Net annual benefit is £36,678 minus £11,640, or £25,038. Over three years that is £75,114 against a total cost of £35,500 plus £34,920, or £70,420. Three-year automation ROI is therefore about 107%, with a payback period of roughly 17 months.
What that number really says
107% over three years is a genuinely good result, and it is nothing like the 400% figures in vendor material. It also survives pessimism: drop coverage to 65% and raise running cost 25% and the three-year automation ROI is still positive at about 46%. That robustness is what makes it approvable.
Presenting three scenarios rather than one is the practical difference between a business case and a pitch. It also protects you, because the pessimistic column is the one you will be measured against.
A second worked example: automation ROI on employee onboarding
The second example deliberately produces a weaker answer, because knowing when not to automate is half the value of the exercise.
The starting position
An HR team onboards 240 new starters a year. The process spans seven systems and takes 95 minutes of coordinated effort per starter, with a fully loaded rate of £29. Annual effort is 380 hours, or about £11,020.
Why the volume changes everything
Even perfect automation cannot save more than £11,020 a year here, and the process touches seven systems, three of which have no usable API. Build cost lands at £28,000 because of the integration work, with £6,800 a year of licence and maintenance.
The resulting automation ROI
At 70% coverage the annual saving is roughly £7,700, giving a net annual benefit of £900 after running costs. Three-year automation ROI is deeply negative. The payback period exceeds the useful life of the automation.
The decision this drives
Do not automate this process yet. Standardise it, remove three of the seven systems, then reconsider. That is a legitimate output of an automation ROI calculator, and a model that never produces it is not a model — it is an approval machine.
The pattern to take from both examples
High volume and low per-unit complexity beats low volume and high complexity, almost every time. An automation ROI calculator mostly exists to tell you which of your candidate processes is which, before you have spent anything finding out.
Payback period, NPV and IRR: three views of automation ROI
Percentage return is one lens. Finance teams usually want two more, and offering them unprompted markedly improves how the case lands.
Payback period
Months until cumulative net benefit equals cumulative cost. Intuitive, widely understood and the number most non-finance stakeholders actually respond to. Under 18 months is comfortable for automation work; over 30 months usually means the process was the wrong candidate.
Net present value
Future money is worth less than money today, so discount it. UK public sector appraisal uses the HM Treasury Green Book discount rate, and private organisations typically use their own cost of capital. A positive net present value at your hurdle rate is a stronger claim than any automation ROI percentage.
Internal rate of return
The discount rate at which NPV reaches zero — useful when the finance function compares projects across the whole capital programme. Quote it if it is asked for; leading with it in an operational audience adds confusion rather than credibility.
Which to lead with
Lead with payback period for the operational sponsor, NPV for the finance director, and automation ROI percentage for the board summary. Same model, three outputs, no contradictions between them.
| Measure | What it answers | Strength | Weakness |
|---|---|---|---|
| Automation ROI % | How much do we get back per pound spent | Immediately understood | Ignores timing entirely |
| Payback period | When are we square | Communicates risk well | Ignores everything after payback |
| Net present value | What is it worth in today’s money | Comparable across projects | Needs an agreed discount rate |
| Internal rate of return | What return does it imply | Speaks the finance language | Misleads on short projects |
| Break-even volume | How far can volume fall | Exposes fragility directly | Rarely asked for, so rarely built |
Build all five once and you can answer any version of the question without rebuilding the model, which is the practical reason to treat an automation ROI calculator as a small piece of engineering rather than a slide.
Why most automation ROI numbers are wrong
There are five recurring errors. Each one alone inflates the result; together they produce the 400% figures that make finance directors stop listening.
Assuming full-time equivalent savings convert to cash
Saving 0.4 of a person’s time in four different teams saves nothing in the budget. FTE savings only become cashable when they aggregate to a whole role somebody agrees not to fill. This is the most common single reason a realised automation ROI misses its forecast.
Using demo coverage rates
Vendor demonstrations run on clean data. Your data is not clean. Assume real coverage lands 15 to 25 points below the demonstration, and validate it in a pilot before the full business case is signed.
Forgetting that automations decay
Screens change, APIs version, suppliers alter their document formats. An automation that needed no attention in month three needs a day in month nine and three days in month twenty. Modelling year one maintenance and holding it flat understates cost every time.
Counting the same benefit twice
Time saved and error reduction frequently overlap — the hours you saved included the rework you are now also counting separately. Net one against the other explicitly, or your automation ROI double-counts a chunk of its own benefit.
Ignoring the cost of the exception path
Partial automation moves work rather than removing it. If the 26% of cases that still need people now take longer per case, that increase is a real cost and belongs in the model, not in a footnote.
Beyond the modelling errors, four operational costs turn a good forecast into a disappointing outcome.
Process debt
Automating a bad process makes the bad process permanent and harder to change. The cheapest automation ROI improvement available to most organisations is removing steps before automating what remains — and removed steps cost nothing to run and never break.
Platform sprawl
Three teams buying three automation tools produces three licence bills, three skill sets and no shared components. Consolidating platforms is the single highest-leverage decision in a multi-year automation programme, and it is much cheaper made early. Our digital strategy work exists largely to prevent this outcome.
The key-person dependency
If one person built it and one person understands it, the automation carries a risk that never appears in the automation ROI model until that person leaves. Documentation, code review and a second pair of hands are cheap relative to a rebuild.
Governance and audit overhead
Automation touching personal or financial data attracts controls. Access reviews, logging, approvals and audit evidence all cost time. Where models are involved in the decision path, the ICO guidance on AI and data protection and the NIST AI Risk Management Framework set expectations that translate directly into effort.
The ordering is the useful part. Four of the five causes are modelling and governance problems rather than technology problems, which is why a better automation ROI method beats a better automation platform in most organisations.
How process choice changes automation ROI
Selecting the right first process matters more than selecting the right tool. A strong candidate produces a defensible return on almost any platform; a weak one fails on all of them.
Score candidates before you model them
Rank every candidate process on volume, rule clarity, input consistency, system accessibility and error cost. Model the top three properly and leave the rest. This ordering step takes a day and routinely saves months.
Volume is the dominant term
Because build cost is largely fixed, per-transaction economics improve linearly with volume. A process running weekly will almost never produce a positive automation ROI; one running hundreds of times a week usually will, even with mediocre execution.
Rule clarity beats process importance
Teams instinctively nominate their most important process. Automate the most deterministic one instead — the one where a competent new starter would make the same decision as a twenty-year veteran every time.
Input consistency decides your coverage rate
Structured, predictable inputs give high straight-through rates. Free-text emails and varied supplier PDFs give low ones. This single characteristic explains most of the variance in realised automation ROI between two otherwise similar projects.
System accessibility decides your maintenance bill
An API-driven integration is dramatically cheaper to keep alive than screen automation over a legacy interface. Where you must automate a legacy portal, treat it as a temporary bridge rather than a five-year commitment — the same reasoning we apply when building a master data management business case, and it is why data analytics readiness so often gates automation work.
| Factor | Score 1 | Score 3 | Score 5 |
|---|---|---|---|
| Annual volume | Under 500 | 500–5,000 | Over 5,000 |
| Rule clarity | Judgement-heavy | Mostly rules, some judgement | Fully deterministic |
| Input consistency | Free text and mixed formats | Semi-structured | Structured and validated |
| System access | Screen only, legacy | Partial API coverage | Full documented API |
| Error cost | Trivial | Moderate rework | Regulatory or financial |
| Process stability | Changes quarterly | Changes yearly | Stable for years |
Anything scoring under 18 out of 30 rarely repays a full automation ROI exercise, let alone the build. Anything over 24 deserves a properly costed model this quarter.
Automation ROI by technology: workflow, RPA and AI agents
The three main technology choices have genuinely different cost structures, so the same process can produce different automation ROI depending on how it is built.
Workflow automation through APIs
Lowest maintenance, highest reliability, best long-term automation ROI where the APIs exist. Platforms such as Power Automate, Camunda and Temporal occupy different points on the price and durability curve.
Robotic process automation
Higher maintenance because it depends on interfaces that change without notice, but it reaches systems nothing else can. RPA and desktop flows justify their maintenance premium when the alternative is no automation at all. Our RPA practice treats it as a bridge, not a destination.
AI agents and model-based steps
Highest capability on unstructured input, highest variability, and a genuinely different cost profile: inference cost per transaction, evaluation effort, and human oversight. Automation ROI here depends on volume in a way the others do not, because cost scales with usage rather than sitting flat.
The combination that usually wins
A deterministic workflow spine calling a model for the one judgement step that needs it. You get predictable economics for 90% of the path and capability where it matters — the pattern our comparison of workflow automation, RPA and AI agents works through in detail.
What this means for the model
Run the automation ROI calculation twice with different technology assumptions before choosing. The answer changes the maintenance percentage and often the coverage rate, which are two of the three most sensitive inputs.
Measuring realised automation ROI after go-live
A forecast nobody checks teaches nothing. The organisations whose second business case is believed are the ones that measured their first.
Baseline before you build
Capture volume, handling time, error rate and cost for at least a month before anything changes. Without a baseline, realised automation ROI cannot be calculated at all, only asserted — and this step is skipped more often than any other.
Instrument the automation itself
Log every run, every exception and every manual intervention. Straight-through rate is the single most important operating metric, because it is the input your forecast was most likely wrong about. The GOV.UK guidance on measuring success and DORA’s metrics guidance both apply cleanly here.
Review at 90 days and one year
At 90 days check coverage and exception time against forecast. At one year check maintenance effort and licence cost. Those two reviews catch almost every way an automation ROI forecast goes wrong, and both are cheap.
Track cashable benefit separately
Ask finance to confirm which forecast savings actually left the cost base. This is uncomfortable the first time and transformative afterwards, because it calibrates every subsequent model you build.
Feed the result back into the next case
Realised coverage rates and realised maintenance percentages from your own estate are worth more than any benchmark. After three automations you can forecast the fourth with real confidence, and your automation ROI models stop being estimates and start being extrapolations.
A 90-day plan to prove automation ROI
Rather than modelling everything, prove the method on one process and let the result fund the next.
Days 1–15: select and baseline
Score the candidate list, pick one process scoring above 24, and baseline it properly. Resist the temptation to pick the process with the loudest sponsor.
Days 16–30: map and cost
Document the real process including exceptions, then build the full cost model with internal effort included. Produce the three-scenario automation ROI at this point, before anything is built.
Days 31–60: build a thin version
Automate the clean path only and route everything else to people. A narrow automation that works beats a broad one that half-works, and it produces a measured coverage rate — the input your model most needed.
Days 61–80: run in parallel
Run automated and manual paths side by side on live volume. Measure straight-through rate, exception time and error rate against baseline.
Days 81–90: recalculate and decide
Rebuild the automation ROI with measured inputs rather than assumptions. Then decide: extend, hold or stop. All three are legitimate, and having a real stop option is what makes the exercise credible.
What you have at the end
One working automation, one calibrated model, and measured coverage and maintenance figures from your own systems. That combination makes the second business case dramatically easier to approve than the first — and it is the foundation of our digital transformation and managed IT services engagements.
Automation ROI calculator: frequently asked questions
What is a good automation ROI percentage?
Over three years, 80% to 150% is a strong, defensible result for process automation. Anything above 300% should be re-examined for double-counted benefits or non-cashable savings presented as cash.
How long should payback take?
Under 18 months is comfortable. Between 18 and 30 months is acceptable if the process is stable and the volume is growing. Beyond 30 months, the process is usually the wrong candidate rather than the automation being badly built.
Should internal staff time be counted as a cost?
Yes, always. Excluding internal effort because it is already in the budget is the most common way an automation ROI model overstates its result, and finance teams spot it immediately.
What coverage rate should we assume before a pilot?
Assume 65% to 75% for a first automation of a real process, regardless of what a demonstration achieves. Replace the assumption with a measured figure as soon as a pilot produces one.
How do we value time saved if nobody leaves?
Show it separately as released capacity, with a named reallocation, and keep it out of the headline automation ROI. If the capacity absorbs growth that would otherwise have required a hire, and that hire is in an approved plan, it becomes cashable.
Does AI change the calculation?
It changes the cost shape. Model-based steps cost per transaction rather than per licence, and add evaluation and oversight effort. High volume improves the automation ROI of a rules-based approach and can worsen it for a model-based one, which is the opposite of most people’s intuition.
How often should the model be revisited?
At 90 days, at one year, and whenever licence terms or process volume change materially. An automation ROI calculation is a live artefact, not a one-off approval document.
References and Further Reading
HM Treasury, The Green Book: appraisal and evaluation in central government
GOV.UK Service Manual, Measuring success
GOV.UK, The Technology Code of Practice
GOV.UK Service Manual, Moving away from legacy systems
AI Playbook for the UK Government
ONS, Business insights and impact on the UK economy
Object Management Group, BPMN 2.0 Specification
Microsoft, Get started with Power Automate
Microsoft, Introduction to desktop flows
Temporal, Understanding Temporal
DORA, Measuring delivery performance with DORA metrics
FinOps Foundation, The FinOps Framework
Martin Fowler, Strangler Fig Application
