Can we just use phone number to match customers across systems?
Use it as a strong signal, never as the key. Numbers get reassigned, shared across a household or an office, formatted five different ways, mistyped, and changed when someone switches carriers. Matching on phone alone merges unrelated customers and splits real ones. Generate your own stable internal identifier, attach the phone as one of several identifiers on that record, and store how confident the match was and what evidence produced it.
Every natural key eventually stops being unique
A primary key needs three properties: it identifies exactly one thing, it never changes, and it always exists. Phone numbers fail all three. Carriers recycle disconnected numbers within months. People port numbers and change them. Some customers give a number they do not answer, and some give none at all.
The same reasoning rules out email address and service address. An address identifies a property, not a customer, which matters enormously when a rental changes tenants or a property manager books work at forty addresses from one line.
Where phone matching goes specifically wrong in service businesses
- Shared business lines. A property management office, an HOA or a builder books work for many households from one number. Match on phone and they collapse into one customer with an implausible service history.
- Households. A landline shared by two adults with different names is two contacts, one number.
- Recycled numbers. A new customer inherits the previous holder's history, including their notes and their do-not-service flag.
- Formatting. Digits, dashes, parentheses, leading country code, an extension appended after a comma. Four representations, four "different" customers.
What to do instead
Mint your own identifier — an opaque internal id that means nothing and never changes. Hang identifiers off it: phone numbers as a list, not a field; email addresses as a list; service addresses as a list with dates. A customer is then a hub with evidence attached rather than a row keyed on something fragile.
Match on combinations, weighted. Phone plus surname is far stronger than phone alone. Address plus surname catches the customer who switched numbers. Nothing should auto-merge on a single weak signal, and anything below your confidence threshold should be proposed for human review rather than applied.
Keep the evidence so merges can be undone
Store which identifiers matched and with what score at the moment the merge happened. Merges are irreversible without that record, and you will need to reverse some — the recycled-number case guarantees it.
This is the unglamorous foundation under customer intelligence. Lifetime value, repeat rate and reactivation targeting are all computed per customer, so a matching layer that over-merges inflates every one of those numbers, and a layer that under-merges makes loyal customers look new. Getting it right is a core part of data integration rather than an afterthought.
Topics: identity resolution · data model · primary keys · data quality
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.