A manufacturing client once asked us to build a dashboard that pulled live data from four systems into one screen. Good idea. We built it. Six months later, roughly a dozen people had it bookmarked and almost nobody opened it more than once a week, because the decisions it supported were still being made in a Monday morning meeting off a printed spreadsheet. The software worked perfectly. The transformation didn't happen, because nothing about how the business actually decided things had changed.
That gap — between a system that functions and a system that changes outcomes — is where most digital transformation ROI goes to die. Not in bad code. In unmeasured assumptions. This article is about closing that gap: how to define the return before you spend, how to measure it honestly while the work is in flight, and how to spot the initiatives that should be killed rather than scaled.
Start by naming the number you're trying to move
"Digital transformation" is not an outcome. It is a category of spending. Before anything is scoped, someone senior needs to be able to finish this sentence in plain language: "If this works, X will go up or down by roughly Y, and we will know by Z."
If nobody can finish that sentence, the project has no ROI — it has a hope. In our experience, the numbers worth attaching to a transformation programme are almost always one of five kinds:
- Cycle time — how long a unit of work takes end to end (quote to cash, application to approval, order to dispatch).
- Cost per transaction — the fully loaded cost of processing one order, claim, invoice, ticket or onboarding.
- Capacity without headcount — how much more volume the same team can absorb before you hire.
- Revenue conversion — the percentage of qualified opportunities that close, or the percentage of users who complete a paid action.
- Error and rework rate — how often work has to be redone, and what that redo costs.
Notice what is not on that list: adoption rate, logins, story points delivered, "single source of truth", cloud migration percentage. Those are activity measures. They are useful for managing a project, and they are worthless as justification for one. A team can hit 100% adoption of a tool that saves nobody any time.
Measure the baseline before you build, not after
The single most common reason companies can't prove ROI is that they never recorded what "before" looked like. Once the new system is live, the old numbers are gone, and everyone falls back on anecdote: "it feels faster."
Baselining doesn't need to be a research project. Two to four weeks of deliberate observation usually gets you close enough to be useful:
- Pick the single process the initiative touches most directly. One, not five.
- Time it. Have people log start and finish timestamps for twenty to fifty real instances, or pull them from whatever system already stamps them.
- Count the handoffs and the rework. How many people touch it? How often does it come back?
- Price the time. Use fully loaded hourly cost, not salary. It is usually 1.3–1.5x base.
- Write it down somewhere permanent and dated. A shared doc is fine. What matters is that it exists in six months when someone asks whether this worked.
You will be surprised how often the baselining exercise alone changes the plan. We have had scoping conversations where a client came in wanting a custom platform and left having realised the bottleneck was one approval step that required a director's signature for amounts under a trivial threshold. Changing a policy is cheaper than shipping software. If we can tell you that in week two, we have earned our fee.
Distinguish the four kinds of return — they behave differently
Not all ROI is the same shape, and treating it as one blended number is how boards get misled. We find it useful to separate:
Hard savings
Costs that actually leave the P&L. A retired licence. A decommissioned server. A third-party processing fee you no longer pay. These are the only savings a CFO will fully believe, and they are the rarest.
Recovered capacity
Hours given back to people who stay employed. Real, but only monetised if that capacity gets redirected to something valuable — or if it lets you absorb growth without hiring. Say so explicitly. "We saved 400 hours a year" means nothing unless you can name what those hours now do.
Revenue effects
Faster quoting, better follow-up, fewer dropped leads, higher conversion. The upside is usually the largest of the four and the hardest to attribute, because sales outcomes have many parents. Use holdout groups or staged rollouts where you can — one region on the new process, one on the old, same quarter.
Risk and optionality
Reduced compliance exposure, less key-person dependency, the ability to launch a new product line in weeks instead of quarters. Genuinely valuable and genuinely hard to quantify. Don't fake a number here. Describe the scenario you are buying insurance against, and let leadership price it.
Fund in tranches, and give yourself permission to stop
The economics of transformation are brutal for one reason: most of the spend is committed before any of the learning arrives. Multi-year programmes with a single approval gate at the start are structurally designed to keep funding things that aren't working, because stopping looks like failure.
A pattern that works better, and the one we push for on longer engagements:
- Tranche one — 4 to 8 weeks. Baseline the process, prove the integration is possible, ship something thin to real users. Deliverable: an evidence-based revised estimate, not a demo.
- Tranche two — a single workflow, end to end, for one team or one region. Deliverable: a measured before-and-after on the number you named at the start.
- Tranche three onwards — scale what the measurement justified, and only that.
Each tranche has an explicit kill criterion agreed in advance. Something like: if median cycle time hasn't moved by at least 15% for the pilot team by the end of tranche two, we stop and reconsider rather than roll out. Writing that down when everyone is optimistic is far easier than negotiating it when everyone is defensive.
Where ROI actually leaks
After enough of these projects you start to see the same few holes. Almost none of them are technical.
- Parallel processes. The new system is live and the old spreadsheet is still being maintained "just in case". You now have two costs and one benefit. Set a hard cutover date and honour it.
- Data nobody trusts. If the numbers in the tool disagree with the numbers people already believe, they will ignore the tool. Reconciliation work is unglamorous and it is where adoption is won.
- Training treated as an event. A two-hour session at go-live is not enablement. Budget for someone embedded with the team for the first few weeks who can answer questions in the moment.
- No owner after handover. The best-instrumented system decays within a year if nobody is accountable for the metric it was built to move.
- Scope that grows to match the budget. Every additional feature dilutes the return per rupee or dollar spent. The discipline is not building everything you could — it is building the twenty percent that carries the number.
- Automating a process nobody should be doing. The fastest way to do the wrong thing is to automate it. Ask whether the step should exist before making it efficient.
Where AI changes the maths — and where it doesn't
We do a lot of AI and machine learning work, so we'll be blunt about this: AI shifts the ROI calculation in a specific and narrow way. It makes economic sense where a task is high-volume, judgement-light-but-not-rule-based, and tolerant of a known error rate — document extraction, classification, triage, drafting, retrieval over messy internal knowledge. In those places the return can be large and fast.
It makes poor economic sense where volume is low, where every output must be exactly right, or where the underlying data is thin or inconsistent. A model trained on three hundred badly labelled records will produce confident nonsense, and cleaning that data costs more than most people budget for. Two questions we ask before recommending an ML approach:
- What is the cost of a wrong answer, and who catches it? If the answer is "expensive" and "nobody", the human stays in the loop and the savings shrink accordingly.
- Could a set of deterministic rules get 80% of the way there? Frequently, yes — and rules are cheaper to build, cheaper to explain, and cheaper to maintain.
Same logic applies to tooling generally. Sometimes the right answer to a sales visibility problem is a focused product like Orbis Lead CRM rather than a custom build. Sometimes the right answer is an embedded team that becomes your internal capability over time, so you're not buying transformation as a one-off event. And sometimes it's a spreadsheet, honestly maintained.
A simple scorecard you can run every quarter
Keep it to one page per initiative. Four rows:
- The named metric, with its dated baseline and its current value.
- Spend to date against spend forecast, and what changed in the forecast.
- One thing we learned this quarter that we did not know last quarter.
- Continue, adjust, or stop — with a reason.
The third row is the one people skip and the one that matters most. A programme that learns nothing new in three months is not transforming anything; it is executing a plan written by people who knew less than you do now.
If you are partway into a programme and can't answer what number it's moving, that's a solvable problem, and usually a short conversation. Have a look at some of the work we've done, and if it would help to talk through your own baseline, scope or kill criteria, get in touch. We're happy to tell you when the honest answer is to build less.
