An automation proposal should explain where value is expected to come from, what it will cost to obtain and which assumptions could change the result. ROI is one useful measure, provided everyone uses the same formula and time horizon.
The calculation is a forecast until benefits are observed. A positive result in a spreadsheet does not establish that the project is safe or that released working time will become a cash saving.
Use an explicit ROI convention
In this article, the initial investment is included in the numerator:
ROI = (Benefits over the period − Operating costs over the period − Initial investment) / Initial investment × 100%.
For a one-year view, use one year of benefits and operating costs. For a three-year view, use three years. State whether the figures are cash flows, accounting amounts or an economic valuation of capacity, and avoid mixing them without explanation.
This convention differs from dividing annual net operating benefits by the initial investment. That ratio can be useful, but calling both calculations “ROI” without explaining the difference makes proposals hard to compare.
Another convention divides net benefit by all costs incurred during the period, as in the business process automation guide. The denominators differ. Recalculate on the same basis before comparing results from the two conventions.
Payback period
If net monthly benefits are constant and start immediately:
Simple payback in months = Initial investment / Net monthly benefit.
Where benefits ramp up, vary seasonally or arrive at irregular intervals, calculate cumulative cash flows instead. Simple payback ignores the time value of money and value after the payback point. NPV and IRR provide additional views of a project’s cash flows.
Establish the current process
Measure volume, active working time, waiting, error rates and the resources involved. Use a representative period and record unusual peaks or exceptions.
An employee’s estimate can be a starting point, but compare it with observations or records where possible. Time between two system events is not necessarily time spent working. Process mining and activity-based costing can help answer different parts of that question.
Agree the baseline before making changes. Otherwise, an increase in volume or a separate policy change may be incorrectly credited to the automation.
Include the full cost of the change
Initial costs can include process analysis, configuration or development, integrations, data preparation, testing, migration, training and internal project time.
Ongoing costs can include software licences, infrastructure, model or API usage, monitoring, support, data review and updates when connected systems change. Include the cost of handling exceptions rather than assuming the process becomes entirely unattended.
Also assess recovery from failures, additional security controls, future migration and any overlapping systems during transition. There is no universal ratio between a licence price and implementation cost. Use a scoped estimate and the current commercial terms of the tools being considered.
Separate the kinds of benefit
Cash savings
A benefit is a cash saving when expenditure actually falls, such as avoided paid overtime, a reduced external processing bill or a justified avoided hire. Confirm that the change can be realised operationally.
Released capacity
Time saved by salaried staff may allow more work, better service or fewer delays while payroll remains unchanged. That capacity can be valuable, but describe how it will be used and keep it distinct from a cash-flow claim.
For example, a hypothetical task taking 30 minutes, performed 200 times a month, represents 100 hours. Removing 85% of that active work releases 85 hours. At an assumed economic value of PLN 80 an hour, the capacity is valued at PLN 6,800. It is not automatically a PLN 6,800 reduction in spending.
Fewer errors
Estimate the cost of relevant errors and how the change could affect their frequency. Avoid counting the same correction time both as labour savings and as a separate error benefit.
Revenue and retention
Additional revenue is not the same as profit or cash available to repay an investment. Use an appropriate contribution margin, account for delivery costs and assess whether the automation caused the change.
Customer lifetime value represents an estimate over a future relationship. Counting the whole amount as a monthly cash benefit overstates short-term payback.
Risk and service improvements
Faster service, traceability and reduced operational risk may justify investment even when precise cash benefits are uncertain. Present them separately or use clearly explained scenarios. Applying an arbitrary discount to a speculative number does not make it reliable.
Hypothetical example: invoice processing
The following figures illustrate the formula. They are not a QA10 case study, quotation, tool price list or expected outcome.
Assume an initial investment of PLN 32,000, measurable monthly benefits of PLN 6,360 and ongoing monthly costs of PLN 2,350. For this cash-flow example, assume the benefits can actually be realised in money, do not overlap and start immediately.
| Calculation | Result |
|---|---|
| Net monthly benefit | PLN 6,360 − PLN 2,350 = PLN 4,010 |
| Net operating benefit in year one | PLN 4,010 × 12 = PLN 48,120 |
| Year-one ROI | (PLN 48,120 − PLN 32,000) / PLN 32,000 = 50.4% |
| Simple payback | PLN 32,000 / PLN 4,010 ≈ 8 months |
| Three-year ROI, assuming unchanged monthly flows | (PLN 144,360 − PLN 32,000) / PLN 32,000 = 351.1% |
If part of the PLN 6,360 is only a valuation of released capacity, produce a separate cash-flow calculation. If deployment takes time or benefits ramp up, the first-year result and payback will change.
The example excludes tax, financing and discounting. A real investment decision may need those factors and a longer operating-cost forecast.
Hypothetical example: customer onboarding
Assume an initial investment of PLN 85,000, monthly benefits of PLN 13,000 and ongoing costs of PLN 5,500. Again, these are illustrative assumptions. For the calculation, the benefits are assumed to be realised in money, rather than simply multiplying saved staff hours by a salary rate.
- Net monthly benefit: PLN 13,000 − PLN 5,500 = PLN 7,500.
- Net operating benefit in year one: PLN 7,500 × 12 = PLN 90,000.
- Year-one ROI: (PLN 90,000 − PLN 85,000) / PLN 85,000 = 5.9%.
- Simple payback: PLN 85,000 / PLN 7,500 ≈ 11.3 months.
No assumed lifetime value, referral growth or churn reduction is added to this example. Those effects would need their own evidence, timing and contribution calculation. Including them without that work would make the forecast appear more certain than it is.
Test the assumptions
Build scenarios around identifiable uncertainties: transaction volume, adoption, exception handling, benefit ramp-up, licence costs and maintenance effort. Explain why the selected values are plausible.
Check sensitivity to the assumptions that drive the result. If a small change in volume makes the project unattractive, investigate volume before committing. Do not label a project “safe” simply because an arbitrary pessimistic scenario remains positive.
Use a decision threshold that reflects the organisation’s funding cost, risk, alternatives and strategic needs. There is no universal rule that every automation must produce 100% ROI in its first year.
When to change or postpone the plan
A low-volume task may not justify a large integration, but it could still benefit from a simpler solution. An unstable process may need redesign before automation. A high-value, infrequent process may justify support tools even where its final decisions remain human.
Pause when benefits cannot be measured credibly, required data are unavailable or operating ownership is unresolved. Compare the proposal with alternatives, including doing less, improving the process manually or using an existing tool.
After deployment, compare observed performance with the baseline and forecast. Review at intervals suited to the process and when material conditions change. Rising costs or falling volume can alter the business case even after the initial investment has been recovered.
Discuss your process
Q-Journey can help examine a process and identify a suitable next step. AiP is part of Q-Journey, with Express and Platinum options; Platinum also includes Lean and Muda consulting. The audit scope, evidence to collect and subsequent software work are agreed individually.
Q-Dev provides custom software delivery where the scope is established. Project costs and dates depend on that scope. Book a 30-minute conversation to discuss the process and the assumptions behind your business case.
FAQ
Is ROI from automation always positive?
No. Benefits may be lower than expected, costs may rise or the process may change. A forecast should make assumptions explicit and be checked against observed results after deployment.
Can saved employee time be included?
Yes, if its treatment is clear. Released capacity can be valued economically, but it is not automatically a cash saving. Explain how the time will be used and distinguish that value from reduced spending.
Can customer satisfaction be converted directly into ROI?
Not without evidence connecting it to an incremental financial effect. Treat satisfaction as a separate outcome unless there is a defensible model for its impact, timing and costs. Do not count all customer lifetime value as immediate cash.
Do small automations need a detailed financial model?
The analysis should be proportionate to cost and risk. A small, reversible change may need only a brief estimate, while a larger or consequential workflow needs a fuller assessment. Even small changes require clear ownership and appropriate safeguards.
How often should ROI be reviewed?
Use review points that fit the process, benefit ramp-up and investment decision. Compare actual costs and benefits with the forecast and reassess after material changes in volume, software, staffing or operating rules.