One Customer, Twelve Systems: The 360° View Problem

Try this experiment at your carrier. Pick a real customer — someone who holds an auto policy, filed a home claim two years ago, and called the contact centre last month. Now ask a simple question: show me everything we know about this person.

At most insurers, that question takes days and a small committee. At some, it can't be answered at all.

This isn't a technology embarrassment. It's the single biggest constraint on everything the business wants to do next — cross-sell, retention, personalised pricing, AI of any kind.

How one person becomes four strangers

Insurance grew by product line, and the systems followed. Auto lives in one platform, property in another, life in a third. Billing has its own customer record. The CRM has another. The claims system has yet another, keyed differently again.

So "Rajesh Kumar, 42, Pune" exists as:

  • Customer A-88213 in the auto system (name spelled "Rajesh Kumar")
  • Insured P-4471 in property (name "R. Kumar", different address format)
  • Party 99120 in billing (matched only by email)
  • Contact c_5567 in the CRM (matched only by phone)

Four records. One human. Nothing joins them reliably, because there was never a reason to — each system was bought to run one product well, and it does.

What this quietly costs you

Cross-sell is guesswork. You can't offer the home policy to your best auto customer because you don't know they're the same person, or that they just bought a house.

Retention is reactive. A customer whose claim went badly last year cancels at renewal, and nobody connected the two events — the renewal team never saw the claim.

Risk is under-informed. Underwriting an auto policy without seeing that this person has two property claims and a lapse history is pricing with one eye closed.

Service feels stupid. The customer explains who they are to every department, every time. They notice. It's the thing they complain about most.

Every AI project stalls. This is the killer. Personalisation models, churn prediction, next-best-action, fraud graphs — every one of them assumes you can identify a person across your business. If you can't, the models are learning from fragments and their predictions are blind in exactly the places that matter.

Why "we'll build a data warehouse" doesn't fix it

Plenty of carriers have a warehouse. They still can't answer the question. Because copying four disconnected records into one database gives you four disconnected records in one database. Co-location isn't resolution.

The hard part was never storage. It's identity.

What actually solves it

1. Entity resolution, done properly. You need a process that decides — probabilistically, with rules you can inspect — that these four records are one person. Fuzzy name matching, address normalisation, phone/email signals, date of birth, household inference. It won't be perfect; it needs a confidence score and a review path for the ambiguous middle.

2. A stable customer key that survives. Once resolved, that identity needs a durable ID that persists as records change. If your key breaks when someone moves house or marries, you've built a snapshot, not an identity.

3. A golden record with provenance. When the four systems disagree on the address, one wins — and you must be able to say which source won and why. That's not pedantry; it's what makes the record trustworthy enough to act on, and what regulators will ask about.

4. Two-way flow, eventually. The resolved identity should feed back so the source systems get better over time, rather than the warehouse being a graveyard of reconciliations nobody upstream benefits from.

5. Governance from day one. The moment you unify a person's data across products, you've created a privacy-sensitive asset. Access controls, PII tagging, and consent tracking aren't optional add-ons — they're what makes the unified view legal to use.

Start narrow, not perfect

The instinct is a two-year "single customer view" programme. Don't. Pick two systems — usually auto and property, or policy and claims — and resolve identity between just those. Prove the match rate. Show one business team something they couldn't see before. That earns the next slice.

The carriers who get to a real customer 360 didn't do it by boiling the ocean. They did it by refusing to accept that "show me everything we know about this person" is a hard question.

It shouldn't be. It's your own data, about your own customer. The only reason it's hard is that nobody built the key.

We unify fragmented insurance data into governed, queryable platforms — including the entity resolution and customer keys that make it real. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Snowflake or Databricks for Insurers? An Honest Comparison

It's the question in every insurance data platform decision, and it generates more heat than insight: Snowflake or Databricks? Here's an honest answer from having migrated a lot of both. Short version: they're both excellent, the gap is narrower than either vendor implies, and the decision matters far less than what you do next. But there are real differences, and your workload should pick. Where each genuinely leads Snowflake is stronger when your centre of gravity is SQL analytics. Reporting, actuarial analysis, regulatory extracts, BI over structured policy and claims data. It's operationally calmer — less to tune, fewer knobs, and your existing SQL people are productive on day one. Separation of storage and compute means the finance team's month-end doesn't fight the actuaries' model run. For a carrier whose data is mostly relational and whose consumers are mostly analysts, it's the shorter path. Databricks is stronger when your centre of g...
Read more

What 200+ Cloud Migrations Taught Us About Insurance Data

Over 200 cloud migrations, patterns emerge. Not the ones in the vendor case studies — the ones you only see from inside, at 2am, when the reconciliation doesn't balance. Here's what we've actually learned about insurance data. Some of it is uncomfortable. 1. The estimate is always wrong in the same direction Every migration takes longer than planned, and almost never because of the technology. It's because of what you find: a rating rule nobody documented, a batch job that silently corrects bad data at 2am, a product variant that exists only in one state. The work isn't moving data. It's discovering what the old system actually does — which nobody knows in full, because the people who knew have retired. Budget for archaeology, not just engineering. 2. Every reconciliation mismatch is a gift When your new premium calculation disagrees with the legacy system by ₹40 on 300 policies, the instinct is to treat it as a bug to squash quickly. Don't. Tha...
Read more

From Mainframe to Lakehouse: How to Modernize a 30-Year-Old Policy System Without Downtime

Ask any insurance CTO what keeps them from modernizing, and you'll rarely hear "budget" or "talent." You'll hear something closer to fear: the policy administration system has been running since the 1990s, it processes every quote, endorsement, and renewal the company makes, nobody who wrote it still works there — and the business cannot go dark for even an afternoon. So the migration gets deferred. Another year passes. Meanwhile every AI initiative, every customer-experience project, and every analytics roadmap quietly starves, because they all need data that's trapped inside that system. Here's the thing: the fear is rational, but the conclusion isn't. Migrating a legacy policy core without downtime is well-trodden ground. It just requires abandoning the approach everyone instinctively reaches for. Why the big-bang cutover fails The instinct is to build the replacement, pick a weekend, flip the switch, and pray. This fails for a predict...
Read more