KodDeltaGuides

How do you measure the return on a software investment?

~9 min read

Return on a software investment is only trustworthy if you measured the starting point. KodDelta asks for three baseline numbers before any build: hours spent on the task, the rate of rework, and the elapsed time from start to finish. Measure them for two weeks, then measure the same three after go-live.

Every software proposal contains a return argument, and most cannot be checked. This page is about the checkable version: which numbers to write down before you start, how to collect them, and which of the resulting gains are genuinely cash.

The two formulas, and why they are the easy part

FigureHow it is calculatedWhat it tells you
Net annual gain Labour saved + rework avoided + margin gained − annual maintenance The recurring benefit, after the cost of keeping the system running
Payback period Build cost ÷ (net annual gain ÷ 12) How many months until the build has paid for itself
Annual ROI (Net annual gain ÷ build cost) × 100 The recurring return as a percentage of what you spent once

None of this is difficult arithmetic. The difficulty is the inputs. A payback figure is exactly as trustworthy as the measurement of the process before it changed, and most companies have never made that measurement.

The three numbers to baseline

  • Hours. How long the task takes, per person, per week — not the estimate people give in a meeting, but the number they write down while doing it.
  • Rework. How many transactions a month are corrected, returned or re-entered, and what one of them costs to resolve, counting everyone who touches it plus any freight, scrap or credit note.
  • Elapsed time. How long a case takes from arrival to completion. An order needing eleven minutes of work but four days of waiting has a waiting problem, and waiting is what customers experience.

These three cover almost every genuine benefit a workflow system produces. If a claimed gain does not show up in one of them, be suspicious of it.

How to collect the baseline in two weeks

  1. Pick one process, not the company

    Choose the single workflow the project will replace first. Measuring everything produces nothing.

  2. Give each person one sheet and one question

    "How many minutes today on this task?" recorded at the end of each day for ten working days. Anything more elaborate will not be filled in.

  3. Count rework from records you already have

    Credit notes, return authorisations, corrected invoices and re-sent shipments are already in your accounting package. Pull three months and take a monthly average.

  4. Timestamp twenty real cases, and fix your hourly rate

    Note when each of twenty recent transactions arrived and completed; the median is your elapsed time. Then set the loaded hourly wage once — gross salary plus employer contributions divided by actual working hours — and use it in every calculation afterwards.

Two weeks of this makes every later claim arguable in a way a supplier's slide never will be. The full method for costing manual work is in the hidden cost of manual work.

Which gains are cash, and which are only capacity

This distinction decides whether your finance team believes the case.

GainCash or capacity?Condition for it to be cash
Fewer hours on data entryCapacity by defaultBecomes cash if overtime stops, a temp contract ends or a vacancy is not refilled
Fewer corrections and returnsCashFreight, scrap and credit notes are already real spend
Cancelled software subscriptionsCashOnly once the contract is actually terminated, not at renewal intent
Faster quote turnaroundCapacity, sometimes revenueCash only if you can show win rate or order volume moved
Lower stock buffersWorking capitalMeasurable directly from average inventory value
Better visibility for managementNeitherReal, but do not put a number on it

A case that puts every saved hour straight into the cash column will be challenged in the first review meeting, and rightly. Separating the columns is what makes the rest of the numbers credible.

A worked example, with its assumptions on the table

A distributor re-enters dealer orders by hand. Three staff spend five hours a week each on it, and about forty orders a month need correcting afterwards.

LineAssumptionAnnual effect
Build costDealer ordering module, one-off$12,000
Baseline hours15 hrs/week at $15 loaded$11,700 of paid time
Hours after go-liveFalls to 4 hrs/week for exceptions$8,580 released
Corrections40/month falls to 8, at $25 each to resolve$9,600 avoided
Maintenance18% tier on a $12,000 build− $2,160
Net annual gainSum of the above$16,020
Payback$12,000 ÷ $1,335 per monthAbout 9 months

The correction saving is cash immediately. The $8,580 of released hours is capacity until those three people are doing something the business can point to, or until the overtime stops. Presented that way the case survives scrutiny; presented as "$16,020 saved", it does not.

When and how to measure after go-live

  • Month one is provisional. People are still learning the screens and old habits run in parallel. Record it, but do not report it as the result.
  • Month three is the real reading. Repeat the same two-week measurement, with the same people and the same sheet.
  • Compare like periods. Same season, same working days, comparable volume. If volume changed, express the result per transaction.
  • Keep the baseline document. A year later nobody remembers what the process cost before, and without it the improvement becomes an anecdote.

Three ways software business cases go wrong

  • No baseline at all. Without a before there is no after, and the project ends up judged on how people feel about it.
  • Everything at once, measured at the end. A twelve-month build with a single go-live delays any evidence for a year. One working module in weeks 4 to 6 lets the first measurement happen while the rest is still a decision — which is why the vendor questions ask when software first runs.
  • Counting a gain the system cannot cause. A workflow system does not raise your prices or find new customers. Claim the hours, the rework and the cycle time; leave the rest out and the numbers you do claim will be believed.

If you want help defining the baseline before committing to anything, describe the process on the quote form. The build bands the arithmetic runs against are on the pricing page, and the five-year view of the same decision is in custom versus off-the-shelf.

Frequently asked questions

What is the formula for software ROI and payback period?

Annual ROI equals net annual gain divided by build cost, times one hundred, where net annual gain is labour saved plus rework avoided plus margin gained minus annual maintenance. Payback in months equals build cost divided by net monthly gain. Both are useless without a measured baseline.

Which three numbers should be baselined before the build?

Hours: how long the task takes, per person, per week. Rework: how many transactions are corrected or re-entered per month and what one correction costs. Elapsed time: how long a case takes from arrival to completion. Collect all three for two full weeks before anyone writes code.

Do saved hours count as cash savings?

Only if you stop paying for them. Saved hours become cash when overtime falls, a temporary contract ends or a vacancy goes unfilled. Otherwise they are capacity, which belongs in a different line of the business case. Presenting capacity as cash is how software business cases lose credibility.

How long should you wait before measuring results?

Take the first reading a month after go-live and treat it as provisional, because the early weeks include learning. Take the real reading at three months, over a period comparable to the baseline: same season, same working days, same product mix.

What is a realistic payback period for an operational module?

For a focused module replacing daily repetitive work, payback commonly falls between a few months and a year, but the honest answer comes out of your own baseline. KodDelta does not publish a single headline figure, because the result depends on how much manual work the current process contains.

What should make you distrust a supplier's ROI claim?

A percentage offered before anyone has measured your process. If a supplier can quote an efficiency gain without knowing your hours, error rate or cycle time, the figure came from a slide rather than your business. Ask instead which three numbers they intend to measure, and when.

Let's talk about what you need.

The 30-minute discovery call is free and carries no commitment.