Software and Automation ROI. How to Build a Business Case

Quick answer

A business case for software or automation does not start with a savings estimate. It starts with the measured cost of the current process, the one number anybody can check against timesheets rather than against the vendor's deck. Then it separates the time and cost the solution can affect from the work that will remain regardless. Only then does it compare the benefit with one-time and recurring TCO over 12, 24, and 36 months. In that order.

This method does not guarantee ROI. It gives decision-makers one model in which they can inspect the source of every number, so the argument moves from whether we believe the estimate to where the figure came from. You can use our calculator for the current-process inputs. Its result is not a promise of savings.

Measure the cost of the current state

Start with one specific flow. It may be order intake, document checking, or report preparation. Measure affected people, manual hours per person per week, total hourly cost, working weeks, monthly errors, rework. Total hourly cost is not salary alone. It includes employer cost and directly attributable operating cost under your accounting method, because the salary line alone prices an hour that nobody in finance recognises as real.

Eurostat explains that labour cost is broader than wages, and its hourly labour-cost source helps define the input. It does not set your company hourly rate.

C = people × weekly manual hours × hourly cost × working weeks + monthly rework × 12

C is the annual cost of the current process. It is a measured input when it comes from time records, payroll data, and rework records. If time is not yet measured, mark it as an assumption, and set the date on which you will confirm it, because this one line quietly rewrites the whole model.

Set the addressable share and adoption

Automation rarely removes an entire process. Work may remain for exceptions, approval, or quality control. Addressable share states how much of C the solution can affect technically and operationally. Adoption states how much of that share is actually used in the chosen horizon, and it is the number that disappoints even when the software works exactly as specified.

B = C × addressable share × adoption

B is the modelled annual gross benefit. Addressable share and adoption are assumptions until a pilot or operating data confirms them. Do not replace them with a generic percentage from someone else's study, which measured a different process, at a different firm, on volumes nothing like yours.

Record full TCO

One-time TCO includes discovery, design, development, integrations, migration, testing, deployment, training and the time your own staff spend on it. Recurring TCO includes hosting, licences, monitoring, support, security patches, operational changes, and process-owner work, which is the line that rarely gets its own row in the budget. Those categories differ for custom software, AI automation, and software modernization. Do not estimate them with one rate.

The UK Green Book calls for documented assumptions and sensitivity analysis, which in practice means every figure can be traced back to whoever put it there. Its appraisal guidance is not Rise pricing. It explains why each input needs an owner and a source.

B(H) = B × H / 12
TCO(H) = one-time TCO + recurring monthly TCO × H
ROI(H) = (B(H) - TCO(H)) / TCO(H) × 100
Payback = one-time TCO / (B / 12 - recurring monthly TCO)

H is 12, 24 or 36 months, whichever horizon the decision actually covers. Payback applies only when its denominator is positive. If monthly benefit does not cover recurring TCO, there is no payback, and the scenario becomes your stop signal rather than something to negotiate down with the vendor.

Use conservative, base, and upside inputs

Do not use invented multipliers, and change only the inputs whose reason you can state out loud, because otherwise three scenarios are three versions of the same guess. A conservative case may use a smaller addressable share, slower adoption, or higher recurring cost. The base case should use the best current evidence. An upside case may use a pilot result. It may not use a marketing promise.

Run sensitivity one variable at a time. Show what happens with lower adoption, higher TCO, or an addressable share that turns out smaller. Set stop criteria before work starts. For example, stop after a pilot if the minimum case volume is not confirmed, if net monthly benefit remains negative, or if the critical integration has no safe operating path.

Keep non-financial risks separate. Security, legality, data quality, supplier dependency and the impact on customers all matter. Do not assign them a euro value without evidence, because the number nobody can defend does more damage than the open question it replaced. Record the risk owner, the control and the decision it can trigger.

A hypothetical example with explicit assumptions

All inputs in this example are hypothetical. It describes neither a Rise.sk measurement nor a client result. Assume five people, five manual hours per person per week, a €35 total hourly cost and 46 working weeks. Rework is excluded from this calculation, which does not establish that an actual firm has none. The resulting annual cost is €40,250.

The team assumes a 60% addressable share with 70% adoption after launch. B is €16,905 per year. One-time TCO is €18,000, recurring TCO €350 per month. At 12 months that means €22,200 of TCO against an ROI of about -23.9%, at 24 months €26,400 against 28.1%, at 36 months €30,600 against 65.7%. Payback lands at about 17 months.

The example does not say your project will have this outcome. It shows how chosen inputs enter the formulas. For your own project, distinguish actual measurements from assumptions.

Create internal consensus

Before approval, confirm the following.

• The process owner confirmed the measurement boundary and exceptions.
• Finance confirmed hourly cost and TCO categories.
• Operations confirmed the adoption condition and pilot measurement method.
• Security or the accountable person confirmed open non-financial risks.
• The sponsor approved the minimum result, stop criteria, and date of the next decision.

The model has limits. It does not capture unverified revenue growth, future process change, or value you cannot reasonably measure. If inputs need work, compare them with our pricing, read further decision guides, then book the short consultation block, where we walk the numbers through with you. The next step is to confirm inputs. It is not to defend a project somebody already picked.