MELLORCATalk to Mellorca
Patterns

Data Integrity

Why Does One Customer Exist Differently in Three Systems?

A Pattern examining data silos and identity resolution failures that cause customer records to diverge across platforms, with actionable normalization strategies.

Mellorca Patterns2026-10-01

Observable condition

Across CRM, billing and support systems, a single customer profile often diverges in identifiers, contact details or history. In the CRM the customer is a company with a new head office address. In the billing system the same company still has the old address and a different account number. In the support tool the customer appears twice, once under the parent company and once under a trading name.

Frontline teams encounter conflicting data, questions about ownership and inconsistent interactions that undermine trust and hinder cross-sell opportunities. A salesperson preparing for a renewal cannot see an open complaint. A support agent cannot tell whether the caller's contract covers the issue. Finance chases an invoice that the customer believes was settled under a different account.

Realisation

When data ownership is fragmented, customers experience episodic interactions rather than a continuous relationship. This results in duplicated outreach, misapplied entitlements and incorrect service histories that complicate upsell and renewal.

The deeper realisation is that the business is not one view of the customer with a few errors. It is several separate views, each internally consistent, none authoritative. Every team believes its own system is right, and in a narrow sense each may be. The problem only becomes visible where those views meet: at a renewal, an escalation, a credit decision or a report that tries to answer "how much is this customer worth to us?"

For customers who are individuals, there is also a legal dimension. The UK GDPR accuracy principle, explained in the ICO's guidance on accuracy, requires personal data to be accurate and, where necessary, kept up to date, with reasonable steps taken to erase or rectify inaccurate data without delay. Correcting an address in one system while the old one persists in two others makes that harder to demonstrate.

Identification

Identification centres on identity resolution gaps: keys that cannot be matched across systems, inconsistent matching rules and missing golden records. The consequence is multiple "versions" of the same customer that no single team signs off as authoritative.

This is a customer master data and identity resolution problem.

  • The visible symptom: conflicting addresses, duplicate accounts and histories that do not line up.
  • The common assumption: people are entering data carelessly.
  • The structural cause: no agreed authority for customer identity, and no reliable mechanism to carry changes from that authority to every system that depends on it.

A closely related Pattern, Why Does the Same Customer Have Three Different Names in Your Systems?, focuses on naming. This Pattern is concerned with the wider record: identifiers, relationships, contact details and history.

Diagnosis

The mechanism is a blend of siloed data models, weak master data governance and insufficient event-driven synchronisation to update every system when a single data point changes. As a result, downstream processes react to stale or conflicting identifiers.

IBM describes data silos as isolated collections of data that prevent sharing between departments, systems and business units, leaving teams with outdated, fragmented or inconsistent data and a partial view on which to base decisions. Customer records are among the most exposed, because almost every system needs some version of them.

Divergence typically arises from a recognisable set of causes:

  • Each system was implemented separately. Billing, CRM and support were bought at different times, each with its own customer model and identifier.
  • Different definitions of "customer". Sales thinks in accounts and contacts, finance in billing entities, support in users or sites. None of these is wrong, but the relationships between them are rarely defined.
  • Creation happens in several places. New customers can be created in more than one system, so duplicates are likely from day one.
  • Changes do not propagate. An update in one system is copied manually, by a nightly file or not at all.
  • Nobody owns the record. There is no data steward with authority to decide which version is correct and to merge duplicates.

IBM's description of master data management frames the response: consolidating critical data into a "golden record" that integrates data from various sources, identifying and resolving duplicates, and relying on data stewardship to decide how master data is structured and related.

Commercial impact

The value wrapper is revenue, cost, customer experience and risk.

Operational costs rise as teams spend time reconciling records, re-keying changes and investigating discrepancies. Revenue opportunities weaken when campaigns target the wrong contact, when cross-sell is missed because product holdings are split across duplicates, or when renewals are approached without knowledge of an unresolved problem. Customer experience suffers when support histories do not align with current purchases or preferences, and when customers have to correct the same detail more than once.

Reporting is affected too. Customer counts, lifetime value and profitability analysis all depend on knowing which records represent the same customer. The Impact article on duplication of customer data entry explores the day-to-day cost of maintaining several versions by hand.

Common misidentification

The usual response is a clean-up exercise: a project to deduplicate and correct records. Clean-ups help, but if creation and update rules stay the same, the records drift apart again. Another common response is to declare one system the master without changing how other systems receive updates, which produces an authority in name only.

Possibility

The possibility lies in establishing a canonical identity, applying consistent identity resolution, and coordinating changes across systems through events or controlled integration. This enables consistent customer views and smoother cross-functional workflows.

In a stronger state, each customer has one authoritative identifier that every system can reference. Customers are created in one controlled place. Changes to core attributes are made once and flow outwards. Each system may still hold data specific to its function, but it links to the shared identity rather than inventing its own.

Intervention

Interventions include a master customer profile, deterministic matching rules and policy-driven synchronisation. Build lightweight identity services that surface authoritative identifiers and propagate updates with minimal delay.

  1. Define "customer". Agree how accounts, billing entities, contacts and sites relate to each other.
  2. Decide the system of record for each attribute. Legal name and billing address may belong to finance; contacts and relationships to the CRM. The Insight How to Decide What Should Be the System of Record covers this choice.
  3. Control creation. Restrict where new customers can be created and check for existing matches first.
  4. Set matching rules. Use deterministic rules on reliable identifiers, with human review for uncertain matches.
  5. Propagate changes. Replace manual re-keying and nightly files with integration that carries changes as they happen.
  6. Assign stewardship. Give a named person or team authority to resolve conflicts and merge duplicates.

Practical diagnostic

Warning signs that customer identity has fragmented:

  • Staff keep spreadsheets that map account numbers between systems.
  • Customers report updating their details but still receive post or invoices at the old address.
  • The same customer appears more than once in a single system.
  • Customer counts differ between sales, finance and support reports.
  • Teams argue about which system holds the "real" record.
  • Changes are copied between systems by hand or by periodic file transfer.

Questions to ask

  • Which system holds the canonical customer record today?
  • How often do profile changes fail to propagate to all systems?
  • Are there policy-driven rules for matching and merging identities?
  • In how many places can a new customer be created?
  • Who has authority to decide which version of a record is correct?

Bottom line

Unified customer identity is foundational to effective engagement. When one customer exists differently in three systems, every team works from a partial truth. Aligning identity, ownership and synchronisation gives the business a single customer to serve, report on and grow.

Sources and further reading

Related Mellorca reading

Article summaryA Pattern examining data silos and identity resolution failures that cause customer records to diverge across platforms, with actionable normalization strategies.
Explore our solutionsStart a conversation