Duplicate contacts in your CRM: set matching rules before you merge

Separate a duplicate person from a repeat enquiry

Two contact rows may describe the same person, while two enquiries from that person may be legitimate separate events. Combining the contact should not erase the second enquiry or make one purchase appear to be two customers. Write down the objects you are cleaning: contacts, companies, enquiries and deals. Decide which is the stable identity and which represents an event. This stops a simple cleanup from distorting conversion and response reporting.

Keep readingAgree what every handover record contains

Build a matching ladder

Use a conservative set of matching rules and a review queue for uncertain cases. Normalise formatting for comparison while keeping original values available for inspection. A shared family email, a reception phone number or two people with the same name should not trigger an unreviewed merge.

HubSpot illustrates why tool-specific rules matter: its documentation describes email-based contact deduplication, domain-based company deduplication and Record IDs for supported import workflows. Check your own CRM's rules rather than assuming every system behaves that way.

• Exact internal record ID: use it when updating a known existing record through a supported import or integration.
• Confirmed email match: a strong candidate, but check shared addresses and the relevant enquiry context.
• Phone match after sensible formatting: review reused, household and office numbers before treating them as identity.
• Similar name plus company: a review clue, not proof of the same person.

Agree which values survive

Before the first merge, list the winning value or decision process for owner, phone, email, consent status, original acquisition source, latest activity and open deals. Preserve the distinction between the original source and the most recent campaign interaction. HubSpot warns that records cannot simply be unmerged. Test a small reviewed example and examine the resulting activities, associations and properties before doing a larger cleanup. An export is useful evidence, but it is not a proven restore method for every relationship in a CRM.

Worked example: fix the count without losing the work

Suppose an inbox import creates a second contact for a prospect who already submitted a website form. There are two rows, one person and two genuine communications about one job. The reviewer confirms the matching identity, preserves both communications and the open deal, then corrects the duplicate contact. For reporting, record the cleanup separately. A fall in contact rows after a merge is not a fall in real demand. Keep a small audit with the surviving ID, merged ID, reason, reviewer and affected deal so the change can be explained later.

Stop the next duplicate at its entry point

Trace whether the duplicate came from a form, an ad platform sync, a manual entry or an import. Agree a stable external ID or supported upsert rule where the tools allow it. Do not use a name alone as an integration key. Check retries and partial failures. A connector that creates a contact successfully but loses the response should reconcile that outcome before creating another. Ask the provider how it identifies an already-created record, and test this behaviour in a safe environment.

Keep readingKeep the source when two records merge

Review the exceptions each week

Give someone ownership of possible matches that automation cannot resolve confidently. Sample recent records and check that preference changes, deal ownership and acquisition history still make sense. Monitor duplicate creation at each source, not just the size of the cleanup queue. The goal is a reliable customer history and meaningful enquiry counts. A smaller contact total is useful only when it represents the underlying people and events more accurately.