Customer data matching: why records multiply

A customer called Halden Health is in the CRM as “Halden Health Inc.”, in NetSuite as “Halden Healthcare LLC” with a different billing address, in Zendesk as an organization named after its email domain, and in the product as three workspaces created by three of its teams. Each system is right about its own record. Ask how much Halden pays, how many tickets it filed last quarter and whether its usage is growing, and nobody can answer without a spreadsheet and an afternoon.

Matching is the first stage of a customer 360, and it’s the one to start with, because every later stage joins on it. Usage, support history, survey scores and health all assume the warehouse knows which records belong to the same customer.

What is customer data matching?

Customer data matching works out which records in different systems describe the same customer, and gives that customer one ID every system can point to. It’s also called identity resolution or entity resolution. A complete approach matches on several keys, decides which system’s value wins for each field, publishes one golden record with a stable ID, and sends genuinely ambiguous matches to a person.

Why one customer becomes four records

1. Each system creates its own record. Sales creates the account in the CRM, finance creates the customer in the ERP at booking, and the help desk creates an organization from the first support email. None of them shares an ID.
2. Names don’t match. Legal entity names, trading names, abbreviations and rebrands all describe the same company.
3. One customer has several entities. A parent with subsidiaries, regions billed separately, or an acquired company still on its own contract.
4. Matching runs on domain alone. It misses subsidiaries and rebrands that use other domains.
5. One system is declared the winner. The CRM has the best contacts and the ERP has the best legal entity and billing address, so a rule that one system always wins is wrong about half the fields.

What it costs

Every report built on unmatched records disagrees with the others. Finance’s revenue per customer, support’s ticket counts and the CSM’s usage chart describe three different sets of customers, and meetings start with an argument about whose number is right.

Every stage after matching inherits the problem. A health score built on one of four records sees a quarter of the usage. Reverse ETL writes the score to the wrong account, or to one of three. An AI agent asked about the customer answers confidently from whichever record it finds first.

What to fix first

1. Match on several keys, each with a confidence. Use the domain, the normalized legal name, the tax or registration number, the billing address and known parent and child links. Exact matches on strong keys merge automatically, and close matches go to review.
2. Choose survivorship per field. Take contacts from the CRM, the legal entity and billing address from the ERP, and plan and seats from billing. Record which source won each field.
3. Publish a stable customer ID and write it back. Store it on the record in every system, so joins use the ID instead of a name.
4. Model the hierarchy. Keep parent and child accounts as separate records linked to each other, so you can report at either level.
5. Keep a stewardship queue. Ambiguous matches go to a named person. Guessing is how two real customers end up merged.
6. Match new records when they’re created. A new customer in the ERP or a new organization in the help desk gets the ID on its first day, instead of at the next cleanup.

The guide to building a customer 360 and master data sync has the prompts for each step.

What centralizing it gave one finance team

A financial services company synced its Stripe payment records into Salesforce, so its teams could tell paid accounts from free ones and see retention by account. Its VP of Operations and Finance described the result:

“Tray.ai gave us efficiency by facilitating automation and centralizing info, so we could scale more quickly and focus valuable resources on more-strategic tasks across finance, operations, marketing, and customer success. It also gave us greater visibility into our business.”

Where matching fits

Every later stage joins on the ID that matching produces. CRM data reaches the warehouse keyed by it. Product usage, support history and survey responses attach to it, and the health score is calculated per ID. On the sales side, lead-to-account matching resolves new leads against the same accounts.

For why a single customer view rarely holds up once four teams need something different from it, read why the customer 360 never sticks.