Sarah's husband passed away three months ago. When she called her motor insurer to remove him from the policy, the conversation was difficult, but the agent was understanding. They noted her bereavement, updated the system, and assured her they were there to support her.

Six weeks later, her home insurance renewal arrives. It's addressed to both. When she calls to update it, she must explain everything again. The home team has no record of what she shared. Different system. Different team. Same company.

For Sarah, this isn't a technical failure; it's a moment where her insurer proved they don't really see her at all.

This scenario isn't hypothetical. It's happening across the industry, and under FCA Consumer Duty, it's now a regulatory breach. But the real issue runs deeper than compliance. It reveals how insurance has been fundamentally architected: around policies, not people.

For customers, every interaction with their insurance provider feels like one company. From shopping for cover, filing a claim, or calling support for advice, they expect a seamless and consistent experience at every step.

However, behind the scenes, many insurers still operate in silos. Separate systems, P&Ls, and disconnected journeys means customer data is scattered across legacy platforms, teams, and channels. This makes it difficult to build a complete view of the customer and deliver a smooth customer experience.

For many years, this policy-centric model made sense operationally. But it no longer aligns with how customers expect to be understood and supported. And these expectations are only getting higher. Digital-first industries have set a new standard for speed and hyper-personalisation. Customers expect their insurers to support them at every step, especially the vulnerable ones.

The future of insurance means shifting from policies to people. Creating a Single Customer View (SCV) is an essential step to delivering personalised, seamless experiences at scale.

The Customer Cost of Siloed Systems

What started as a compliance project revealed something more fundamental. The challenge wasn’t just about tracking vulnerable customers; it was that the entire business was structured in a way that made it impossible to see customers as whole people.

Sarah’s experience with the misaddressed renewal letter wasn’t an edge case. It was a symptom of how insurance has been built around product lines, not people. And once you start looking for the pattern, you see it everywhere.

Consider the customer who already holds home insurance with you but visits a price comparison website to shop for motor cover. Your pricing engine treats them as a stranger. The opportunity to retain them with a multi-product discount never surfaces because your acquisition systems don’t talk to the policy administration systems across lines. By the time someone in retention realises they’re shopping around, they’ve already bound elsewhere.

Or the claims handler dealing with a home insurance claim who has no visibility that this same customer just filed a motor claim two weeks ago. Two claims in quick succession might indicate a pattern worth understanding, but without a single view, each claim is handled in isolation. The opportunity to proactively support the customer, or flag other behaviours worth investigating, simply don’t exist.

The fragmentation isn’t just a revenue measure; it’s a compliance risk that extends beyond Consumer Duty. When a customer exercises their Right to be Forgotten, can you confidently identify every system that holds their data? When they submit a Subject Access Request, are you certain you’ve found everything? When they update their marketing preferences with one team, does that cascade correctly across all brands, or are different systems holding different consent states, leaving you exposed under GDPR and PECR?

These aren’t hypothetical scenarios. They’re playing out daily across the industry. The same architectural problem that made “Tell Us Once” difficult for vulnerability data makes everything else harder: cross-sell, retention, compliance, operational efficiency, customer experience.

The vulnerability requirement was the canary in the coal mine. The real issue is that organisations have spent decades optimising around policies while customers have always experienced them as one company. The misalignment creates friction at every touchpoint and in an industry where trust is the product, friction is expensive.

Building the Foundations for Customer Hyper-Personalisation

When our compliance project was completed, the immediate win was clear: Sarah's bereavement would now be visible across all brands and teams. If she called about any policy, the agent would know. The renewal letter would be addressed correctly. “Tell Us Once” meant once.

That immediate win revealed something bigger. Once the single view is in place, the opportunities compound quickly.

Retention becomes predictive when the customer visits a Price Comparison Website, you have a source to correlate them as an existing customer with a policy and claims history. Your pricing engine can make an informed decision: retain them with a loyalty discount, or risk losing a profitable relationship. Retention isn’t looking for signal after the fact; the system catches in real-time.

