Measuring automation ROI before you build
Estimate automation savings using a measured baseline, exception handling, review time and operating costs, with a worked example.
A process takes eight minutes, runs a thousand times a month and looks easy to automate. Multiplying those numbers gives 133 hours of monthly work. It does not tell you how much time an automation will recover.
Someone may still need to check the results. Unusual inputs may take longer to resolve than they do today. The person maintaining the integration will spend time on it too. Include that work before using the estimate to justify a build.
Measure a complete task
Choose a start and an end that the team can observe. For invoice intake, that might be receipt of the document through to a validated record ready for approval. Stopping the clock when extraction finishes would omit corrections and reconciliation.
Sample real work across different sources and input types. Record active handling time separately from elapsed time: an invoice waiting overnight for approval creates delay, but it does not consume eight hours of someone’s labour.
Include rejected inputs and corrections. If the team already spends time repairing bad records, record that time as part of the baseline rather than counting it again as an additional benefit later.
Work through the exceptions
The following example is hypothetical. It illustrates the arithmetic, not an expected result for an Apsan Works project.
Suppose a team handles 1,000 documents each month. Each takes eight minutes, including the current checks and corrections. The baseline is 8,000 minutes, or about 133.3 hours.
A trial clears 700 documents without human handling. The remaining 300 each need three minutes of review, giving 15 hours. A person also spends five hours a month checking samples and maintaining the workflow.
Residual work is therefore 20 hours. The estimated capacity recovered is 113.3 hours per month. This assumes the trial’s document mix and handling times remain representative. A supplier changing its format could change both.
At an assumed loaded labour cost of $30 per hour, that capacity has a planning value of about $3,400 a month. If recurring infrastructure and service costs are $400, the estimated monthly net benefit is $3,000. With a hypothetical $12,000 initial implementation cost, simple payback is four months.
Those figures deliberately leave out revenue growth and avoided errors. Neither should be added without evidence. The payback calculation also assumes stable volume and excludes financing, tax and the time value of money.
Capacity recovered is not necessarily money saved
If the same employees remain on the same payroll, the $3,400 is not an automatic reduction in expenditure. It is an estimate of capacity the team could use elsewhere.
Name what will happen to that capacity. It might absorb a growing workload, shorten a queue or let an employee spend more time on customer requests. A cash-saving claim needs a corresponding expenditure change. Keep that separate from an operational improvement whose value has not yet been priced.
Include the cost of recovery
Automation costs extend beyond successful runs. Count failed attempts, human investigation and any work required to reconcile partial completion.
For example, a payment request can time out after the provider has performed the operation. Retrying safely requires the receiving API’s documented idempotency behaviour; a local record alone cannot establish what happened remotely. Stripe’s documentation explains how a stable key supports retries within its API contract.
The implementation and operation of those controls belong in the project cost. Our article on idempotent automation covers the failure case in more detail.
Try the assumption that hurts the result most
Recalculate the example with only 500 documents cleared automatically. At three minutes each, the other 500 need 25 hours of review. Adding the same five hours of oversight leaves about 103.3 hours recovered. At the same assumed rates, net monthly benefit falls to $2,700 and simple payback rises to about 4.4 months.
Then try a slower review process, lower volume or additional maintenance. A useful trial measures the variables that could reverse the decision. For a document workflow, that means clearance rate, review time and errors found after clearance, measured together.
Write down the conditions under which the build should proceed. Keep the baseline and revisit the calculation after deployment using actual work records. If review effort or operating cost rises, the original estimate should be revised along with it.
