Observable condition
A single customer appears in several systems under several versions of a name. The CRM holds the trading name, the finance system holds the registered company name, and the support desk holds whatever the person typed into a web form. One record says “Ltd”, another says “Limited”, a third uses an abbreviation or a former name. Individuals fare no better: a maiden name in one place, a nickname in another, a misspelling in a third.
Each record looks reasonable on its own. The trouble only appears when somebody tries to answer a simple question across systems: how much has this customer bought, how many open issues do they have, and who last spoke to them?
Realisation
Identity fragmentation undermines trust in data, complicates customer interactions and leads to duplicated work across teams. Inconsistent identities cause misaligned messaging, duplicate records and the erosion of the single customer narrative that lifetime value analysis depends on.
The deeper realisation is that the business does not actually know who its customers are with the confidence it assumes. Reports that count customers may be counting records. A customer who complains to support while finance chases an overdue invoice may be treated as two unrelated relationships. Every downstream decision that depends on “the customer” inherits that uncertainty.
Identification
This is a data quality and identity resolution problem, often first noticed as a deduplication issue. It shows itself through mismatched contact details, inconsistent identifiers, and records that are supposedly synchronised but fail to merge or reconcile automatically.
The UK government’s Government Data Quality Framework offers a useful vocabulary. It describes uniqueness as “the degree to which there is no duplication in records” and consistency as the degree to which values do not contradict other values representing the same entity, including across systems. A customer with three names fails both tests at once.
Diagnosis
The visible symptom is inconsistent names. The common assumption is careless data entry. The structural cause is usually a lack of identity governance: no agreed master for customer data, weak rules for creating new records, and no reconciliation between the systems that each hold a version of the customer.
Several mechanisms tend to combine:
- Every system can create customers. Sales, finance, support and e-commerce each have their own “new customer” screen, so the same person or organisation is created repeatedly.
- Matching relies on names. Names are among the least stable identifiers a business holds. Without a shared reference such as a customer number, company registration number or verified email, systems cannot reliably recognise each other’s records.
- Integrations copy rather than link. When one system pushes records to another without a durable key, each sync can create a new record instead of updating the existing one.
- Changes are not propagated. A rebrand, a marriage or a corrected spelling is updated in one place and left untouched elsewhere, so records decay apart over time.
The Government Data Quality Framework lists incorrect data linking and inconsistent standards among the sources of poor quality, and it recommends root-cause analysis rather than temporary fixes. Vendor documentation reflects the same mechanism. Microsoft’s proactive engagement configuration guidance, for example, asks administrators to choose the correct unique identifier for contacts so that duplicate contact records are not created, and suggests passing an external CRM or master data identifier where another system is the source of truth. The lesson generalises: identity is held together by keys, not by names.
Commercial impact
The commercial value at stake is customer experience, revenue, cost to serve and decision quality.
Identity fragmentation damages customer experience because the customer is asked to repeat themselves and receives messages that ignore what another team already knows. It reduces targeting effectiveness and increases the cost of serving and marketing to the same person more than once. It complicates analytics, which can lead to biased insight: customer counts, retention and account value all look different depending on which records are joined. In regulated contexts it also matters for compliance. The ICO’s guidance on the accuracy principle expects organisations to take reasonable steps to keep personal data accurate and to correct or erase inaccurate data without delay, which is harder when nobody can see every copy of a person’s record.
Common misidentification
Teams often assume that normalising addresses, or cleaning up one system, will be enough. A one-off cleanse improves the picture for a while, but if every system can still create customers independently, the duplicates return. The lasting fix is a customer master data approach that links identities across sources and enforces a single customer view as records are created and changed.
Possibility
A better state is one in which each customer has a single durable identifier that every system recognises. One system, or a dedicated master data service, owns the creation of customers. Other systems reference that identity rather than inventing their own. Matching uses deterministic rules where strong keys exist and probabilistic matching where they do not, with uncertain matches routed to a named person for a decision. Identity resolution has accountable owners rather than being everyone’s background chore.
For a wider view of the same condition, see Why does one customer exist differently in three systems? and How to decide which system owns which data.
Intervention
Interventions combine data quality rules, master data management governance and cross-system identity reconciliation. They work best incrementally:
- Inventory where customers are created. List every screen, form, import and integration that can create a customer record.
- Choose the identity owner. Decide which system issues the customer identifier and which fields it owns, such as legal name, trading name and primary contact details.
- Introduce a shared key. Store the master identifier in every system that holds customer data, and make integrations update by that key rather than by name.
- Resolve the backlog with care. Match existing records using strong identifiers first, review uncertain matches, and keep a record of every merge so that it can be traced and reversed if wrong.
- Close the door on new duplicates. Add search-before-create checks and validation at the points of entry.
- Measure and repeat. Validate identity matches periodically and give conflicts a clear escalation route.
Where duplicate entry is already consuming staff time, the cost of duplicated customer data entry explains the wider consequence. If the business plans to automate on top of these records, poor data quality becomes an automation failure quickly.
Practical diagnostic
Warning signs
- Staff search for a customer by several spellings before they are confident they have found the right record.
- The customer count differs between the CRM, the finance system and the marketing platform, and nobody can explain the gap.
- Customers receive duplicate mailings or are contacted by two teams about the same matter.
- Account managers keep private spreadsheets to map which records belong together.
- Merging records is avoided because nobody knows what will break.
- Integration logs show records being created where an update was expected.
Diagnostic questions
- How many distinct customer identifiers exist across systems?
- Which system is allowed to create a customer, and which systems actually do?
- What rules govern identity resolution and matching?
- How often do duplicates arise, and through which entry point?
- Who decides when two records are the same customer?
- When a customer changes name, how many places must be updated by hand?
Bottom line
A single customer view requires disciplined identity governance, robust matching and cross-system reconciliation. When the same customer has three names, the business is not looking at three data entry errors; it is looking at three systems that have never agreed how to recognise a customer. Fixing that agreement brings a clearer understanding of customer behaviour and more coherent engagement across every touchpoint.
Sources and further reading
- The Government Data Quality Framework (last verified 10 October 2026)
- Principle (d): Accuracy (last verified 10 October 2026)
- Configure proactive engagement in Dynamics 365 Contact Center (last verified 10 October 2026)
- What is Entity Resolution? (last verified 10 October 2026)
- Record linkage - Wikipedia (last verified 10 October 2026)
Related Mellorca reading
- The Hidden Cost of Re-entering the Same Information
- Why One Number Requires Three People and Four Systems
- When Your CRM Knows Something Your Finance System Does Not