AI duplicate contact review: check evidence before merging

An AI duplicate contact review should produce evidence for checking record pairs, not automatically combine people with similar names. After this exercise, you can save five pair decisions showing matching fields, conflicts and unresolved questions. The eight original records remain intact. No contacts are merged, deleted or messaged.

A contact record stores information used to identify or reach someone. A duplicate may be a second entry for an existing customer, but resemblance alone does not establish that. Colleagues can share a mailbox, and unrelated people can share a name. We will use a small fictional file to keep those possibilities visible.

Content last updated: 15 October 2026. Every name, identifier and record below is an author-created teaching example. Phone fields contain tokens, not dialable numbers. The example.com domain is reserved for illustrative documentation. This is not customer data, an observed model run or a measured cleanup result.

What must the matching rule establish first?

Imagine a small equipment rental business checking two old exports. The immediate goal is not to shrink its customer count. It is to give the record owner a short list of questions they can investigate. A polished combined list would hide those questions if the assistant made unsupported decisions along the way.

For this exercise, a C code identifies a verified customer record in the fictional source system. Different customers have different codes. Matching C codes create a source-record review candidate. Different codes must not be automatically combined, and two blank codes do not count as a match. This is a stated exercise rule, not a claim about every CRM or database.

In a real export, ask what the identifier represents. It might describe a person, an organisation, a household or an account. Until that meaning is confirmed, do not let an assistant infer it from a display name. The same warning applies when a spreadsheet heading sounds more precise than its underlying data actually is.

Google Sheets documents removing repeated rows by selected column values. OpenRefine documents suggesting clusters of similar text for user approval. Neither operation, by itself, establishes a person's identity. We will not run either cleanup operation here. Their distinction helps explain why a separate evidence review comes before source changes.

Which eight records should you copy?

Copy the table without editing its values. Missing means the field was not supplied; it is not a shared identifier. An R label identifies an original row, while a C code identifies the fictional customer record under our stated rule. Keep both so a reviewer can trace the discussion back to the source.

Review these five selected pairs only: P1 R1/R2, P2 R1/R3, P3 R4/R5, P4 R6/R7 and P5 R6/R8. This is not a search through every possible pair. The selection makes the reasoning inspectable in a short session. It does not prove that a larger database contains no additional duplicates.

Create a separate decision ledger with columns for pair ID, both source-row IDs, matching fields, conflicting fields, missing evidence, proposal and human decision. The Excel prompt guide covers formulas and category-label cleanup as other tasks. Matching customer records requires explicit identifier and conflict rules beyond making text labels consistent.

How do you request proposals without requesting merges?

Use an existing working text assistant such as Gemini. Open gemini.google.com, sign in with an account you are allowed to use and start a new conversation. If text chat is unavailable, continue manually with the same card. This exercise does not require a customer-system connection, a spreadsheet integration or a new paid subscription.

A prompt is the written instruction you give the assistant. Paste the template below into the message box and replace [RECORD CARD] with all eight rows. Retain the rule and the five named pairs. Do not replace the fictional addresses with real customer details; they are unnecessary for learning the comparison method.

This is a fictional contact-record review. RECORD CARD: [RECORD CARD]. In this exercise, each C code identifies a verified customer record and is not shared between different customers. Missing values are not matching identifiers. Inspect only P1 R1/R2, P2 R1/R3, P3 R4/R5, P4 R6/R7 and P5 R6/R8. For each pair, preserve both source-row IDs and list matching fields, conflicts and missing evidence. A shared name, email or phone does not alone establish one person. Do not invent contact details, overwrite names, merge, delete or send messages. Leave the human-decision column empty. Do not assign confidence percentages.

First count P1 through P5 in the response. Check the two R labels against the original for each proposal. If the assistant announces that it found five duplicates, reject that interpretation. Five pairs were supplied for investigation; they were not labelled as confirmed duplicates. Ask for the specific incorrect statement to be corrected.

Keep the response beside the original card. Never turn a cleaner-looking proposed name into a replacement source value during this exercise. If you later consider work inside a spreadsheet, the Gemini in Sheets guide describes that separate workflow. A chat response is not an applied spreadsheet operation.

What should your five human decisions say?

P1 has the same C10 code, mailbox and phone token. Under the exercise rule, it is a candidate for reviewing entries attached to one customer record. That does not authorize discarding either row. We have not been given transaction history, correction notes or other fields that might need preservation. Record a source-owner review rather than inventing a complete merged record.

P2 shares a name but conflicts on customer codes and contact fields. Reject automatic combination under the stated rule. Do not add a story that Robin changed email addresses or was assigned a new code. No such history was supplied. If someone questions the code's quality, capture that as a separate investigation instead of silently overriding the rule.

P3 shares office@example.com while its names, customer codes and phone tokens differ. A shared mailbox is not enough to combine these records. Keep the pair separate in this exercise and explain the code conflict. Whether either record may receive marketing is a different question that the card does not answer.

P4 shares a phone token and a similar name, but both customer codes are missing and one email is absent. Mark it unresolved and ask the record owner for evidence. The phone could be shared; its history is unknown. Avoid presenting a high confidence score as a substitute for that missing information.

P5 shares a name while its email and phone tokens differ. It also lacks customer codes. Do not automatically combine it. The appropriate ledger entry describes the matching name and the unresolved identity, without choosing which email is newer or declaring either phone wrong. No source for those conclusions exists in the exercise.

Keep each decision local to its evidence. Considering R6/R7 as a possible match does not establish that R7 and R8 belong together. Nor does matching two empty fields create a new connection. Before accepting any proposed group, return to the original rows and ask which actual field supports every link in that group.

What can you finish and reopen in fifteen minutes?

1. Minutes one to three: copy the record card, version and identifier rule. Expected output: eight unchanged source rows.
2. Minutes four to seven: submit the request and check pair coverage. Expected output: proposals attached to the correct source IDs.
3. Minutes eight to twelve: compare the response with the five checks above. Expected output: human decisions and explicit questions.
4. Minutes thirteen to fifteen: save and reopen the document. Expected output: the original card and a separate review ledger.

This allocation is a planning suggestion, not a measured speed claim. Login trouble or an unclear identifier should be recorded as a blocker. You can still copy the fictional card manually. Do not convert a time target into pressure to guess an answer or approve a merge.

Open Notepad or another plain-text editor. Add the heading Contact review 01, no merges. Paste the original card, identifier rule and checked P1–P5 decisions into that document. Press Ctrl+S, select Documents and save contact-review-01.txt. Close the editor, reopen the file and confirm that all eight R labels and five P labels remain.

In my earlier writing about effectiveness and perfection, I described how pursuing every detail delayed my projects. Applying that principle here means finishing five explainable decisions instead of declaring an entire database clean. This is not a claim that I ran a rental-company cleanup or measured an improvement in its customer records.

What stays separate before a real source change?

Give the record owner the pair IDs and the missing evidence. Actual merging needs its own field-preservation rule, responsible person and recovery method. Decide what history must remain before considering a source update. Reducing the row count is not, by itself, evidence that the data became more accurate.

The email list cleaning guide addresses campaign eligibility and preserving opt-out instructions. This exercise does not establish sending permission, remove suppressions or replace that process. Keep identity review separate from deciding who should receive a campaign, even when the same export contains both kinds of information.

For a different field-comparison task, the supplier quote comparison guide explains working from supplied evidence without filling gaps. The artificial intelligence guide covers the broader concept. Here, completion remains a saved decision ledger with unchanged sources, not a finished CRM migration.