Customer data deduplication should make records more trustworthy without collapsing distinct customers into one. Finding similar names is relatively easy. Deciding whether two records represent the same organisation, site or person requires business rules. Separate candidate detection from the decision to merge, then define exactly what survives and how the change can be traced.
Define what a duplicate means in your model
Start by identifying the entity. Two records might describe the same legal organisation but different delivery sites, or one person with two job roles. A parent company and subsidiary may share a website without being interchangeable customer accounts. Your rules must preserve distinctions the business uses for ownership, reporting and fulfilment.
Write a short identity definition for accounts, sites and contacts. For example, a site could be a particular operational location linked to an account, while a contact represents a person who can hold several relationships. If your current model forces every relationship into a separate person record, apparent duplicates may reveal a modelling problem rather than careless entry.
Normalise comparison values while preserving originals
Prepare comparison fields that remove accidental variation: surrounding spaces, inconsistent capitalisation and agreed telephone formatting. Retain the original values for display and investigation. Do not erase meaningful parts of names or addresses simply to increase matches. A unit number can distinguish two businesses in the same building.
Handle missing values explicitly. Two blank telephone fields are not matching evidence. A generic switchboard number or shared enquiries address provides less evidence than a verified unique account reference. Record where identifiers came from, because a field labelled “customer ID” may contain different reference schemes from different source systems.
Use rules that explain why a pair was flagged
Begin with interpretable matching rules. An exact trusted account identifier within the same source context is a strong candidate signal. A similar name combined with the same postcode may justify review. A shared email domain alone should not merge accounts, particularly where a group of companies uses one domain.
- Strong candidate: matching verified identifier with no contradictory entity information.
- Review candidate: several consistent descriptive fields but no trusted unique identifier.
- Weak candidate: name similarity or a shared generic contact channel alone.
- Blocked merge: conflicting evidence that the records represent different entities.
Show the matched and conflicting fields to the reviewer. A confidence score without an explanation makes difficult decisions harder. Keep automated merging narrow until representative samples demonstrate that the rule preserves important distinctions. The cost of an incorrect merge can be much greater than leaving a questionable pair for later review.
Worked hypothetical example: two sites and one buyer
A fictional wholesaler has “Harbour Supplies, North Depot” and “Harbour Supplies, South Depot”. Both share the same buyer email address and main switchboard number. Their site addresses and delivery instructions differ. The matching rules flag the pair, but the reviewer keeps two site records under one customer account rather than merging the locations.
The same review finds two records for the buyer, one with an old job title and one with a recently verified telephone number. The reviewer confirms they are the same person, preserves one contact identity and links it to both sites. Activity history remains associated with the relevant site or opportunity where that context exists.
A third contact uses the same purchasing mailbox but has a different name and role. It stays separate until the business establishes what it represents. The shared address is not proof of personal identity. This invented example demonstrates cautious entity resolution, not a real cleanup result or a product capability claim.
Choose surviving values field by field
Do not assume the newest record is the best record. Its timestamp may reflect a bulk import rather than a recent verification. Set precedence by field: a confirmed address from the account owner may outrank an unverified form entry, while a recently confirmed telephone number may replace an older one.
Preserve useful history, attachments, relationships and source identifiers. Keep contact preferences and their provenance intact; conflicting preferences should enter an appropriate review process rather than being silently replaced by a permissive default. Record who approved the merge and the reason. This is an operational data-quality decision, not a substitute for any separate policy review.
Protect downstream systems before merging
Check whether both records have identifiers in accounting, support or other connected systems. Merging locally does not necessarily combine those external accounts. Agree which mapping survives and how historic references continue to resolve. Pause relevant outbound updates if a merge could otherwise create or overwrite records unexpectedly.
Test whether the product supports reversal and what reversal actually restores. If it does not, retain an appropriate pre-merge snapshot and a clear reconstruction procedure. Recovery should include relationships, not only contact field values. Start with a small reviewed batch and verify downstream behaviour before applying the rule broadly.
Prevent recurrence at the point of entry
Offer a search-before-create step using the same entity distinctions. Show enough context for staff to recognise an existing record: site, account reference and relevant contact details. Avoid blocking legitimate creation merely because another record has a similar name. Let users explain why a new record is needed and send uncertain cases for review.
Track duplicate candidates by source to identify repeated imports or forms that omit useful identifiers. Keep a sample of rejected matches as test cases when rules change. For the financial consequences of account mapping, read accounting CRM reconciliation. Explore Visuosofts CRM development or contact Visuosofts with anonymised duplicate pairs and the distinctions your team needs to preserve.