Try this at almost any established company. Pick a real customer — someone who bought product A, filed a support case, and called last month. Now ask a simple question:
Show me everything we know about this person.
At most organisations that 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 personalisation, retention, risk modelling, and basically every AI project downstream.
How one person becomes four strangers
Companies grow by product line, and systems follow. Product A lives in one platform, product B in another. Billing has its own customer record. The CRM has another. Support has a third, keyed differently again.
So "Rajesh Kumar, 42, Pune" exists as:
| System | Identifier | Name as stored | Join key available |
|---|---|---|---|
| Product A | A-88213 |
Rajesh Kumar | — |
| Product B | P-4471 |
R. Kumar | address (different format) |
| Billing | 99120 |
RAJESH KUMAR | |
| CRM | c_5567 |
Rajesh K. | phone |
Four records. One human. Nothing joins them reliably, because there was never a reason to — each system was bought to run one thing well, and it does.
Why a warehouse doesn't fix it
Plenty of teams have a warehouse and 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 records are one person. Signals:
- Normalised name (phonetic + edit distance, not exact match)
- Normalised address (a real address parser, not string equality)
- Email and phone, normalised
- Date of birth
- Household inference for shared addresses
Output a match score, not a boolean. Then:
score >= 0.95 -> auto-merge
0.80 - 0.95 -> human review queue
score < 0.80 -> keep separate
It won't be perfect. It needs a confidence band and a review path for the ambiguous middle. Any vendor promising 100% is describing a demo dataset.
2. A stable key that survives change
Once resolved, the identity needs a durable ID that persists as records change. If your key breaks when someone moves house or changes their name, you've built a snapshot, not an identity. This is the part people underestimate: the key must be stable across the very events that make people's records diverge.
3. A golden record with provenance
When 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 you'll need when someone challenges a decision made from it.
Store the winning value and the losing candidates with their sources.
4. Bidirectional flow, eventually
The resolved identity should feed back so source systems improve over time — otherwise the warehouse becomes 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 that didn't exist before. Access controls, PII tagging, and consent tracking aren't 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 the two with the most overlap — and resolve identity between just those. Measure the match rate. Show one team something they couldn't see before. That earns the next slice, and you learn your data's actual quirks on a small blast radius.
Why it matters more now
Every agentic/AI project assumes you can identify a person across your business. Recommendation, churn prediction, fraud graphs, next-best-action — all of them silently depend on it. Fed fragments, these models don't fail loudly; they produce confident recommendations about a person they can only half see.
The unglamorous customer key is the prerequisite that determines whether everything built on top of it works or quietly embarrasses you.
We build entity resolution and the unified data foundations behind it. More at IntelliBooks.
Top comments (0)