Most infrastructure is justified by the thing it was built for and remembered for the thing it turned out to enable. A group funds an integration layer because reporting is slow, and some time later that layer is the only place in the estate where a customer exists as one person rather than four unrelated records. Nobody wrote that on the business case. Nobody knew to.
A large European cooperative banking group built one of these earlier than most, and for an ordinary reason. Its customer insight function had been asked how insight drawn from process data actually improves the way the group serves people, and could not answer without admitting something structural. No system in the estate covered a whole customer journey, so the evidence for any question worth asking sat across systems never designed to be read together.
The challenge
The function started by drawing the journey rather than the architecture. Seven stages, end to end: orientation, advice, quote, purchase, service and maintenance, claim notification, claim settlement. Under each stage went the touchpoints, and under those the customer's need written as something measurable rather than as a sentiment. Apply quickly and through any channel. View, change or cancel without effort. The claim paid within a week of filing, and a call back inside the same week. Those are thresholds, and a threshold can be missed and counted.
Then it overlaid the systems of record on the same picture, and the seams appeared. Website and social data carried orientation and marketing. The group's insurance business held the quote, the policy and the claim. The customer relationship system held advice, telephone contact and service. Four sources for one journey, none covering more than a fragment, one of them in a different entity altogether. Every question of consequence crossed at least one seam.
The seam map also settles what kind of problem a single customer view is. It is decided where records join, not on the screen the customer sees, which makes it an integration property rather than a front-end one. Four sources meant four partial customers, and nothing done at the front end would have merged them.
The approach
The answer was a hub, and the wording of the claim mattered more than the diagram. It was to be the group's data collection point, singular and designated, not one warehouse among several with a federation story attached later. Website, social, insurer and customer relationship data all landed in it. What came out was raw, deliberately: refinement was assigned to people rather than to a pipeline, with data scientists turning raw data into analysable data. And on the same page as the integration claim, in the same size of type, sat a line insisting that data privacy was essential. Not an appendix, not a later workstream. Same page.
One ordering choice is worth taking away. The seam map came before the hub, so integration was scoped by where the journey broke, not by what a vendor could connect.
What the hub then made possible was never on its business case. Because all four sources sat in one place, a journey could be traced as a moving path rather than counted as a funnel snapshot, and every path sorted into one of four behaviours: the intended one, completion by an unintended route, ricocheting between steps or channels, and leaving without completing. The last two look identical in a funnel report and need opposite fixes.
The readings that followed were only available to something holding the whole journey. Across 248 sales opportunities, 62.9 per cent completed within eight days and 49 of them, 19.8 per cent, ran past fourteen. The distribution dips at days four and five and rebounds to its highest block at days six to eight, which is the signature of a cadence rather than of a process running continuously.
Ranked per local unit, the same measure spread wide. The norm line sat at 8.89 days. The slowest unit took 27.35. Thirty-eight of the eighty-five local units with usable data sat above that norm, and the excess summed across the network came to 177.6 days in this one process. That line is the group's own average, which is the quietly effective part of the method: nobody argues with their own average, and the gap to it is bookable on the day it is drawn.
The channel reading was harder. Average online handling share across the 138 local units recording any online volume was 34.2 per cent, eight of every ten of them between 28.7 and 41.0, and the best reached 60 per cent. A tight band under a hard ceiling is not a problem at the weak end. It is a proposition problem across the whole network, because the online route ran into the same ceiling wherever it was measured. One caveat belongs with those figures: the group's own chart does not close. Online and offline together average 48.6 per cent of volume across those same units, so 34.2 is a share of a partially covered base, not of everything. The direction holds; the denominator does not.
One join is worth more than either reading alone. The local unit slowest on throughput, at 27.35 days, also sat at 22 per cent online, ranked 132nd of the 146 units plotted. Speed and channel adoption were the same problem wearing two costumes: two budgets, two owners, one cause. Only something holding both readings at once could have shown that, and that is the hub's real return.
The outcome
What the hub delivered is a place where those readings could be taken. What followed were five named measures, split so both halves of the group's relevance filter were served: make the website carry a fast, simple application at higher conversion, catch the drop-out during the application rather than reporting it afterwards, steer response and throughput times proactively, let weaker local units learn from stronger ones, and strip superfluous clicking out of the customer relationship system. Those are measures, not results. The group recorded them as improvement opportunities, which is the honest reading of where this work stood.
The reason to write it up now is that the question in front of every institution has changed shape. The conversation is about copilots, retrieval-augmented generation over internal documents, vector stores, evaluation sets, and how carefully to scope a first autonomous experiment. Almost all of it is about what to build. The more useful question is what already exists, because retrieval is only as good as the corpus it reaches, and a copilot that sees one channel will confidently give advice the customer can contradict from another.
That is the whole argument. This group's hub was built to produce insight, and it is now the only place in the estate where a cross-channel view of a customer already exists. Data readiness is rarely a programme anyone funds on its own merits. It is usually something funded once for a duller reason that has been compounding ever since, and the privacy constraint attached at design time compounds with it, because a lineage trail is far cheaper to have kept than to reconstruct.
The first genuinely autonomous thing worth trying here is also the smallest, and this group named it years before the tooling existed. Catching a drop-out during an application is a bounded action against a stated threshold, with the threshold written on the journey map and the norm already drawn. That is an experiment that can be defended. Most of our Consult work now opens by finding the equivalent asset a client already owns, and the Platform work that follows extends it rather than duplicating it, because a second collection point is how a single view stops being single.
Infrastructure built for one purpose is often the thing that makes the next one possible. That is not luck. It is what happens when someone insists on one collection point at the exact moment it would have been easier to build a fifth.