THE SHORT ANSWER
A CRM duplicate is more than a similar name. Two records may describe the same organisation, represent different subsidiaries or deliberately capture separate relationships. AI can surface suspicious pairs and conflicting fields. Whether merging is appropriate, and which information must survive, depends on explicit rules and the actual business context in which colleagues use those records.
To connect individual AI applications with reliable marketing operations, read the pillar guide AI transformation in B2B marketing: from individual prompts to reliable operations.
Distinguish the type of data problem first
Separate potential duplicates from conflicting field values, outdated relationships and missing information. These problems need different actions. Two records sharing a domain may represent different business units, while a single record with two addresses may simply need a current address. Ask AI to name the suspected problem class and explain it. A general quality score provides little help if nobody can determine whether to investigate a contact, update a field or preserve an existing relationship deliberately rather than merge it away. Explore this further in the guide AI CRM enrichment: evidence suggestions and protect core records.
Generate candidates from several signals
Use stable identifiers, domains, known relationships and controlled name variants for initial selection. Similarity methods can generate candidates, but their scores should not be presented as proof of identity. HubSpot documents different rules for contacts, companies and imports; companies created through its API are specifically not automatically deduplicated by domain. Check how your records actually enter the system. A rule that works during an import does not establish the same behaviour in an integration or an AI workflow with direct write access.
Create a review sheet for each pair
Display both record identifiers, relevant matches, conflicting values and existing relationships together. Link to the CRM context rather than unnecessarily copying sensitive conversation notes into the review interface. The recommendation must allow uncertainty about whether the records truly duplicate one another. Name the additional information needed to resolve that uncertainty. Such a view shortens the human decision without pre-empting it through a confident summary. It also reveals whether the agent considered meaningful counterevidence or merely repeated the similarities that initially triggered the candidate match.
Resolve field precedence and relationships before merging
Decide which source takes precedence for each field. The most recently edited value is not necessarily the correct one. Inspect connected contacts, open tasks, opportunities and ownership alongside company attributes. Merging can affect reporting and active workflows even when every visible name field looks accurate. Establish which platform changes can be reversed and which cannot. If the consequences remain unclear, the AI process should end with a documented proposal rather than an automatic merge that somebody must later attempt to reconstruct.
Assess a hypothetical subsidiary example
Imagine two company-group records. Both use the same international website, but one belongs to the German sales team and the other represents a French framework agreement. AI reports a highly similar organisation. Discussion with the owners reveals separate buying responsibilities. You retain both records and add a clear group relationship. The value of the investigation comes from a more understandable structure that prevents future misrouting, rather than deleting an apparent duplicate. The example also shows why a technically plausible match can still be a poor business decision.
Include false merges deliberately in testing
Test known duplicates alongside similar but separate organisations. Add name changes, multiple domains, personal email addresses and former-employer relationships. Assess which incorrect merges are proposed and which genuine cases are missed. The consequences differ: an overlooked candidate creates more work, while an incorrect merge can mix business relationships. Reflect that difference in approval rules. A good overall accuracy figure is insufficient when the critical edge cases are confidently treated as certain. Review the cases individually before deciding how much automation the process can safely support.
Fix causes at the points of entry
A cleaned database stays dependable only when incoming data is controlled. Examine forms, imports, interfaces and manual creation separately. Document where each problem originated and which input check might prevent it. Record confirmed non-duplicates so the same pair does not create work on every run. Revisit those exceptions after meaningful organisational changes. AI can then support ongoing data stewardship with traceable decisions, instead of repeatedly discovering the same symptoms and recommending risky bulk changes that leave the underlying source of duplicates untouched. Explore this further in the guide CRM data quality for trustworthy marketing decisions.
INTERACTIVE / FROM READING TO ACTION
Three checkpoints for your implementation
Choose a checkpoint and track your reading progress. Checks are neither saved nor sent and do not score your business.
CHECKPOINT 01
Create a review sheet for each pair
Display both record identifiers, relevant matches, conflicting values and existing relationships together.
Explore in the article ↗CHECKPOINT 02
Resolve field precedence and relationships before merging
Decide which source takes precedence for each field.
Explore in the article ↗CHECKPOINT 03
Assess a hypothetical subsidiary example
Imagine two company-group records.
Explore in the article ↗Frequently asked questions
Does a matching domain prove duplication?
No. Check entity, location, buying responsibility and the intended structure of your CRM.
Should AI merge records directly?
Start with candidates and review sheets. Acceptance needs tested rules covering fields, relationships and consequences.
How do we prevent recurring false candidates?
Record confirmed non-duplicates with reasons and revisit that decision when the organisational context changes.
How can I put “Distinguish the type of data problem first” into practice?
Separate potential duplicates from conflicting field values, outdated relationships and missing information. These problems need different actions. Two records sharing a domain may represent different business units, while a single record with two addresses may simply need a current address.
What matters when working on “Generate candidates from several signals”?
Use stable identifiers, domains, known relationships and controlled name variants for initial selection. Similarity methods can generate candidates, but their scores should not be presented as proof of identity. HubSpot documents different rules for contacts, companies and imports; companies created through its API are specifically not automatically deduplicated by domain.
