agent failed to detect duplicate accounts across two CRMs
Fixes an agent failing to detect duplicate accounts across two CRMs by matching on multiple strong identifiers with a human-reviewed merge queue. Use when two CRMs hold overlapping account sets. Not for merging the CRMs themselves, which is a migration project.
TL;DR
Duplicates across CRMs survive single-key matching because each system holds different identifiers. Match in tiers (exact domain plus name, billing id, website, address), score candidate pairs, auto-link only the certain tier, and send the ambiguous tier to humans with the evidence side by side. The agent's job is detection with proof, not silent merging.
agent failed to detect duplicate accounts across two CRMsUse this when
- The same companies appear in both CRMs with different ids and spellings
- Reports double-count accounts and pipeline
- One CRM came from an acquisition or a team split
Not for this skill when
- Overlap is tiny and a manual spreadsheet pass suffices
- A single shared identifier already exists and just needs enforcing
Steps
- Profile both account sets: counts, and which identifiers each actually populates. Verify: the usable matching keys per system are known
- Run tiered matching: strong keys first (domain, billing id), then fuzzy name plus address. Verify: candidate duplicate pairs are produced with a match tier per pair
- Measure precision on a labelled sample of pairs per tier. Verify: each tier's trust level is evidenced, not assumed
- Auto-link the high-precision tier, and queue the ambiguous tier for human decision with evidence shown. Verify: certain duplicates are linked and uncertain ones get human judgement
- Add duplicate prevention at creation: search-before-create checks in both systems for new accounts. Verify: the duplicate population stops growing while the backlog drains
Variant phrasings
duplicate accounts across two CRMs
A related phrasing for the same underlying problem.
cross system account matching
A related phrasing for the same underlying problem.
same company two CRM records
A related phrasing for the same underlying problem.
Compatibility: Compatibility: dual CRM estates (Salesforce plus HubSpot) with warehouse or agent-based matching, current versions.
Why it happens
Cross-system identity has no master key, so matching is evidence-weighing. Tiered keys with measured precision let automation handle the obvious 80 percent safely while humans spend their judgement only where evidence genuinely conflicts.
Edge cases / pitfalls
- Domains lie for subsidiaries and franchises. Treat domain as strong evidence, not proof, below the top tier.
- Never merge records as a side effect of detection. Linking preserves both systems' history; merging is a governed business decision.
- Keep the match evidence with the link. When a link is later disputed, the evidence is the whole conversation.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_ShGteAgLK9AgQdTFYWqSXQ