By KYN AI Advisory Team — AI implementation specialists, Singapore
Clean the CRM before you connect an agent to it. An agent reads every record as true, so a duplicate becomes two conversations, two follow-ups and sometimes two quotes to the same buyer. The fix is a short sequence: back up, choose match keys, merge by written rules, log every merge, and stop new duplicates at entry. Plan one to three weeks for a CRM of a few thousand records, most of it spent on decisions, not on tooling.
Why do duplicates hurt more once an agent is involved?
A person who sees "Tan Wei Ming" twice knows it is the same man. An agent does not, unless a rule says so.
What goes wrong:
- Double outreach. Two records, two sequences. The buyer gets the same pitch twice in a week.
- Split history. A reply logged on record A never reaches record B, so the agent proposes a first touch to a contact who already said "not now".
- Wrong counts. Pipeline, win rate and response rate are all computed over records. Duplicates inflate the denominators.
- Unsubscribe leaks. A person opts out on one record and keeps receiving mail on the other. This is also a legal exposure: see the Spam Control Act 2007 for Singapore's rule on unsolicited commercial email.
We describe the wider problem in fragmented CRM and sequencing tool stacks and why warm leads go cold.
Step 1: What do you back up first?
Export every object: contacts, companies, deals, notes, activities. Save the files with a date. Store a copy outside the CRM. A merge cannot always be reversed from inside the tool, and you want a record of what each field held before.
Count what you have: records per object, records with no email, records with no company, records created by import. These counts become your before-and-after measure.
Step 2: Which fields define a match?
Pick match keys by object. Do not match on a name alone.
| Object | Strong key | Weak key (needs a second signal) | |---|---|---| | Contact | Normalised email | Name plus company; phone number | | Company | Registered number (UEN in Singapore) | Normalised legal name; website domain | | Deal | Company plus product plus open date window | Deal name |
Normalise before comparing:
- lower-case emails and strip spaces;
- phone numbers to one format with the country code (+65, +852, +62, +60);
- company names: drop "Pte Ltd", "Sdn Bhd", "PT", "Limited", punctuation and case;
- domains: strip "www." and the path.
A strong key match is safe to auto-merge. A weak key match goes to a review queue. Two "Lim Hui Min" at different companies are different people.
Step 3: How do you merge without losing data?
Write the merge rules before you merge a single record. The usual conflicts:
- Which record survives? The oldest, or the one with the most activity. Pick one rule and apply it.
- Which field wins on conflict? The most recently updated value, except for fields a person typed by hand, which beat imported values.
- What happens to activity? All notes, emails and tasks move to the survivor. Nothing is deleted.
- What about consent flags? Take the most restrictive. If either record is opted out, the merged record is opted out.
- Who owns the record? The owner of the survivor, unless the other record has an open deal with a different owner. Then a person decides.
Run the merge on a copy first. Compare the counts. Review 50 merged records by hand.
Step 4: How do you keep a trail?
Write one line per merge to a log: the date, the keys that matched, the surviving record ID, the absorbed record ID, and who or what approved it. This is the audit record. When a salesperson asks where a contact went, you can answer in a minute.
Keep absorbed IDs in a redirect table. Old links, imports and integrations that still point at the absorbed ID can then resolve to the survivor.
Step 5: How do you stop duplicates coming back?
Cleaning once is wasted if the intake leaks. Fix the sources.
- Forms and WhatsApp enquiries. Check for an existing record by email or phone before creating one. If found, attach the enquiry to it.
- Imports. Run every import through the same match keys. Reject or queue rows that match.
- Sync between tools. Pick one system as the source of truth for each field. Two tools writing the same field creates conflicts every night.
- Agent writes. An agent that finds a new contact must search before it creates. Give it a "find or create" action only, never a bare "create".
Schedule a weekly duplicate report. Zero is the target. A rising count points to a leak.
How do you check the CRM is ready for agents?
Before connecting an agent, confirm:
- duplicate rate under your tolerance (set it, for example 1% of contacts);
- every contact has an owner and a consent status;
- every company has a country and a domain or registered number;
- a stage definition exists for each deal stage, in writing;
- the agent has its own restricted account, not a salesperson's login.
If any of these fail, fix them first. Agents amplify whatever data they are given.
What does a duplicate look like in practice?
Three illustrative pairs show why match rules need tiers. The names are invented.
| Record A | Record B | Same person? | Rule | |---|---|---|---| | wei.ming@tanlogistics.sg | WEI.MING@TANLOGISTICS.SG | Yes | Normalised email matches: auto-merge | | Lim Hui Min, Alpha Foods | Lim Hui Min, Beta Packaging | Unknown | Name matches, company differs: review queue | | +65 9123 4567 | 91234567 | Yes | Phone matches after normalising: review, then merge |
The second pair is the trap. Two people can share a name. A rule that merges on name alone destroys a real contact, and the loss is hard to see later.
Set aside a review queue with a daily limit, for example 50 pairs, so the owner clears it in one sitting. Show both records side by side with the matched keys highlighted and three buttons: merge, keep both, not sure. Log "keep both" decisions so the same pair is not raised again next week.
Measure the clean-up with the counts from Step 1: records before, records after, merges by rule, pairs sent to review, pairs kept apart. Those five numbers are the report you hand to the CRM owner.
Where KYN fits
KYN builds the match rules, the review queue and the merge log as part of the sales system, in your own cloud account. Agents write through find-or-create actions, run under their own restricted accounts, and every action is logged with the actor. Deletions and bulk merges wait for a named person. For a manufacturer, we moved 10,210 vendor quotes and a ledger of 3,309 reconciled rows with zero duplicates.
The first 14 days are a review of your CRM export and the merge habits of whoever owns it. A full build, including the match rules and audit log, ships in under 90 days. See sales systems and integrations.
Frequently asked questions
Can an AI agent deduplicate the CRM for me?
It can find candidates and rank them by match strength, which is slow work for a person. The merge itself should follow written rules, and weak matches should reach a person. An agent that merges on its own judgement is a risk to your history.
How many duplicates are normal?
It varies by how many sources feed the CRM. Count yours first. A rate you can name, such as 4% of contacts, lets you track whether cleaning and intake fixes work.
Should I delete old contacts while cleaning?
Archive, do not delete, unless a legal reason requires deletion. Mark the status and the date. Deletions of personal data should wait for a named person and follow your retention policy.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
