Before the Platform Moves: An Identity Audit for Fragmented Customer Records

Most UK SMEs do not set out to hold the same customer three or four times. It happens gradually. A sales enquiry is entered into the CRM. The accounts team creates a billing record when the first invoice is raised. The support desk opens a ticket under the name used in an email. The ecommerce platform keeps its own customer account, with a different address and a marketing preference that nobody has checked since it was captured. Each system is internally consistent. Together, they are not.

That fragmentation is manageable while people remain in the loop. A colleague recognises the customer, checks the right screen and reconciles the difference. It becomes less manageable when a new platform, a data migration or an AI-assisted workflow is asked to act on those records at speed. The upgrade does not create the identity problem. It exposes it.

Identity is a process, not a field

In practical terms, customer identity is the ability to say, with confidence, that a person, company, billing account and set of interactions belong together. It is not simply a unique customer number. It is a set of decisions about which identifiers are trusted, which systems may create a new record, and which fields take precedence when sources disagree.

For a UK SME, the discipline is usually lighter than a full master data management programme. It still needs an owner, a small set of rules and a repeatable audit. The objective is not a perfect single record for every customer. It is a record set that is fit for the next operational decision.

Map the places where a customer is created

Begin with a simple map rather than a data cleanse. List every system that can create or materially change a customer record: CRM, accounts, support desk, ecommerce, subscription billing, field service, marketing automation and any spreadsheet that still functions as a de facto register. For each, note who can create a record, which identifiers are mandatory, whether duplicates are blocked, and where the record travels next.

Pay particular attention to identifiers that are almost unique but not quite. An email address may be shared by two people in a small business. A company name may be written with or without ‘Ltd’. A phone number may move between employees. A Companies House number is strong evidence for a registered entity, but it does not identify the individual contact. The audit should distinguish between identifiers that prove identity and attributes that merely support a match.

Separate duplicates, conflicts and orphans

Not every identity problem is a duplicate. It helps to sort findings into three groups.

• Duplicates are two or more records that represent the same person or organisation. They may be exact copies, or they may differ by spelling, address format or contact details.
• Conflicts are records that appear to refer to the same entity but disagree on material facts: legal name, billing address, VAT number, ownership, consent status or account status.
• Orphans are records with no reliable link to a customer, contract or owner. They may be old imports, test records or contacts left behind after a system change.

This distinction matters because the remedy differs. Duplicates need a merge decision. Conflicts need a field-level source of truth. Orphans need a retention and ownership decision, not a hopeful match.

Score clusters before anyone presses merge

A useful safeguard is to score each suspected duplicate cluster before merging. A simple five-factor method is enough for most SMEs. Rate each cluster from 1 to 5 on the following:

1. Matching evidence — 1 for a name-only similarity, 5 for a verified unique identifier such as a Companies House number or a confirmed account reference.
2. Recency — 1 for a record untouched for years, 5 for activity in the last 90 days.
3. Source authority — 1 for an unknown or unofficial source, 5 for the system that is authoritative for the field in question.
4. Downstream dependency — 1 for a record with no invoices, contracts or open tickets, 5 for one tied to billing or live support obligations.
5. Consent clarity — 1 for conflicting or missing marketing permissions, 5 for a clear and auditable consent position.

A total of 20 or more suggests a strong case for merging after a sample check. A score of 12 to 19 should go to manual review. Below 12, keep the records separate until better evidence appears. The score is not a substitute for judgement. It is a way to make the judgement consistent and reviewable.

Make the source of truth field-level

Many identity projects stall because teams argue over which system should be the master. In practice, the answer is usually field-level. The accounts package may be authoritative for billing name, billing address and VAT details. The CRM may be authoritative for account ownership and sales history. The support desk may be authoritative for service contacts and open cases. The ecommerce platform may hold the current delivery address and transaction history.

Write those rules down in a short matrix. Name the field, the authoritative system, the permitted exceptions and the person accountable for changes. Then apply the rules consistently during the upgrade. A customer record can be assembled from more than one source without pretending that a single platform owns every fact.

Clean with GDPR and retention in view

Identity work involves personal data, so the cleanup itself needs care. Merge only on reliable evidence, and record who merged which records, when and why. Preserve a suppression list where a person has opted out of marketing; deleting it as part of a tidy-up can undermine compliance. Do not merge records with conflicting consent states simply to produce a cleaner list. Keep financial and transaction records for the period required by tax and company law, even if the associated contact record is being rationalised.

Apply data minimisation to the audit sample. Use pseudonymised extracts where possible, restrict access to the working file, and delete the audit copy when the exercise is complete. Check the retention schedule before removing orphan records, and make sure any subject access or erasure process can still find the data after migration.

A pre-migration checklist for UK firms

Before the platform move, confirm the following:

• A named owner for customer data and a deputy have been agreed.
• Every system that can create a customer record has been listed.
• Strong identifiers and weak matching attributes have been separated.
• A sample of at least 50 duplicate clusters has been scored and reviewed.
• Field-level source-of-truth rules have been written down.
• Consent and suppression records have been checked before any merge.
• Records subject to financial retention have been flagged and excluded from deletion.
• Merge decisions are logged with a reason and a date.
• Test data for the new system is pseudonymised or synthetic.
• A post-migration check is scheduled to catch new duplicates in the first month.

The test to run before the upgrade

Take a representative sample and measure three things: the duplicate rate, the conflict rate and the orphan rate. If the duplicate rate is high, fix the creation rules before migration. If conflicts cluster around billing or consent fields, resolve the source-of-truth question first. If orphans are widespread, decide what retention requires before the new platform inherits the problem.

An AI project will not forgive a fragmented customer record. It will reproduce the fragmentation at greater scale. The practical answer is not a vast cleansing programme. It is a short, documented identity audit, a field-level set of rules and a willingness to leave uncertain records alone until the evidence improves. That is the work worth doing before the platform moves.