Duplicate records rarely get treated as urgent, because nothing breaks visibly. What actually happens is slower and more corrosive: two reps call the same lead, a customer's true exposure is split across three accounts so credit checks pass when they should not, reporting undercounts conversion because the same buyer appears twice, and automation fires against the wrong copy.
By the time someone says "I don't trust the CRM numbers", the cause is usually this.
First, decide what "the same" means
Every deduplication project stalls in the same place: two records that might be the same organisation. Different spellings, one with a branch address, one with a group email.
You need a written match rule before you touch anything. In practice:
- Contacts and leads: email is the strongest single key, but many B2C and field-sales businesses have contacts with no email at all. Phone number, normalised to a consistent format, is usually the better primary key there — it is what we used for the WhatsApp lead matching in our D2C engagement.
- Accounts: a registration or tax number beats a name every time. Company names are entered inconsistently and change; registration numbers do not.
- Patients, students, members: a composite — phone plus date of birth, for example — as in the cross-branch patient matching for our clinic group.
Write the rule down, including the tie-breaker for which record survives a merge. Usually: the oldest record wins the ID, the newest data wins the fields, and everything else is preserved as a related activity.
Clean up in the right order
1. Standardise before you match. Normalise phone formats, trim whitespace, lowercase emails, and standardise country and state values. A surprising share of "duplicates" only become visible after this step, and another share stop looking like duplicates once the data is consistent.
2. Handle the obvious matches in bulk. Exact email or phone matches with the same name can generally be merged with a reviewed rule.
3. Queue the ambiguous ones for a human. Same company name at different addresses, same phone at different names. These need judgement — often from the rep who owns the account, not from whoever is running the cleanup.
4. Deal with the long tail deliberately. There will be a residue you cannot resolve confidently. Flag it rather than guessing. A record tagged "possible duplicate, unresolved" is honest; a wrong merge is a data loss you will discover months later.
Then configure so it does not come back
Cleanup without prevention buys you about two quarters. The prevention side is mostly configuration:
Unique fields. Mark email or your chosen key as unique on the module. This is the single highest-leverage setting, and it is off by default.
Duplicate check rules on import. Every import should match on your key and update rather than create. The most common source of mass duplication is a well-intentioned spreadsheet import by someone who chose "add as new".
Guard the entry points. Web forms, marketing campaigns, chat widgets, and API integrations each create records. Every one of them needs the same matching logic, or your cleanest module gets polluted through the least-governed door. Where a channel cannot check reliably, route its records into a staging queue instead of straight into the live module.
Validate at the source. A phone field that accepts any string will receive every format anyone can type. Validation at entry costs a little friction and saves the normalisation pass entirely.
Give it an owner and a rhythm
Data quality without an owner decays by default. What works in practice is modest:
- A named owner — usually the CRM admin — accountable for the state of the data, not just the configuration.
- A monthly duplicate report reviewed as a short task, not an annual project. Ten minutes a month prevents the next cleanup.
- A rule for reps: search before creating. This sounds trivial and is the single behaviour that matters most at the point of entry. It also has to be fast — if search is slow or the layout hides it, reps will create.
- A quarterly check on entry points, because new integrations, forms, and campaigns appear without anyone revisiting the matching logic.
What good looks like
You will not reach zero duplicates, and chasing zero is not a good use of anyone's time. What you want is: the key modules have a unique key enforced, every entry point matches against it, ambiguous cases are flagged rather than guessed, and someone looks at the exception list monthly.
At that point, reporting starts being trusted again — which is the actual goal. Duplicates are not a tidiness problem; they are why the numbers are wrong.
If your Zoho CRM has accumulated years of duplicates and you are not sure whether to clean up or start from a re-import, tell us what you're working with — the answer depends on how much history is genuinely worth keeping, and that is worth a real conversation.