Cross-sell stops being guesswork. When a customer calls about home insurance, you know they don’t have motor cover with you, but you also know they have two vehicles registered at the address and they’ve been shopping for motor quotes. The conversation can be genuinely helpful rather than scattergun. The claims handle spotting two claims in quick succession can proactively reach out to offer support, not just process paperwork in isolation.

This is where the foundation starts to unlock for the future. With a single, accurate view of each customer, hyper-personalisation switches from an aspiration to reality.

Predictive analytics can identify churn risk before the customer starts shopping because they’re trained on behavioural data, not fragmented policy records. Dynamic pricing can factor lifetime value, cross-product holdings, and vulnerability indicators to make genuinely personalised offers. AI agents can orchestrate proactive outreach with the right message, at the right time, through the right channel because they have access to complete context about consent, preferences, communication history, and current needs.

Digital journeys become contextual. A customer midway through a renewal doesn’t have to re-enter information you already hold. A mid-term adjustment can suggest relevant add-ons based on known coverage gaps, not generic upsells. Product explanations can be generated on the fly, tailored to the customer’s comprehension, language preferences, and prior interactions.

These capabilities exist, but the architecture to support them is missing. You can’t personalise what you can’t see. You can’t predict churn if you don’t know the customer holds three products with you. Your Agent can’t choose the right communication channel if consent data is scattered across multiple systems.

Winning in the next few years won’t be about sophisticated AI models; it’ll be about the data foundations that make those models useful.

The Challenges of a Single Customer View

Most insurers already have some form of customer matching in place, typically built for marketing purposes. The logic is often quite forgiving: if two records are probably the same person, merge them for consent management. If you get it wrong, someone receives a marketing e-mail they shouldn’t or doesn’t receive one they should. Annoying, but not catastrophic.

Building a Single Customer View for operational purposes requires a fundamentally different level of rigour. When you’re associating vulnerability records, claims history, or cross-product holdings to a customer, the stakes are higher. Get it wrong and you’ve breached Consumer Duty, exposed yourself to GDPR violations, or made business decisions based on incomplete information.

The matching problem is more complex than it appears, reconciling data from systems built over decades, each with their own quirks and constraints. Some legacy systems store age rather than date of birth, making precise matching impossible. Address data varies when customers move house or declared different addresses across policies. Contact records proliferate, some systems support joint policy holders, titles have evolved – newer systems hold Mx as an option where older ones haven’t caught up.

All of this becomes layered in change over time, a customer may have presented in the past before they were married, moved house, or changed name. Or maybe they just entered their details incorrectly this time, or last time. Who knows?

The data quality challenge extends beyond matching. Legacy systems, designed in the 1980s and 1990s, hold assumptions that are no longer true. Systems that assume everyone has a surname. Systems built for batch processing that barely support nightly extracts, let alone real-time APIs for surfacing customer data to contact centres or digital channels.

When one insurer began building its SCV, the contact centre teams themselves flagged that the existing marketing matching logic wasn't robust enough. They understood intuitively what the business case hadn't fully articulated: operational decisions require operational-grade data.

This doesn't mean it's impossible. It means it requires investment, expertise, and realistic expectations about what "good enough" looks like at each stage. You don't need perfect matching on day one, but you do need to understand the difference between marketing-grade and operational-grade accuracy and build toward the latter deliberately.

Building a Single Customer View

Building a Single Customer View isn't a binary choice between doing it quickly or doing it perfectly. It's about navigating a set of fundamental trade-offs that will shape both what you build and how much value it delivers.

Good Enough vs Perfect

Perfect customer matching is a mirage. There will always be edge cases: the customer who moved house between policies, the person who changed their name, the joint account holder whose details appear inconsistently across systems. Chasing 100% accuracy means you'll never ship.

But "good enough" must be defined deliberately. Marketing-grade matching, where false positives just mean someone gets the wrong email, isn't robust enough for operational decisions about vulnerability, claims, or cross-sell. You need to build toward operational-grade accuracy: high enough confidence to make business decisions, with clear thresholds for when human review is required.

This means investing in matching logic upfront, not treating it as a future enhancement. It means defining what "confident enough" looks like for your risk appetite and use cases. And it means building feedback loops, when contact centre agents or customers themselves flag incorrect matches, that intelligence feeds back into improving the algorithm over time.

