Duplicate customer records? Check what you are combining.

Consider a fictional supplier using a sales application alongside an accounting system. Sales knows the customer by a trading name. Accounts records the organisation that pays. Another branch shares the same contact person but has a separate delivery address and its own receiving arrangements. This is an illustrative example, not an IndustrylinQ client case.

Three similar names in a search result do not establish that three records describe the same thing. They may represent different parts of a customer relationship. Combining them could remove the distinction an employee needs when preparing a delivery. A shorter list would then be less useful.

Describe the relationships your business needs to represent: organisations, branches, contacts, invoice recipients and perhaps project locations. Establish how they connect. One person may support several branches; an order for one location may be paid by another organisation. Make those relationships explicit before cleaning up the records.

The Government Data Quality Framework considers data quality in relation to its intended use. Apply that principle to the work: employees need information that supports the correct customer agreement. The approach below is our practical application to business software, rather than a requirement to adopt a government framework.

Similar names, shared addresses and matching contact details can help identify possible duplicates. They are clues rather than a complete business decision. Look for evidence that the records represent the same relationship, including original enquiries, confirmed customer details and references in connected applications.

Allow three outcomes: confirmed duplicate, intentionally separate or unresolved. An unresolved record should have a clear explanation and somebody responsible for investigating it. This is more useful than requiring employees to approve a merge simply to clear a work queue.

Consider when each value was valid. An earlier delivery address may be correct for a completed order even though the customer's current address has changed. Replacing the old value everywhere could make that order difficult to understand. Decide separately what applies to new work and what must remain recognisable within the history of an existing transaction.

A technical administrator can compare records without knowing which commercial agreement applies. Separate the work of deciding what a relationship means, making routine corrections and implementing the technical change. In a small business, one person may perform several of these roles. The reasoning should still be recorded.

The UK's Data ownership model distinguishes accountability for significant data decisions from day-to-day management. This distinction can clarify authority without requiring a small company to reproduce a large governance structure.

Give employees a straightforward way to flag a possible duplicate and explain the difficulty it causes. Perhaps they cannot tell which account to use for a quotation. A flag should initiate review, not automatically combine the records. The reviewer should be able to explain why a difference is retained or resolved.

Select a small number of confirmed duplicates and identify everything attached to them. Customer records may connect to orders, documents, pricing arrangements and portal access. Choosing the surviving record is only part of the task. You also need to understand what other applications will do with the result.

Area	Question to resolve before changing it
Open orders	Will the delivery location and agreed terms remain clear?
Contacts	Does each person belong to this organisation or branch?
Pricing	Which agreement applies, from when and to which work?
Portal access	Could the change expose additional records to a user?
External references	Can connected applications still recognise the earlier identity?

Make conflicting values visible in the proposal. Do not assume that the most recently written value is the most accurate. A fresh import can contain older information. Have the appropriate colleague decide which value applies and retain the reason for that decision.

Ask the technical partner to explain how the change will be applied, verified and, where possible, reversed. A backup does not by itself explain what happens to work created after an incorrect merge. Agree when processing should stop, who makes that decision and how the original relationships could be reconstructed.

Start in an isolated test environment using suitable test data. Ask an employee to find the customer, retrieve an existing order and prepare a new one. Check the receiving applications as well. A successful update in sales does not establish that accounts now recognises the intended relationship.

Include a deliberate non-duplicate: two branches sharing a contact. They must remain separately usable. This tests whether the selection rules are too broad, alongside whether a genuine duplicate can be resolved. Begin live processing with a limited, reviewed group and inspect the outcome before proceeding further.

Investigate how the records were created. Search might require an exact spelling, an import might omit an existing external reference, or employees might have no way to add a branch except by creating another customer. Each cause suggests a different improvement.

The Data quality issues framework links quality rules to their purpose and the impact of a failure. In practice, give attention first to duplicates that could misdirect a delivery or change access, rather than treating every untidy search result as equally urgent.

The answer might be clearer search results, an explicit branch structure or better handling of customer identifiers from another application. Show employees why a potential match has been suggested and let them reject it with an explanation. Automated matching can assemble candidates; it should operate within the meaning and authority agreed for the business.

Bring a few confusing records and the work connected to them to an initial discussion. Our systems integration work connects data definitions, processing and verification. If the customer relationship itself needs clarifying first, business process analysis can establish that foundation. The aim is a colleague who can select the right relationship and trust the commitments attached to it.