Building one customer record across sales, service and marketing

A single customer view is an identity-resolution problem, not a screen-design problem. Consolidating sales, service and marketing into one record fails when teams start with the interface and discover, months in, that nobody agreed which system wins when two records disagree.

Why the same customer exists seven times

Duplicate records are rarely caused by carelessness. They are produced by the ordinary operation of systems that were each correct in isolation:

• Different natural keys. Sales identifies an account by company name, support by email domain, billing by tax registration. All three are legitimate; none matches the others reliably.
• Different granularity. Marketing tracks individuals, sales tracks accounts, support tracks entitlements attached to contracts. A “customer” is a different object in each.
• Time. Companies rename, merge, get acquired and change domains. A record correct in 2021 silently stops matching in 2026.
• Free-text entry. Every variation of a company name that a human can type will eventually be typed.

This matters because it tells you consolidation is continuous, not a one-off migration. A deduplication project with an end date produces a clean dataset that starts degrading the day it finishes.

Deterministic before probabilistic

Matching splits into two approaches, and the order you apply them matters:

• Deterministic matching uses exact agreement on a reliable key — tax registration, verified email, a customer number issued by you. It is unambiguous and auditable. Where a strong key exists, use it and stop.
• Probabilistic matching scores similarity across several weaker attributes: normalised company name, address, domain, phone. It catches what deterministic matching misses, and it will produce false merges.

The critical design decision is what happens in the middle band where the score is suggestive but not conclusive. Automatic merging there is how two genuinely different customers become one record — and an incorrect merge is materially harder to undo than a missed one, because the histories interleave. The safe default is to auto-merge only on high confidence, queue the middle band for human review, and never auto-merge on name similarity alone.

Survivorship: deciding which value wins

Once two records are the same customer, their fields still disagree. Survivorship rules decide the surviving value, and they should be explicit per field rather than system-of-record-wins across the board:

• Most recently updated suits volatile attributes like phone or job title.
• Most trusted source suits fields where one system is authoritative — billing owns the legal entity name; support does not.
• Never overwrite with empty is the rule most often missed. A sync that treats a blank field as an update silently erases good data, and the loss is invisible until someone needs it.

Write these down before building anything. In practice a workshop that forces sales, service and finance to agree which system owns which field surfaces more real problems than any amount of tooling.

The timeline is where the value actually shows up

A unified record is often sold as a profile screen. The part people use daily is the merged timeline: proposal sent, ticket resolved, campaign engaged, usage changed, invoice overdue — in one sequence.

That is genuinely useful because it answers questions no single system can. Whether a renewal conversation is walking into an open support escalation. Whether the champion has gone quiet. Whether usage started declining before the complaint arrived. Each of those requires events from different systems ordered together.

It also imposes a constraint: events need a consistent timestamp basis and a stable reference to the merged identity, so a later re-merge does not orphan history. Rebuilding a timeline after an identity change is expensive; designing for it is not.

Consent belongs to the record

Under the GDPR and comparable regimes, consolidating customer data raises an obligation rather than removing one. Marketing consent captured for one purpose does not automatically extend to another, and merging two records must not silently upgrade the more permissive consent onto both.

Consent state should therefore be a first-class field on the record, with its own survivorship rule — and the safe rule is the restrictive one, not the recent one. It should carry its source and timestamp, because a consent you cannot evidence is a consent you do not have.

Governance that auditors accept

A single record concentrates data, which concentrates risk. Three controls make that defensible: role-based access so teams see what their role requires; field-level permissions so sensitive commercial or personal fields are not visible estate-wide simply because the record is; and a complete audit trail of reads and writes on those fields.

This is also where consolidation projects tend to stall late — a data-protection review arrives after the build and finds that everyone can see everything. It is far cheaper as a design input than as a remediation.

Sequencing that works

The order that avoids the common failure:

• Agree the customer definition — account, individual, or both, and how they relate.
• Identify the strongest available key, and improve it before matching on weak ones.
• Write survivorship rules per field, with the owning team in the room.
• Run matching in report-only mode first, and review the middle band by hand.
• Merge in stages, keeping the pre-merge state recoverable.
• Only then build the timeline and the screens.

Teams that invert this — screens first, matching later — usually ship something that looks right in a demo and produces arguments in production, because the disagreements were never resolved, only hidden behind a layout.