Ask finance what a customer is and they'll say an account. Ask sales and they'll say a person. Ask your CRM and it'll give you twelve duplicates of something that might be the same entity spelled three different ways.
I used to think this was a semantic quibble. It's not. It's one of the most expensive operational problems in enterprise B2B, and almost nobody treats it with the seriousness it deserves.
"As Basic as We Can't Agree on a Customer Name"
In a recent conversation, the head of data engineering at a global biotech company said something that stuck with me. He manages a CRM with 800,000 contacts, a hybrid environment with both a CRM and an ERP system, and data coming in from over a dozen sources. His team has spent a decade trying to keep it coherent. And when I asked him what the core challenge was, he didn't talk about AI or integrations or tooling. He said: "The challenge is really as basic as we can't agree on what a customer name is."
Here's what he means. His company is technically B2B — transactions go through the ERP and get fulfilled at the account level. But the marketing is B2C. They talk to individual researchers, scientists, lab managers. Those individuals interact with the website, fill out forms, download content. Then the actual purchase happens through an institutional account.
So when someone in finance says "customer," they mean the account that pays the invoice. When a salesperson says "customer," they mean the person they're on the phone with. When marketing says "customer," they mean the email address that clicked through a campaign. The CRM tries to hold all three definitions at once. It can't.
Take a university like UCLA. In his system, it shows up as UCLA, U.C.L.A., UC Los Angeles, University of California-Los Angeles, University of California comma Los Angeles, and in the ERP, yet another abbreviated format. Each variant was created by a different source — a web form, a sales rep, a marketing import, a data vendor. None of them are technically wrong. None of them are reconciled. And nobody can answer: how much business do we actually do with UCLA?
It Gets Worse with Complex Ownership
We see the same problem in a different flavor when ownership structures are involved. In a conversation with a RevOps team at a large real estate software company, the challenge wasn't name variations — it was structural.
Their CRM hierarchy was built around legal entities. Trusts, holding companies, regional subsidiaries. Which makes sense from a compliance perspective. But that's not how their sales team sells, and it's not how their board thinks about the business.
A single real estate group might operate through multiple trusts, each owning a handful of regional agencies, each with its own branding and website. One trust has no obvious connection to another — different names, different registrations — but they're ultimately controlled by the same individual or holding company. The legal structure tells you nothing about the commercial relationship.
Their board kept asking a straightforward question: what does our total portfolio with this customer look like? Product mix, regions, spend. The data existed. But because the hierarchy was organized around legal filings rather than business reality, nobody could see through it.
Their RevOps lead put it simply: "We just use names as our main reference point, and that only gets you so far."
Why Entity Resolution Is Genuinely Hard
Entity resolution — figuring out that two records refer to the same real-world thing — sounds simple. Match on name, maybe address, done. In practice, it's one of the hardest problems in data management.
Names are ambiguous by design. Is a regional franchise office the same entity as the parent brand? For your marketing team, probably yes. For your finance team, absolutely not. Is the Arizona subsidiary the same as the national company? Depends on who's asking and why.
Hierarchies aren't trees — they're webs. Subsidiaries get acquired. Franchises change hands. A holding company dissolves and its assets get redistributed across three trusts. Public business registrations will tell you some of this, but the data is scattered across state and national databases, formatted differently in every jurisdiction.
And sources actively disagree. Your ERP uses one naming convention. Your CRM uses another. Your marketing platform uses whatever the prospect typed into a form at 2am. Third-party data vendors each have their own normalization rules — or don't. The result is that every system has a slightly different version of the truth, and reconciling them manually at scale is basically a full-time job that nobody has budget for.
What Fixing This Looks Like
You can't solve entity resolution with a one-time cleanup project. New records flow in daily. Ownership structures change. People move. The data drifts back the moment you stop paying attention.
At Salmon, we do entity resolution by researching the live web — public business registrations, company websites, regulatory filings, press releases. We identify that UCLA, U.C.L.A., and University of California-Los Angeles are the same entity and resolve them into a single relationship. We map franchise structures, holding companies, and subsidiaries into hierarchies that reflect how your business actually operates — not how the legal paperwork is filed.
And we keep doing it. When a new record enters your CRM, it gets resolved against what we already know. When an ownership structure changes, we catch it on the next verification pass. The hierarchy stays current because we're checking it against reality, not a database that was last updated six months ago.
The question "what is a customer?" should have one answer across your entire organization. If it doesn't, that's not a data hygiene issue. It's a revenue visibility problem — and it's costing you more than you think.
If your CRM can't give you a unified view of a customer relationship, we should talk. Get in touch.