Three salespeople are texting the same shopper

Two completely different failures produce this symptom, and the fix for one makes the other worse. Either deduplication never ran — the records were compared and did not match, usually because nothing normalised them first — or it ran, matched correctly, and lost the race, because assignment and notification had already fired on each record as it arrived. Loosening your matching rules fixes the first and does nothing for the second, while merging more aggressively is how you end up with 2 shoppers sharing one record.

So establish which one you have before changing a rule. It takes one export and about an hour, and the answer determines whether you are working on comparison logic or on ordering.

The check: normalise one week and count collisions

1. Export every lead and customer record created in one closed 7-day window: record id, created-at to the second, name, email, phone, source, assigned user.
2. Normalise the phone column to its last 10 digits, discarding spaces, brackets, dashes and any leading country prefix. Do this in the export, not in the CRM.
3. Normalise email to lowercase and trim whitespace. Do not strip anything else yet — provider-specific rules about dots and plus-tags vary, and guessing turns 2 people into 1.
4. Group by normalised phone. Every group with more than 1 record is a collision your CRM did not act on.
5. Read the created-at gaps inside each group. Gaps of days point at a matching failure; gaps of seconds point at simultaneous arrivals from different sources.
6. Count how many collision groups have more than 1 assigned user. That number is the size of the problem your salespeople are actually complaining about.
7. Finally, look for the opposite failure: records where the name changed materially in the record history, which is what a wrong merge looks like after the fact.

Four causes, and the evidence that confirms each

Comparison without normalisation is not matching

One shopper submits a number through a website form, a marketplace sends it with a country prefix, and someone at the desk types it with dashes. To an exact-match rule those are 3 different customers, and the CRM is behaving correctly. This is the most common cause and the cheapest to fix, and it is worth proving first because it costs nothing to test in an export.

• Strip to a comparable form. Digits only, then compare the last 10, which survives prefix and formatting differences without collapsing genuinely different numbers.
• Watch the short-number trap. Comparing on fewer than 10 digits starts matching unrelated people, and a rule that matches on the last 7 will eventually merge 2 real customers.
• Normalise the name for comparison only. Case, punctuation and a middle initial are noise; a name match is a supporting signal, never a decision.
• Capture the number in a clean shape at source. A form that validates and stores digits, as in wiring an enquiry form so nothing lives in an inbox, removes an entire class of duplicate before it exists.

The marketplace is deliberately hiding the shopper from you

Third-party listing sites often relay messages through an address they generate per enquiry, and some withhold the phone number entirely until the shopper responds. That is a commercial decision on their side, and it means the strongest key you have is absent by design. The same shopper enquiring through 2 marketplaces produces 2 records with 2 unique relay addresses and no phone, and nothing you configure in the CRM will match them.

There are only 3 honest responses. Ask the vendor whether unmasked details can be delivered on your account. Match on the weaker signals available — a name plus the same stock number within a short window — but route the result to a person rather than to an automatic merge. And accept that a residue of unmatched duplicates is the cost of that channel, because the alternative is a rule that merges strangers who both enquired about the same car.

Name plus vehicle is not a matching key. On a Saturday, two families enquiring about the same used car is a normal event, not a duplicate.

Assignment fired before anything checked for a duplicate

This is the cause behind the specific complaint in the title. The matching worked. Both leads arrived within a minute of each other from 2 sources, the CRM created a record for each because neither existed when the other was evaluated, and the routing rule assigned and notified before the merge step ever ran. By the time the deduplication job caught up, 2 people had already sent a text.

The fix is an ordering change rather than a rule change: evaluate the match, then assign. That means holding the lead for a short window before notifying anyone, and the window is a genuine trade-off you have to price. A 60-second hold costs 1 minute of response time and eliminates almost all simultaneous-arrival duplicates. A 10-minute hold eliminates the rest and is indefensible for anyone competing on first reply. Pick the shorter one, and be aware that a hold interacts with everything else in the intake path — including the queues described in half your enquiries arrive when the store is shut.

There is a second ordering failure worth checking while you are in here. When a match is found and the incoming lead is folded into an existing record, the new-lead notification usually does not fire at all, and if that record is owned by someone who is not in today the enquiry is invisible — the state described in the lead was assigned in nine seconds to a salesperson on holiday.

A matching-key policy you can defend to a manager

1. Normalised phone is the primary key. It is the one identifier a dealership reliably holds, uses to contact people, and can compare across systems.
2. Email, lowercased, is the secondary key. Weaker than phone because relay and shared household addresses are common, and stronger than any name-based comparison.
3. Two independent keys auto-merge. Phone and email agreeing is a match no human needs to review.
4. One key merges nothing. It creates a suggested match with both records intact, and a person decides. This is the rule that prevents the failure you cannot undo.
5. Name, vehicle and address never merge on their own, in any combination. They may raise a suggestion and nothing more.
6. Every merge is reversible for at least 90 days, with both source records retained and the merge event logged with its actor and its matched keys.

Fix in this order

1. Normalise at comparison time. One change, largest effect, no risk to stored data.
2. Move dedupe in front of assignment, with the shortest hold window your response-time target tolerates.
3. Add the suggested-match queue and give it an owner, because a queue nobody works is a slower way of doing nothing.
4. Instrument it: a weekly count of collision groups and of groups carrying more than 1 assigned user. Those 2 numbers tell you whether anything you did worked.
5. Only then consider a customer-matching service or a shared identity layer. That is a build, and the honest version of it is a small service the CRM calls — the kind of scope covered in our internal tools and operations work.

One boundary worth stating. This page is about lead-side duplication inside the CRM. The related and messier problem — the same person existing as a sales prospect in the CRM and as a service customer in the DMS, with neither system willing to concede the master record — is a different investigation, covered in the same customer twice in two systems. The underlying shape recurs across the store wherever one real thing carries 2 identifiers, including the parts counter version in the part arrived and nobody knows whose it is. The rest of this silo sits under lead response and follow-up, within our wider automotive retail and aftermarket work.

• lead deduplication
• CRM data quality
• identity matching
• lead routing