How do you know a record in one system is the same customer as a record in another?
You match in priority order and record which rule fired. An explicit shared identifier is best. Then normalized phone number, then email, then address plus name similarity. Each step is weaker than the one before. A responsible matcher keeps unmatched records visible instead of guessing, and never merges two customers just because they share a household phone number.
The ladder of identifiers
Every match rule has a different error rate, and treating them as equivalent is what produces merged customers who are not the same person.
- A shared key. If the CRM stores the field service system's customer id, use it and stop. This is the only rule that is not a guess.
- Normalized phone. Strong for service businesses, but shared across households, businesses and property managers.
- Email. Reliable when present, frequently missing or entered as a placeholder by a dispatcher in a hurry.
- Address plus name. Useful for repeat service at the same property. Fails on apartment units, renters and recently sold homes.
Normalization does most of the work
Before any comparison, values have to be made comparable. Phone numbers reduce to digits in a single canonical format so that a number typed four different ways is one value. Emails get lowercased and trimmed. Addresses get parsed consistently, with unit numbers preserved rather than discarded, because dropping the unit is what merges an entire apartment building into one customer.
Most matching problems that look like algorithm problems are normalization problems. Fix the formatting and the match rate improves more than any clever scoring will deliver.
Two errors, not one
A false split creates two records for one person. It is annoying, visible, and easy to fix later. A false merge combines two different people into one record. It is quiet, it corrupts history, and it is very hard to undo once downstream systems have referenced the merged id.
Because the errors are not symmetric, matching should be tuned conservatively. Leaving something unmatched and reporting it as unknown is better than a confident wrong join, especially when the result feeds customer intelligence or a marketing suppression list.
Keep the reason, not just the result
Store which rule matched, when, and how confident it was. That single column turns identity resolution from a black box into something you can audit, tune, and explain when somebody asks why two records were combined.
It also lets you report the match rate honestly. Any attribution or marketing analysis that depends on joining ad data to operational records should publish the share it could not match, rather than distributing the unmatched portion invisibly across the sources it did match.
Topics: identity resolution · matching · customer data · deduplication
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.