Author: Nadali. Prepared by the editorial team using AI.
A shop has two cards with similar surnames, a hotel has several guests sharing a phone number, and a service company has two contacts using a general mailbox. Staff want to remove duplicates, but an incorrect merge could mix different people’s histories.
In brief: ask AI to prepare a queue of suspected pairs, while a responsible employee decides whether records should be merged. The useful first-pass output is an explanation of agreements and contradictions tied to source fields, not a supposedly cleaned database.
This guide is for small-business owners and customer-database administrators. The workflow below is an editorial proposal, not a product test. It does not cover merging medical records, credit files or other records where a mistake could have high-impact consequences.
1. Define what a record represents
One person may have several orders. A company may have several branches and contacts. Before trying to reduce the row count, state whether a record represents a person, organisation, delivery address or individual enquiry. Two orders from one customer are not duplicate orders merely because they share a phone number.
The UK Government Data Quality Framework distinguishes uniqueness, completeness and accuracy. Having no repeated records does not establish that values are correct. We apply that distinction to customer records. Assess whether linking is correct, not just how many cards disappear.
Agree who can confirm the person or organisation using existing approved sources. Do not collect passport details or other unnecessary information just to make cleaning easier.
2. Preserve the original and prepare a working copy
Record the export date, system, filter and record count. Retain each card’s stable ID; a row number after sorting is not a substitute. Our separate CSV guide explains how to check that identifiers survive transfer.
Use fictional records for the first practice run. For real work, use only an approved tool and permitted fields. Names, phone numbers and purchase histories do not become suitable for any arbitrary service merely because you replace an ID. If there is no approved environment for the necessary data, keep comparison within the source system or do it manually. Define data-sharing boundaries before exporting.
Keep normalised values beside the originals. For example, a separate comparison column may remove extra spaces. Do not overwrite the original name or guess a country code for a phone number.
3. Build a pair-review queue, not a merge instruction
Start with simple checks in the existing system: exact repetitions of agreed keys, blanks and contradictions. Use AI to organise selected candidates and explain why they need review. A small database may not need an AI assistant at all.
Require these fields for every pair:
- both record IDs and the source version;
- matching fields with exact values;
- conflicting fields;
- missing information and questions to investigate;
- a needs-review status, without automatically choosing a surviving card.
A shared phone might belong to a reception desk or family. A matching email address might be a company mailbox. Transliteration differences may explain similar names but do not establish identity. Treat these as reasons to investigate, not ready-made merge rules.
Do not ask the model to combine whole groups merely through a chain of resemblance: if A resembles B and B resembles C, that alone does not establish that all three records represent one customer.
4. Worked illustration: one mailbox, two contacts
This example is fictional. Cards C-014 and C-209 have the same general company email address but different contact names. C-014 lists purchasing, while C-209 lists delivery reception. No other evidence is available.
The appropriate first-pass output is a pair for review, retaining both IDs and explaining that the address matches, the name and role differ, and the mailbox may be shared. A merge has not been approved. Even a confident AI statement that these are one customer adds no evidence.
An authorised employee may establish that these are two people at one organisation. The cards then remain separate; if needed, they can be linked to the organisation using an approved, supported method. This illustration demonstrates no measured time saving or sales improvement.
5. Decide the fate of fields and linked records
If a duplicate is confirmed, specify the surviving card and the source for each conflicting field. The newer record is not necessarily more accurate. Do not transfer messaging consent, an opt-out status or other important flags simply by choosing whichever field is populated; the responsible person must check the rules of that particular process.
Before changing anything, the administrator reads the system documentation. For example, Microsoft describes a Dataverse merge as retaining the primary record, deactivating the secondary one, and linking associated notes and activities to the primary. That is product-specific behaviour, not a universal guarantee for every CRM.
Check what will happen to orders, open enquiries, points and integrations in your own system. Record the approved change, executor and verification method. If complete restoration is not supported, do not describe the operation as reversible: stop until the responsible person makes a separate decision.
6. Verify one approved change and measure mistakes
Reread the current records before execution: someone may have changed them since the export. First check the process with test records in an approved environment. Preserve the before-state and a log containing old IDs, the new link, selected values, decision evidence, approver and person verifying the result.
After the change, reconcile links to orders and enquiries and the necessary totals. A lower card count alone proves nothing. Record incorrectly suggested pairs, confirmed duplicates, unresolved cases and human review time. Also inspect a sample of records the search did not suggest; otherwise you are not assessing missed duplicates. A sample does not prove the completeness of the whole database.
Conclusion: start with a controlled candidate queue. Merge only after confirmation, dependency checks and agreement on restoration or its limitations. If the queue takes more time than manual checking, change the criteria or leave AI out of this step.
Sources checked November 1, 2026. Built-in feature availability depends on your system and permissions; the workflow does not require buying a new subscription. No product tests were performed.
Cover: a reused original Nadali AI illustration showing a person comparing two printed records beside a calculator. It depicts neither real customer data nor a product test.
