Want help applying this guide?Ask the DripTell team
A customer asks on Instagram, returns on WhatsApp, and later submits a form. If every conversation creates a lead, one person can become three records before sales replies once.
The fix is to identify the person before creating the sales record. Normalize reliable identifiers, search the existing customer and lead records, attach the new conversation when the match is certain, and send ambiguous matches to a short human review. Create a new lead only when the system has enough evidence that this is a new buying situation.
Identify the person before creating the lead
A conversation is an interaction. A contact represents a person, a lead represents potential buying work, and an opportunity represents a deal worth progressing. Treating every interaction as a new lead mixes those layers and makes ownership and reporting unreliable.
- 1Capture the interactionStore the inbound event and source before deciding whether it needs a new lead.
- 2Normalize identifiersStandardize reliable phone and email values while keeping the original for audit.
- 3Search existing recordsCheck contacts, active leads, and linked conversation history before creation.
- 4Choose one outcomeAttach exact matches, review uncertain pairs, and create only clear non-matches.
- 5Audit the resultVerify ownership, consent, next actions, and automation after every merge or rule change.
Start with identifiers that the customer actually supplied. For WhatsApp, that may be a normalized international phone number. For a form, it may be a verified email address. Instagram can provide a channel identity, but that identity should not be silently assumed to be the same person as an email or phone contact without a linking event or human confirmation.
Normalize before matching. Remove formatting differences from phone numbers, standardize email case, and keep the original value for audit. Do not match on a display name alone because names, phones, and role inboxes can be shared.
Microsoft explains that duplicate-detection rules compare match codes built from fields such as email and name. It also warns that records processed simultaneously can still duplicate and recommends scheduled detection jobs as a second check in its duplicate detection guidance.
A reliable conversation inbox should therefore feed one identity decision rather than letting each channel invent its own customer.
Use three outcomes instead of one match rule
Real customer data is too messy for a binary rule, so use three outcomes. An exact match attaches to the existing record. A possible match waits for review without launching outreach. A clear non-match creates a record with its source and consent evidence.
| Match outcome | Evidence example | Safe record action | Follow-up state |
|---|---|---|---|
| Exact match | Same normalized verified phone or email | Attach the conversation to the existing contact and active lead | Keep the current owner and next action |
| Likely match | Similar name and company with one differing identifier | Hold for human review | Do not start a second sequence |
| No match | Different reliable identifiers and no linked history | Create a new contact or lead | Assign one owner and next action |
| Shared identity | Household phone or role email used by several people | Keep separate people with an explicit shared relationship | Require confirmation before personal outreach |
This is a policy, not a universal formula. Define reliable identifiers for each channel, test real edge cases, and show the decision reason.
This decision should happen before a lead qualification workflow. Qualification asks whether the buying need is worth progressing. Deduplication first asks whether the record already exists.
Prevent two automations from winning the same race
Searching before creation is not sufficient. Two events can search together, both see no record, and both create one when a form follows a message or a webhook retries.
Give each inbound event an idempotency key so a retry cannot create the same work twice. Make the normalized strong identifier unique where business rules allow it. Perform the final lookup and creation as one controlled transaction. If another event wins, attach to its record.
Keep the channel event even without a new lead because the contact belongs in the history. This differs from preventing duplicate outbound messages, although both controls should work together.
Do not let the matching service send a campaign, assign a salesperson, or advance a stage. Its job is narrower. It resolves identity and hands one record to the next process. That separation makes retries safer and failures easier to diagnose.
Merge carefully when prevention fails
Duplicates still appear through imports, manual entry, changed numbers, and older integrations. Choose a primary record using a published rule. Preserve the earliest source, current consent, conversation history, open tasks, active opportunity, owner, and next action. Pause overlapping automations before merging, then verify no second follow-up remains.
Microsoft documents that a merge keeps the primary record, deactivates the secondary, and links selected data and activities to the primary in its record merge guide. Support varies by record type and workflow, so test your actual creation paths.
Never auto-merge an ambiguous pair just because the names look alike. A false merge can expose one person's history to another, misroute a seller, or overwrite a valid consent decision. A short review queue is cheaper than repairing a mistaken identity.
Measure the workflow without hiding the misses
Count duplicates by source across forms, imports, WhatsApp, Instagram, manual entry, and API. Track automatic exact matches, reviewed cases, false results found later, and review time.
Also check what happened downstream. Did two salespeople contact the same person? Did a merge restart a sequence? Did the lead qualification rate change because duplicate records entered or left the denominator? A clean-looking database can still have a broken operating process.
The useful design for CRM and lead records is one customer history with source, consent, owner, stage, and next action kept together. A broader sales workflow can then qualify and follow up without asking the customer to repeat the same story.
Review a sample of matches every week and feed the mistakes back into the rules. The goal is not zero warnings. It is one accountable decision for each real person and buying situation.
Frequently Asked Questions
Should the same phone number always mean the same customer
No. It is a strong signal, but family numbers, shared business phones, reassigned numbers, and data-entry mistakes exist. Use the relationship context and require review when the identity is uncertain.
Should a returning customer create a new lead
Not merely because they started a new conversation. Create new buying work only when there is a distinct need or opportunity. Keep the person and their history on the existing contact record.
Can duplicate detection happen after assignment
It can, but that is late. A second owner or automated sequence may already have started. Run the strongest check before creation and assignment, then use scheduled checks to catch what the first gate missed.
What should happen to an ambiguous match
Hold it in a named review queue with the evidence and a deadline. Do not merge, create a second outreach sequence, or discard the conversation until a person resolves the identity.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy