An insurer can buy a modern core system and still be unable to answer a customer inside the time that customer is willing to wait. That is not a procurement failure. It is what happens when the budget goes into replacing systems of record while the thing that decides the customer's experience sits above those systems, between them and the channels people actually arrive through.
A European composite insurance group ran a capability assessment across its private lines to find out where it stood against the digital business it had said it wanted. Twenty-two capabilities were scored on five dimensions, and each one was read three ways: where it stands today, where the programmes already committed will carry it, and where the strategy needs it to be. Then the middle reading was subtracted from the last one. Ten capabilities survived that subtraction, meaning ten need action beyond everything already funded and staffed.
The challenge
The subtraction is the whole method, and it is the part most capability reviews skip. Scoring where you are against where you want to be produces a gap on almost everything, which is another way of producing nothing. Scoring where your committed programmes will take you, and only then measuring the distance left, produces a shorter list and a harder conversation, because every item on it is work nobody has budgeted.
The banding was published rather than judged: under one point of remaining difference on the five-level scale counted as no gap or a small one, one to two points as medium, above two as large. The ten that made the shortlist grouped three under the customer dimension, two under operations, one under new digital services, two under technology and two under people. Two of the ten priority gaps were behavioural, scored on the same ladder as the systems.
The operations pair is where the argument lives. One of them, a configurable product architecture, is the capability the funded portfolio helps most: the migration already under way is expected to produce the largest single step change anywhere in the set, which puts it in the top band of the published scale, above two points. The other, straight-through processing, is the capability that same portfolio helps least, which puts it in the bottom band, under half a point.
The reason is stated plainly in the assessment and it is worth quoting in substance. Despite heavy investment in a new core platform, many transactions were still being processed by batch-oriented legacy systems, which blocks real-time handling of a customer request. The migration is real and it does raise maturity where it lands, but it reaches the value chains it covers and no further. Its planned effect on straight-through processing stops at 2.9. The default aspiration for every capability was 4, and the strategy singled out a handful for 5 on the grounds that cost and consolidation depend on them. Straight-through processing is in that handful. So the best case, once every funded programme has landed, leaves 2.1 points on the capability that determines whether a claim or a policy change can complete without a person touching it, which is a large gap on the assessment's own banding rather than a medium one.
Read that picture once and the sequencing question answers itself. Front-end work that lands on a thin span is work that will disappoint. The assessment made the same point from the other direction: mobile applications and self-service portals could not raise maturity any further without back-office integration, so the apps kept arriving and the maturity did not move. Every one of those apps is a channel wired directly into a batch system, which is the brittle join the whole shortlist is really about.
The approach
The recommendation was not another replacement programme. It was to put an orchestration layer over the legacy estate and use it to extend straight-through processing into the parts of the estate the migration will not reach. Workflow and business rules on top, the old systems underneath, exposed as callable steps rather than as overnight batches.
That is a smaller commitment than it sounds and a larger one than it looks. Smaller, because it does not require the legacy chains to be retired on any particular schedule, which is why it can start now. Larger, because a layer is only as good as what the systems beneath it will let it call, and the oldest chains have the fewest real-time interfaces to call.
This is where an assessment turns into something we sell. Deciding to orchestrate rather than replace is a two-hour decision. Discovering which parts of the estate can be called, in what order, with what compensation when a step fails, is a build. The Platform work we do starts there, with an inventory of what each system of record can expose and what it costs to make it expose more, because a layer specified without that inventory is a diagram.
The customer-side items on the shortlist have the same shape. Inconsistency across channels was traced to one root cause, the absence of a single view of the customer across those channels, which makes it an integration question rather than a front-end one. Moving profiles beyond transactional records to behavioural ones hit the same wall: the online behaviour data sat outside, hosted by someone else, unjoined to what the group already knew about the same person offline.
Three preconditions were named ahead of all of it, deliberately. Senior stakeholders did not share the same level of ambition, particularly on customer focus and on new services, so the roadmap would have been built on an unresolved disagreement. Whether the group wanted one customer view across its distribution businesses was still an open strategic question, not a technical one. And the existing development process and control points could not deliver inside the three to six month cycle the market was already running at. None of the three is solved by an architecture decision.
The outcome
What this engagement produced was a pilot close-out: a scored baseline, a shortlist of ten, a set of proposed actions labelled as hypotheses, and a phased follow-up to validate them and build an integrated roadmap. Those actions were explicitly to be validated and priced on a business case before anyone committed to them. No orchestration layer was built in this phase. The numbers here are scores and plans, not outcomes, and several sub-scores rest on as few as two survey responses.
The honest question is what would be done differently if the same assessment ran today. Three things.
The grid was drawn by hand, from surveys and interviews, and a hand-drawn grid stops being true the moment the portfolio under it moves. Straight-through processing is the least defensible capability to survey, because it is directly measurable. The share of policy changes completing without a human touch, the share of claims settling inside the automated path, the queue depth in front of each batch window: all of it is already in the logs. Process mining over the workflow events gives the same score with a source attached, refreshed as often as anyone wants it.
The orchestration layer is also where machine learning actually reaches production. A pricing or acceptance model that can only run in an overnight batch cannot change what a customer sees in the moment they ask. The same layer that carries a straight-through process is the layer that calls a model, records the features it saw and writes the decision to a lineage trail an auditor can follow later. Deciding orchestration and deciding model deployment are one decision, taken twice by two different committees in most insurers we work with.
And the current wave of cautious language-model pilots in document handling changes none of the arithmetic above. A model that reads a claim form well still needs somewhere to put the answer. Where the span is thin, the answer lands in a person's queue and the automation is a demonstration. Our Consult engagements now start by measuring that landing point, because it is the cheapest way to tell an interesting pilot from a programme that will pay.
The capability that gains least from everything already funded is the one that decides how everything else feels to a customer. That is not a scheduling accident. It is what happens when replacement programmes are the only instrument an organisation has.