How do you match the same customer across the field service system, call tracking and the CRM?
Normalize first, then match in tiers. Convert every phone number to a single canonical format, standardize addresses, and lowercase emails. Then match on exact email, then exact phone, then phone plus address, then fuzzy name plus address. Record which tier produced each match and never merge records automatically below your top tiers — a wrong merge is much harder to undo than an unmatched record.
Normalization does more work than matching does
Most match failures are formatting failures. The same phone number appears as a ten-digit string, a formatted string with parentheses, and an international format with a country code. The same house appears with Street, St, and St. plus a unit number in three different places. Before any comparison logic runs, everything should be reduced to one canonical form.
For phone numbers that means stripping to digits and applying a consistent country prefix. For addresses it means a standardization pass, ideally against a postal reference, producing a stable key. For emails it means lowercase and trimming. Doing only this typically resolves the majority of the records that looked unmatchable.
Match in tiers and keep the tier
- Tier one: exact email. High confidence. Safe to merge.
- Tier two: exact normalized phone. High confidence for businesses with mostly residential customers, lower where a property manager's number sits on many accounts.
- Tier three: phone plus normalized address. Strong, and the workhorse tier in home services.
- Tier four: name plus address without phone. Suggestive only. Queue for review; do not auto-merge.
- No match. A legitimate outcome. Keep it visible as its own bucket.
The two errors, and why they are not symmetric
A false negative leaves one person as two records. You under-count repeat business and over-count new customers. Annoying, correctable, and visible.
A false positive fuses two households into one. Now service history, marketing consent and possibly billing information are blended, and unwinding it after months of activity is genuinely painful. Because of that asymmetry, the correct bias is toward leaving records separate. Any resolution system should also store the source record IDs so a merge can be reversed, which is a design requirement we hold in every data integration we build.
The cases that break naive matching
Shared numbers in multi-unit properties, adult children calling on a parent's behalf, landlords versus tenants at the same address, and businesses using one main line for dozens of sites. Each of these produces a technically correct match that is operationally wrong.
The practical mitigation is to model the property as a separate entity from the person. Home services work happens at an address; the person who called is a contact for that address. Once the data model separates the two, most of these cases stop being ambiguous. That separation is also what makes customer intelligence useful at the household level rather than the phone-number level.
Topics: identity resolution · data matching · CRM · integration
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.