Single Use Case vs Boiling the Ocean

The temptation is to solve every customer data problem at once. Don't. Start with a forcing function, for many in this industry, that will be a regulatory requirement. Prove you can solve that problem well.

But architect for expansion from day one. If your MVP only solves vulnerability tracking, you've built a niche tool. If your MVP solves vulnerability but demonstrates how the same foundation enables retention, fraud detection, and cross-sell, you've built a platform.

This is where the business case either stalls or accelerates. A Single Customer View that unlocks one use case struggles to justify ongoing investment. A Single Customer View that proves its value across multiple domains, even if those additional use cases aren't fully built yet, becomes self-evidently strategic.

The key is designing the matching engine and data architecture to be use-case agnostic, then layering specific applications on top. Vulnerability first, but with pricing, product, and fraud in the roadmap from the start.

IT Project vs Business Capability

This isn't just data plumbing. The hardest decisions are about what your business is willing to accept.

What's your threshold for match confidence before you trust a cross-sell recommendation? When do you merge customer records vs keep them separate? How do you handle conflicts when different systems have different versions of the truth? These aren't questions for the data team to answer in isolation.

Involve frontline teams early. Contact centre agents and claims handlers will tell you whether matching logic is robust enough for real-world decisions. They'll surface edge cases you hadn't considered. And they'll be your advocates when it works, because they're the ones who feel the pain of fragmentation.

Build governance around the golden record. Someone needs to own the rules for how conflicts are resolved, how match thresholds are set, and how exceptions are handled. Without that ownership, your SCV becomes another siloed system that nobody quite trusts.

Start with Regulation, Design for Value

Consumer Duty might be the forcing function, but don't let compliance be the ceiling. Use the regulatory requirement to secure investment, then architect for the business capabilities that make the investment worthwhile.

The insurers who succeed aren't the ones who build the most sophisticated matching algorithm. They're the ones who find the balance between fast enough and accurate enough to unlock value across the business and who build the organisational muscle to improve over time.

This is specialist work. It sits at the intersection of data engineering, business process, and risk management. It requires practitioners who understand both the technical complexity and the commercial trade-offs. Done well, it's the foundation that makes everything from retention, cross-sell, personalisation, to AI possible.

Shifting From Policy to People

Sarah's renewal letter arrives. It's addressed correctly. When she logs into her account, her vulnerability record is visible and up to date. The system knows she has home and motor insurance, but not contents cover and can offer it with thoughtful, personalised pricing based on her full relationship with the company. When she calls about a mid-term adjustment, the agent already has context. She doesn't have to repeat herself. She doesn't have to re-explain.

This is the immediate win. But it's also the foundation for something bigger.

The insurance industry is moving toward AI-driven personalisation not because it's fashionable, but because customer expectations demand it. The question isn't whether insurers will adopt predictive analytics, dynamic pricing, and agentic automation. The question is which insurers will be ready as these capabilities mature.

The ones who will be ready are those who've built intentionally. They've invested in operational-grade customer matching. They've unified data across silos. They've created the architectural foundation that makes AI useful rather than just impressive.

AI isn't magic, it is pattern recognition applied to data. If your data shows customers as fragmented policy records rather than whole people, your AI will optimise around policies. If your data reflects a single, accurate view of each customer their history, their context, their needs your AI can do what it's supposed to: make insurance more human.

Not from manual to automated. Not from reactive to predictive. From policies to people.

For decades, insurance has been organised around products because that's what made operational sense. But customers have never experienced you that way. They've always seen one company. One relationship. One expectation of being understood.

Building a Single Customer View isn't just about compliance or efficiency or even competitive advantage, though it delivers all three. It's about closing the gap between how your business is structured and how your customers experience you.

It's about making sure that when someone shares something difficult: a bereavement, a diagnosis, a crisis, they only have to say it once. And that every subsequent interaction reflects that you heard them.

That's what it means to put people at the centre. Not as a tagline, but as architecture.

 

For more information about Dot Collective, please visit their website.