An automation proposal can look attractive when it multiplies a task's duration by its monthly volume. But someone may still check the output, resolve missing information, reconcile failed updates and maintain the workflow. Those hours belong in the calculation.
Calculate automation ROI from the work and spending that actually change. Establish the current baseline, subtract all remaining human effort, distinguish reusable capacity from cash savings, and compare the resulting benefits with implementation and operating costs.
The worked example below shows how to do that. Every number is illustrative; it is not a netlinkE client result, price quote or market benchmark.
Start with one completed business outcome
Choose a unit that an operator can recognise: a supplier request correctly recorded, a qualified enquiry assigned to an owner, or an invoice reconciled. Count that completed business outcome once.
A workflow may retry, call several child flows or update multiple systems to finish one request. Counting each technical run as a separate unit of business value can inflate the result.
This distinction matters when using built-in dashboards. Microsoft documents that Power Automate savings are generated from user-defined baselines on successful cloud-flow runs. Those totals depend on the rule you configure. A successful run is useful operational evidence, but your business-value calculation still needs a sound baseline and a record of work left outside the flow. Microsoft: Savings in Power Automate
Before estimating savings, map the workflow from trigger to outcome. Define which steps automation will change and which will remain.
Measure the current work honestly
Record both normal cases and the cases that need correction. The baseline should include the human effort required to finish the same scope of work to the same quality standard.
Measure active handling time separately from elapsed time. A request that waits two days for approval does not necessarily consume two days of staff effort. Faster turnaround may be valuable, but its value needs its own evidence.
Use a sample that includes the types of work the proposed system will actually encounter. If month-end requests are harder, include them. If incomplete submissions are common, retain them. Record the sample size, period and exclusions so the estimate can be challenged.
For a first model, collect these inputs:
| Input | What to record |
|---|---|
| Volume | Distinct business cases per month, with duplicates excluded |
| Current handling time | Average active staff minutes per case, including current corrections |
| Remaining routine work | Staff minutes still needed on every automated case |
| Exception work | Share of cases needing intervention and extra minutes per affected case |
| Maintenance | Monthly staff hours for monitoring, updates and repairs |
| Costs | Implementation, software, infrastructure and any paid support |
| Benefit mechanism | How released time changes spending, capacity or customer outcomes |
Use the same currency throughout. A Nigerian business can use naira and its own labour costs; a dollar-denominated vendor bill needs a documented exchange-rate assumption and a sensitivity check.
Subtract the work that survives automation
Consider a hypothetical professional-services team processing 1,000 requests per month. Each request currently takes an average of eight active staff minutes, including its share of corrections.
The proposed workflow reduces routine staff handling to one minute per request. However, 20% of requests still need six additional minutes of exception handling. Maintaining and monitoring the automation takes six staff hours each month.
The extra six minutes apply only to exception cases and are additional to the one-minute routine check. This avoids counting the same effort twice.
| Monthly calculation | Result |
|---|---|
| Current human effort: 1,000 × 8 ÷ 60 | 133.33 hours |
| Remaining routine work: 1,000 × 1 ÷ 60 | 16.67 hours |
| Extra exception work: 1,000 × 20% × 6 ÷ 60 | 20.00 hours |
| Monitoring and maintenance | 6.00 hours |
| Net staff capacity released | 90.67 hours |
The calculation is:
Released hours = current human hours − routine review hours − extra exception hours − maintenance hours.
Keep full precision during calculations and round only the displayed result. With these assumptions, the proposed system releases 90.67 hours monthly, rather than the entire 133.33-hour baseline.
If different roles perform the work, value their hours at their respective costs. The single hourly rate used below is a simplifying assumption.
Decide which savings are spendable
At an illustrative staff cost of $30 per hour, the released capacity has a monthly time value of $2,720. That figure does not establish that the business's bank balance improves by $2,720.
Keep three benefit categories distinct:
- Cash savings or avoided spending: documented reductions in overtime, contract work, another vendor bill, or an otherwise necessary hire.
- Reusable capacity: staff time available for other work, with a named owner and a practical redeployment plan.
- Service improvement: outcomes such as shorter turnaround or fewer errors, measured independently.
An avoided hire counts only against a credible hiring requirement in the baseline. Extra capacity counts as additional contribution only when there is work to fill it and evidence of the contribution after delivery costs. Do not count the same freed hours as both salary savings and revenue-generating capacity.
For the worked example, assume the budget owner can turn half of the net released capacity into documented avoided overtime or contractor spending. The other half remains capacity value and is excluded from the cash calculation.
That produces $1,360 in monthly cash benefits. This 50% conversion is an assumption to test, not a standard percentage to copy.
Calculate payback and first-year ROI consistently
Assume implementation costs $6,000 upfront and software costs $300 per month. The six monthly maintenance hours are already deducted from released capacity; no separate maintenance invoice is assumed. If support is purchased separately, add that cost.
| Cash calculation | Result |
|---|---|
| Monthly cash benefit | $1,360 |
| Monthly software cost | $300 |
| Monthly net cash benefit | $1,060 |
| Simple payback: $6,000 ÷ $1,060 | 5.66 months |
| First-year cash benefits: $1,360 × 12 | $16,320 |
| First-year costs: $6,000 + ($300 × 12) | $9,600 |
| First-year net benefit | $6,720 |
| First-year ROI: $6,720 ÷ $9,600 | 70% |
Here, first-year ROI means:
(First-year cash benefits − all first-year costs) ÷ all first-year costs × 100%.
Do not subtract the monthly software bill from benefits and then subtract it again as a cost. Use one consistent formulation.
This simple estimate assumes the same volume, exception rate, costs and realised benefits for all twelve operating months. It excludes deployment delay, ramp-up, tax, financing and discounting. A larger or longer-lived investment needs a dated cash-flow model that includes these effects and the expected life of the system.
If monthly net cash benefit is zero or negative, there is no positive simple payback under those assumptions.
Test what can overturn the decision
The useful question is whether the case survives realistic changes in its weakest assumptions.
Holding every other input constant, changing the exception rate gives:
| Exception rate | Net capacity released monthly | Monthly net cash benefit | Simple payback |
|---|---|---|---|
| 10% | 100.67 hours | $1,210 | 4.96 months |
| 20% | 90.67 hours | $1,060 | 5.66 months |
| 35% | 75.67 hours | $835 | 7.19 months |
These are alternative scenarios, not forecasts. In practice, higher exception rates may also mean longer handling times and more maintenance. Test those together when they are linked.
The cash-conversion assumption is equally consequential. If none of the released time changes spending, the model has no cash benefit and still incurs the $300 monthly software bill. A capacity or service case may remain, but it must stand on its own evidence.
Under the base assumptions, roughly 29.4% of the $2,720 monthly capacity value must become cash benefits to cover the $6,000 implementation cost and $3,600 software cost over twelve operating months.
That gives the budget owner a specific question: can the organisation credibly realise at least $800 per month in cash benefits?
HM Treasury's Green Book recommends sensitivity analysis and identifying assumptions that could change an investment decision. It is UK public-sector appraisal guidance; the private-business example here is netlinkE's illustrative analysis, not a Green Book assessment or certification. HM Treasury: The Green Book 2026
Run a pilot that can validate the estimate
Define the pilot's scope and acceptance rules before starting it. Compare the same business outcome and quality standard before and after automation.
Track distinct completed cases, staff intervention minutes, exception causes, maintenance time, operating spend and the benefit actually realised. Include a high-demand period or difficult case type if it materially affects the estimate. Pilot length should follow the evidence needed.
A technical success counter is insufficient when a request can be marked complete while its business record is wrong. Inspect a sample of completed outcomes and investigate failed and reopened cases.
Microsoft's automation-center documentation describes separate views for flow runs, errors, queue performance and savings. That supports using several measures together; it does not verify a particular business's savings or replace checking its records. Microsoft: Automation center
Assign a named owner to each benefit. If the case depends on reducing overtime, verify that reduction with the person responsible for the budget. If the benefit is faster service, measure service performance rather than converting it into invented cash.
Make the next investment decision
Proceed with a bounded implementation when the baseline is credible, exceptions are accounted for, the intended benefit can be realised and the downside case remains acceptable for the organisation.
Improve the process first when missing information, unclear ownership or inconsistent rules dominate the work. Keep the model provisional when the result depends on an untested volume assumption or on released time that has no identified use.
Before requesting an automation proposal, prepare a small evidence pack: the current workflow, representative cases, handling times, exception causes, expected costs and the person accountable for the benefit.
Request an Architecture Assessment if you need help deciding which workflow deserves investment and what must be true before implementation. Bring the operating problem and baseline assumptions; exclude confidential customer records.
Sources and methodology
This article presents an original illustrative calculation and practical decision guidance. It uses no client results, market pricing claims or industry-average savings percentages. Inputs should be replaced with measured local data.
Microsoft documentation supports the descriptions of savings rules and monitoring capabilities. HM Treasury provides external context for sensitivity analysis. Neither source supplies or endorses the numerical example. The article's archive sequence date is 1 May 2026; source verification and actual publication are recorded separately.
