Insight · 5 November 2026 · 5 min read
Origin Growth sets out how to measure transformation benefits
Supplier claims and economic forecasts can support a case for investment, but they cannot prove what an organisation will gain. We set out how to measure benefits against the services, costs and outcomes that matter.
NHS England is reportedly seeking clearance of Palantir’s FDP benefit claims, according to Digital Health’s report of 4 November 2026. For Origin Growth, that puts an important question squarely on the agenda: what evidence should an organisation require before treating a transformation benefit as real?
The scale of the opportunity is also attracting attention. ABC Money’s report of 5 November 2026 attributes a forecast of more than 10% additional UK GDP by 2031 from wider technology adoption to the British Chambers of Commerce. That is an economy-wide estimate, not an organisation’s business case. We welcome ambition, but our view is straightforward: investment decisions need evidence from the service being changed, with someone accountable for delivering the result.
We recommend starting with a service problem, not a platform capability. Define what needs to improve: the time taken to complete an application, the effort needed to resolve an enquiry, or the proportion of requests completed correctly first time. Then establish how that service performs today, before setting a target for tomorrow.
The baseline should cover the whole journey. If a request passes from a website into a CRM and then to an operations team, measure that journey rather than declaring success when the online form is submitted. Include waiting, handovers, repeat contact and rework. Otherwise, the proposed improvement may simply move effort somewhere less visible.
For each measure, record its definition, data source, reporting period and known limitations. Agree which cases belong in the calculation and how exceptions will be handled. A completion-time measure needs a consistent start and finish; a cost measure needs a consistent boundary. This is unglamorous work. It is also what makes later comparisons credible.
Choose a baseline period that reflects the service’s operating conditions, including relevant seasonal peaks. Where the existing data is incomplete, mark the gap and plan to close it rather than presenting an assumption as an observation. We would rather see a modest, defensible baseline than a precise-looking number nobody can explain.
Treat adoption as a condition for the benefit, not the benefit itself. Giving people access, delivering training and counting logins can help explain implementation progress. None should be accepted on its own as proof that a service has improved.
Define the behaviour the investment depends on. For an internal platform, that might mean staff completing the intended workflow without maintaining a parallel spreadsheet. For a customer-facing service, it might mean eligible users completing their task without avoidable assistance. These are measures to specify for the service in question, not universal targets.
We recommend tracking:
Keep the denominator visible. A high completion rate among a small group of confident users should not stand in for adoption across everyone the service is intended to support. Break results down by relevant user group, location or task where that helps explain the experience, using only the data needed for the decision.
When adoption falls short, investigate the journey before demanding more training. Review confusing steps, missing information and operational constraints. Our service design-led approach puts those questions alongside the technology, so the response addresses the barrier rather than merely encouraging people to click more often.
We recommend measuring cost per successfully completed service outcome, rather than cost per interaction alone. A cheaper interaction is not necessarily a cheaper service if the user has to repeat it or someone must repair the result. Set the unit of measurement before comparing the old and new approaches.
Build the cost boundary explicitly. Include the relevant platform, implementation, integration, support and operating costs, alongside staff effort. Account for training, change activity and any period of running old and new processes together. Finance and operations should agree which costs belong in the calculation and which remain outside it.
Separate cash savings from released capacity. If a process takes less staff time, record that improvement, but do not automatically describe it as money available to spend elsewhere. Specify whether the organisation intends to reduce expenditure, absorb additional demand or redirect effort towards other work. Each can be valuable; they are different benefits.
Give each benefit a single entry in the benefits register, with any dependencies clearly noted. Do not count the same reduction in handling time once as productivity, again as lower cost to serve and a third time as a financial saving. Show how the measures relate.
Finally, make the uncertainty visible. Use a range where costs or adoption remain unsettled, and identify the assumptions that would change the investment decision. A business case should be something leaders can challenge and update, not a number polished until it looks inevitable.
Every proposed benefit should have a named business owner who can influence the operating changes needed to deliver it. The delivery team can implement a platform and provide measurement, but responsibility for service performance should sit with the person accountable for that service. Assign someone to maintain the evidence, too; ownership without reliable reporting is incomplete.
Use a compact benefit record:
Pair efficiency measures with service outcomes. For example, a proposed reduction in handling time should be reviewed alongside completion quality, repeat contact and user effort. Decide in advance which outcomes must not deteriorate. Faster is only better if the service still does what people need it to do.
Agree how the organisation will test whether the change contributed to the result. Where practical, use a phased rollout or comparable group, and record other changes that could affect performance. A simple before-and-after comparison can inform a review, but we would not treat it as conclusive without examining demand, staffing and other relevant conditions.
At each review, distinguish observed results from forecasts and assumptions, then choose whether to expand, adjust, pause or stop. Our team’s role is to help connect service research, platform delivery and optimisation to that decision. Contact Origin Growth to discuss a measurement approach that gives the next investment a clear route from intended value to evidenced improvement.
