A transformation portfolio is easy to argue about while nobody has priced it. This one was priced. An international health insurance group set out six priorities for its operating model and wrote a value-at-stake figure beside each: £90M, £70M, £65M, £30M, £10M, and, against the sixth, the letters TBD. Two hundred and sixty-five million pounds of quantified ambition, plus one priority the group declined to guess at.
Enthusiasm reads that column from the top. It opens with the £90M, because £90M is the figure that survives a steering committee. The proposal written against this portfolio starts somewhere else: on the £30M priority, and on the one with no number at all.
The challenge
The six priorities are the group's own: automation and digital service, more value out of existing and new partnerships, a differentiated health management proposition, a reshaped distribution model, a defined global service model, and consolidation onto a single product system. Five carry a figure. One carries TBD.
Only one of the six is shown being built from its parts, and it is the £30M. It splits in two. £8M sits in digital and omni-channel service, where the benefit drivers are leads, conversion and renewal rates, and the diagnostic finding is blunt: service improvement had concentrated on the contact centres while the digital estate and self-service fell behind market standards, with interaction data captured at only a few points. The other £22M sits in automation of underwriting, claims and payment, where the drivers are a five percent reduction in average cost and a ten percent increase in claims processed per person, read against benchmark efficiency gains of fifteen to thirty percent across policy servicing and claims. The two halves sum to the priority. Nothing else in the portfolio is opened up like that.
The service-model priority carries TBD, and the pages behind it are not empty. The current issues are stated plainly: contact centres are sub-scale, supporting multiple stand-alone units in every region is uneconomic, and locally relevant service is an enabler of the regional growth plan rather than an overhead on it. The benefit driver is named too, a productivity gain from customer analytics and better tooling for service staff. So the value is not in doubt. What is missing is the decision that would size it, which is how many service hubs there should be, where they sit, and which model they run.
That decision has no default answer. A scan of how comparable international financial services organisations run customer service reaches a deliberately unhelpful conclusion: there is no single best practice. Some run country by country, some run regional hubs, some run a mix. What decides it is the business strategy, the geographic spread and the balance struck between customer experience and cost efficiency.
Put those two facts together and the TBD stops looking like a gap in the analysis. Any figure written into that cell before the design choice is made is a figure about a design nobody has picked. The honest cell is the one that says so.
The framing letter makes the same point in a sharper form. It names the big design decision the group should surface early: whether to organise the operating model around value chains, which is a cost emphasis, or around customer journeys, which is a service emphasis. That single choice moves the missing number more than any benchmark will.
The approach
The proposed work runs fourteen weeks across three stages of six, five and three weeks: scope the change, design the service model, capture the implications.
The first stage is an options exercise, and the question written into it is the one the portfolio is short of an answer to, which is what the value at stake and the indicative cost to deliver are in each priority area. Options get developed, then assessed in a working session against potential value and ease of implementation with sub-criteria under both, then cut to a short list with the operating-model consequences attached: what each option does to the product it sits under, the channels it is served through, the processes it runs on and the systems beneath them.
The second stage designs the thing the number depends on: how the organisation should be arranged to deliver the priority changes, what the contact strategy should be, how many hubs and where, which processes to standardise and harmonise, what enabling technology is required, and the indicative value, cost and delivery path for each. The third turns that into workstreams, phasing, dependency maps, a cost-benefit position per phase and the governance to run it. Twelve numbered deliverables come out, among them a to-be capability map with a gap analysis against the current state, a cost-benefit model for the options, an outline business case, and a roadmap with a transition plan.
The sequencing logic sits in a note written against the portfolio page: the two priorities in scope touch large parts of the operating model and carry many dependencies onto the other four. They go first because the other four cannot be sequenced honestly until these two settle. Value at stake ranks the portfolio. Dependency decides the order of work.
The outcome
This is a proposal, and it should be read as one. What exists is a bid document: a portfolio read, a diagnosis of the current estate, a three-stage plan with a week grid, an options method and a deliverable list. The £265M is the group's own estimate of value at stake, not benefit booked. The sixth figure was still TBD on the day the document was written, and the plan to close it had not been run.
The interesting thing about that TBD is what it implies about its five confident neighbours. All six were produced the same way: interviews, benchmarks, judgement, workshops, fixed to one date. Every one of them was as provisional as the unpriced one. Only one of them admitted it.
That is worth changing, because the drivers under each priority are already measurable. Cost per claim, claims processed per person, the straight-through rate on underwriting and payment steps, enquiry volume by type and channel, first-contact resolution, conversion and renewal by segment. Those numbers live in the claims platform, the policy system, the telephony records and the web logs. The work that makes them usable is unglamorous: definitions that mean the same thing in the claims view and the service view, pipelines that refresh them, lineage from the figure on the slide back to the record it came from. That is the plumbing the RealAI Platform is built to carry. Do it and value at stake stops being a workshop output and becomes a query anyone can re-run when the assumptions move.
The missing number closes the same way. Contact volumes by type, language and time zone are in the case and telephony records. Automation candidates show up as the repeated paths through claims and underwriting where nobody exercises judgement, which is exactly where process automation and, cautiously, early language-model support for enquiry handling and document-heavy steps belong, narrowly scoped and with a person on the output. Model several hub configurations against that data and the design decision gets priced instead of argued, which is how a TBD closes on evidence rather than on whoever speaks last in the room.
None of this makes the portfolio table obsolete. It makes it repeatable. Six priorities, six numbers, each with a source and a refresh date, is a different management instrument from six numbers agreed once and defended for a year. Our Consult work starts there, on the ranking rather than the enthusiasm, because the order in which a portfolio is attacked is the decision that quietly sets everything after it.
The most useful cell in that table had nothing in it. Keep the TBDs honest, and build the machinery that closes them.