To fix duplicates in your CRM, first confirm that the records represent the same person or company. Then decide which information to keep, review the relationships and check the result of the merge. A similar name is not enough: joining the wrong records can mix conversations, owners and deals that were meant to stay separate.
Two salespeople call the same contact. One thinks a quote is pending and the other sees a closed deal. You do not need a more sophisticated artificial intelligence to understand the confusion: you need to rebuild the story that was split in two. The duplicate record becomes duplicate work when it triggers tasks and decisions.
The problem appears in small businesses too. Imagine a sports equipment distributor that receives enquiries through forms, imports and phone calls. A club can have several contacts and the same person can work for more than one organisation. This scenario is hypothetical; it helps tell a real duplicate from a legitimate business relationship.
How do you tell a duplicate from two similar contacts?
Start by defining what each object in your CRM represents. A person, a company, a site and a deal are not the same unit. The identity of the record must be clear before you compare names or ask a tool to suggest matches.
An email address can help, but it does not always settle the commercial identity. A reception mailbox may represent a team; two companies can share an external contact. Treat a match as a signal to review, not as automatic permission to merge. Document which piece of data lets you decide and which situations fall outside the rule.
The HubSpot deduplication documentation, updated on 8 September 2026 and accessed today, explains criteria tied to email, domain and record identifiers in different flows. Those rules belong to the product and to the way records come in: they should not be generalised to any CRM or integration.
The distributor in the example would need to tell the sports club apart from the person placing an order. If two records contain a common name, check the entity, the contact's role and the context of the relationship. Keeping two justified records is better than forcing an apparent clean-up that loses useful information.
Why can a merge change more than it seems?
Records usually carry connected information: notes, tasks, owners, conversations and open deals. That is why merging can have wider consequences than joining two names. The exact effect depends on the system. Before acting, check which elements it combines, which values it keeps and how it treats associations.
HubSpot describes a tool for reviewing and managing possible duplicates, whose documentation was updated on 8 October 2026. That update is a recent signal to review the topic; it does not show that every business has access to the same features nor does it prove a search trend.
Check the edition and permissions available on your account. If a feature presents candidates, review the evidence it shows and the resolution options. Do not approve a batch because the pairs have a high similarity percentage. The business's identity criterion is still needed, especially when a record contains contradictory information.
Consider what will happen afterwards too. An automation may watch the status or owner of the resulting record. Ask which events the merge triggers and which tasks might run. A clean-up operation should not send messages or reassign work unexpectedly unless the team has anticipated those consequences.
What information should the main record keep?
The most recent record does not always hold the most reliable data. It may come from an incomplete import, while an older record keeps the confirmed contact. Decide precedence by type of information: verified identity, current data, history and owners. You do not need a single rule for every field.
A useful criterion separates confirmed facts from pending data. If an address was updated at the customer's request, keep the reference to the change. If an import added a value with no context, flag it for review. The clean-up should improve traceability, not make the origin of a conflict disappear.
- Identity needs sufficient evidence of a match.
- Contact details require telling apart what is current from what is confirmed.
- History must keep its context and relationships.
- Open deals need a review by the owner.
- Communication preferences are not deduced from a similarity between records.
In the hypothetical distributor case, one record might hold the buyer's mobile number and another the club's generic account. They are not necessarily competing values. They may belong to different people or channels. Before deleting one, understand how it is used. A tidy CRM describes real relationships, not just records with fewer repeated fields.
How do you review a batch without mixing everything at once?
First select a small, representative group. Include obvious pairs, ambiguous cases and records with active relationships. Agree on who confirms each situation. If the system offers a preview, use it to check what would be kept before applying the operation. A sample chosen with care uncovers mistakes that a uniform batch hides.
Keep the information needed to audit the decision, according to your tool's possibilities and conditions. Do not assume that exporting a spreadsheet is the same as being able to undo a merge with all its relationships. The ability to recover must be checked before acting, not after finding a wrong merge.
For each pair, record the decision and its reason: merge, keep separate or investigate. Avoid sending a whole database of personal data by email for someone to review. The check should be done in a suitable environment and with suitable access. This is general information, not legal or professional advice.
After the test, review a resulting record with the team that uses it: identity, owner, notes and associated deals. Also verify what changed in the related automations. Counting deleted records does not measure the success of the clean-up; a person finding the right story does give a useful signal for accepting the change.
What should you fix so it does not happen again?
A clean-up falls short if the next form creates another record. Identify where the duplicates came in: import, manual entry, synchronisation or integration. Each entry point may use a different criterion. Look for a common identification pattern and document the exceptions the team must resolve.
HubSpot's deduplication documentation lets you review how existing identifiers are used during certain import processes. Before applying it, check the file and the specific procedure. Updating a record and creating a new one are different decisions, and an omitted column can change the result of the process.
Explain to the people who enter records when to look for an existing one, when to create another and what to do if information is missing. A clear warning at the point of entry is usually more useful than an error report that arrives when everything is already loaded. Automation can help detect matches, but doubtful cases need a review path.
Set up a check after changing a form or connecting a provider. Do not wait for the team to complain about duplicate calls. The number of candidates, the unresolved cases and the identity incidents can guide the review. Avoid turning those indicators into a goal of deleting records at any price.
How have we approached it at meiika?
Custom systems and our Growth & MarTech work are among the services meiika offers. To study a CRM, the starting point can be the journey of the data and how the team uses each record, before proposing another tool.
We do not claim to have achieved results for the distributor described. A specific proposal would need to know the objects, entry points and relationships that exist in your account. The priority is to keep the right information and reduce confusion, with rules that the business can understand and maintain.