Case study: the customers we couldn't see

The insurer didn't have a customer problem. It had a recognition problem. A customer with car insurance never heard about home cover, let alone pet insurance, because the business couldn't tell it was the same person, or the same family. Its happiest customers were invisible to it.

What it was costing

The insurer held a huge amount of customer data, full of duplicates. Without one trusted view of each customer and their household, it couldn't market the right product to the right person, and it felt it was losing its own customers to competitors. The bigger loss wasn't the revenue walking out of the door. It was the revenue it could have earned from people who were already happy with it.

Part of something bigger

The single customer view wasn't a standalone project. It was a core service of a new shared digital platform, built once so that many parts of the business could reuse it: for marketing, for customer surveys, and for understanding how the business itself was performing.

Choosing the engine

We evaluated two leading MDM products and an open-source option. In the end, the insurer's existing relationship with one of the vendors sealed the deal. That taught me something early: on a programme like this, the tool matters less than people expect. The hard parts are the data and the people.

Who to trust

Before arguing about matching algorithms, we had to agree which system we trusted. That turned out to be one of the easiest decisions of the programme. The policy system kept the best-quality customer data, and the business agreed straight away, so it became the trusted source for the golden record. We standardised addresses against Royal Mail's address file before trying any clever matching.

The decision that shaped everything

The MDM product was good at matching and searching, but it wouldn't let us customise it the way the business needed. So we made a choice that shaped the whole architecture: we would never expose MDM to the people who used the data.

Instead, we built our own orchestration layer and a consumer data store on top of it. MDM did the matching, merging and householding behind the scenes; our services wrote the single customer view into that store; and every consumer reached it only through APIs and events. Marketing in the MarTech platform, next-best-action decisions, surveys and performance reporting all used our layer, never the engine.

Hiding the engine gave us two things. We could customise freely, because the logic consumers depended on was ours. And we could upgrade or even replace the MDM engine later without breaking a single consumer.

How the data moved

Around that core, each source and consumer got the integration pattern that suited it. Third-party data providers enriched the data through a daily batch feed and an on-demand service. Every change to a customer was published as an XML event, so subscribing systems knew straight away instead of polling. Digital channels and next-best-action decisions queried customers in real time through API services built around the consumer data store. Batch ETL loaded the data lake for analytics and the MarTech platform for marketing. And the data stewards worked in MDM's own screens, resurfaced for their review queue.

The hardest call: when to merge

Most of our arguments were about auto-merging and survivorship. Merge two different people by mistake and you damage both records, and both customers' experience. So the business, not IT, led the decision on where to draw the line, with us advising.

We went live cautious: only matches scoring about 90 or more merged automatically, and everything below went to a small team of data stewards, who reviewed the queue and sampled what the system merged on its own. The thinking was simple. The more you analyse the data, the more comfortable you become with it, so you relax the threshold as confidence grows, not on day one.

You can try the same trade-off yourself in my MDM playground: move the threshold and watch customers merge, or fail to.

What it made possible

• One trusted view of every customer and their household, with matching rates 21% better after tuning, cleansing and clearer survivorship rules.
• Marketing could finally target a car customer with home or pet cover, and next-best-action decisions had a real customer to work from.
• Surveys and performance reporting used the same customer, not three versions of them.
• Six projects reused the shared platform instead of building their own, and the steering committee named it one of the key reasons the programme succeeded.

What I'd do differently today

I'd add graph-based matching alongside the scoring rules. Relationships (a shared address, a shared phone, a shared policy) say a lot about whether two records are the same person or the same household, and a graph makes them easy to see and explain. I've since built that approach in my own labs.

What I'd tell another leader

• Start from the business loss, not the data mess. "We can't see our own customers" gets funded; "we have duplicates" doesn't.
• Agree which system you trust before you argue about algorithms.
• Keep the product behind your own interface. Consumers should depend on your APIs and events, not on a vendor's engine.
• Let the business own the merge threshold, start high, and relax it as the data earns trust.

The goal of a single customer view isn't clean data. It's recognising the people who already trust you.