Review Duplicate Customer Records Safely

1. Begin with a possible duplicate, not a conclusion

Possible duplicates can appear when staff create records from separate conversations, forms, imports, or referrals. Similarity can help find a pair worth inspecting, but it cannot establish identity. A business reception number may be shared by colleagues; a family phone may be shared by more than one person. A common name, incomplete address, or old email can also make different customers look alike.

Suggested practice: mark the pair as under identity review and pause routine clean-up edits that could blur the evidence. Do not overwrite one record merely because the list would look tidier. Until a verified fact establishes otherwise, keep necessary follow-up active on both records. Similar information does not make either record wrong.

Start with one pair and one reviewer. Write down why the pair was flagged, who owns each open enquiry, and which evidence is missing. Set a review deadline, but do not turn that deadline into permission to merge. If the evidence is still inconclusive, leave both records intact and assign the next verification step. The useful output is a recorded identity decision with preserved follow-up, not a lower count in the customer list. Work through a single pair before considering a wider clean-up so the team can check whether its evidence and handoff rules are usable.

2. Build a pairwise review sheet before changing data

Suggested practice: create one worksheet row or review note for each pair. Record A’s and Record B’s stable pre-change record references, each creation source and date, the reviewer, review date, and eventual decision. Record references are useful because displayed names, phone numbers, and other values may later change; after some product-specific merge processes, identifiers may also differ.

Compare fields that matter to the work: name, company or role, contact method, location where relevant, enquiry or quoted-work context, and the date each value was last verified. Keep separate fields for agreement and contradiction. Agreement should say what matches and how it was corroborated. Contradiction should state facts that cannot comfortably describe one identity, such as two named contacts on separate confirmed jobs.

Then list outstanding work under each record: a promised callback, quotation question, booking-related action, complaint, renewal reminder, or internal task. For every item, write the current owner, immediate next action, due date if known, and the original record reference. This prevents a data-quality decision from burying active work inside historical context.

3. Use three decisions instead of a forced merge choice

Choose keep separate when evidence supports two people or material contradictions remain. A shared household, generic company inbox, or main office number may explain matching information without proving one identity. Record why the pair remains distinct and whether a specific future event would justify another review.

Choose seek evidence when the pair looks plausible but lacks dependable corroboration. Suggested practice: assign a narrow task, such as checking a source document already used in the normal workflow or asking the appropriate owner to confirm the customer’s preferred identity. Do not ask staff to infer identity from tone, memory, or a fragment of chat.

Choose eligible for authorised merge only when evidence supports one identity, contradictions are resolved, and an appropriately authorised person can follow the actual system’s documented process. Eligible is a review handoff, not a merge command. It does not grant permission or predict what a particular product will retain.

4. Preserve follow-up context before an authorised change

Suggested practice: create a pre-change snapshot containing both original record references and IDs where available, the values selected during review, open commitments, responsible owners, useful links or references, the reviewer’s decision, and a timestamp. Store it under the team’s normal access rules. Its purpose is to show what was considered and what must be checked afterwards.

A snapshot is not a rollback guarantee. A merge can affect structure, associations, timelines, identifiers, or workflow behaviour differently across products and configurations. Do not tell staff that a backup means a destructive action is reversible. Require the authorised operator to check product-specific consequences before acting.

For every open promise, preserve an operational item on the surviving context rather than relying on historical text alone. Where the system permits, retain the original record reference as context. Confirm one accountable owner and one immediate next action. If a commitment cannot clearly be assigned to the surviving identity, keep the records separate while that relationship is resolved.

5. Fictional example / 虚构示例: shared phone and confirmed duplicate

Fictional example: Record C-118 says “Amina, purchasing,” while C-207 says “Amina, site coordinator.” Both contain a company main line. Their requests concern different projects, and source messages name different roles. The worksheet records the shared phone as an agreement but the distinct role and work context as contradictions. Decision: keep separate. Existing follow-ups stay with their current owners, and the review note explains that the company number is shared.

Fictional example: C-310 and C-455 have independently verified matching identity details and refer to the same quotation discussion. C-455 was created later, but C-310 contains an open callback promise with an assigned owner. Decision: eligible for authorised merge. Before any change, the reviewer records both original references and the callback. After the authorised operator uses the system-specific process, the reviewer checks that the surviving context still shows the callback, owner, next action, and source reference. These invented cases are teaching examples, not customer results.

6. Reconcile after the authorised change

Suggested practice: reopen the surviving record and compare it with the pre-change snapshot. Confirm that intended links or associations can be found where the system is expected to retain them, needed timeline context remains accessible, and every open promise is still actionable. Check the owner and next action directly; an activity log alone does not establish responsibility.

If something is missing, unclear, or linked to the wrong context, record the discrepancy and escalate through the team’s normal system-owner process. Do not perform another merge, delete remaining evidence, or close the review merely because the visible duplicate count has fallen.

A concise reconciliation note can state the surviving record reference, prior references, decision authority, reviewer, date, and status of each open action. This gives a manager a reviewable handoff without requiring them to reread every old conversation.

7. Product facts, suggested practice, and the BossFlow handoff

Official product documentation note: HubSpot says its duplicate-record manager can present potential contact and company pairs for review, with merge or reject actions. HubSpot also says merged records cannot be unmerged. Those are HubSpot-specific statements only; they are not claims about SME Systems, BossFlow, or your current system.

The worksheet, evidence thresholds, pre-change snapshot, and reconciliation routine here are original suggested SME practice. Adapt them to the records, access controls, and escalation rules your team actually uses.

For system-specific implementation, permissions, migration choices, integrations, and quotation discussion, use a BossFlow workflow review. SME Systems provides education; BossFlow owns workflow review and implementation discussion.

Source note: HubSpot Knowledge Base: Review and manage duplicate records — HubSpot’s stated review scope for potential duplicate pairs. HubSpot Knowledge Base: Merge records — HubSpot’s stated merge and non-unmerge scope.

Practical Checklist

• Open both records and record stable pre-change references before editing.
• Mark the pair under identity review; do not treat similarity as proof.
• Compare source context, last-verified values, agreements, and contradictions.
• List each open promise with its original record reference, owner, next action, and due date if known.
• Choose keep separate, seek evidence, or eligible for authorised merge.
• Create a pre-change snapshot as review evidence.
• Use only an authorised operator and the actual system’s documented process.
• Reopen the surviving record and reconcile links, timeline context, promises, and ownership.