Two numbers, one question
Quarterly review. Sales says the company has 4,200 customers. Finance says 3,100. Support says 5,800.
Nobody is wrong. Yet the meeting turns into an argument about whose number is right, and the real decisions wait.
The problem isn't data quality. It's that "customer" means three different things, and nobody wrote down which is which.
The word is shared. The meaning is not.
Each team is counting something different:
| Team | What "customer" means to them | Why it makes sense for that team |
|---|---|---|
| Sales | Any company with an open or won deal in the CRM | Sales tracks relationships, including ones not yet paying |
| Finance | A legal entity that paid an invoice in the last 12 months | Finance cares about who owes money and who has paid |
| Support | Every person who has raised a ticket | Support serves individuals, not companies |
Every definition makes sense at home. The trouble starts on the shared slide: the label travels, the meaning stays behind.
And it isn't only "customer." Try product, order, revenue, or active user.
Why this happens
Every system is set up by the team that uses it, in that team's words. Add years of mergers, new regions and new tools, and meaning ends up in people's heads and in settings nobody remembers.
Inside a team, everyone shares the context. Across teams, it's gone.
A real case: when a number lost its meaning
In 1999, NASA lost the Mars Climate Orbiter, a spacecraft reported at about $125 million (CNN, via De Anza College). One team's software sent thruster data in English units. The navigation software read it as metric, as the specification required (NASA Mishap Investigation Board, Phase I Report).
Every number was correct. Its meaning didn't travel with it. Your customer count fails the same way, only more quietly.
What it costs
- Hours lost reconciling reports that never match.
- Decisions on the wrong figure, like hiring for 5,800 customers when 3,100 pay.
- Integrations that drag on because data is misread between systems.
- Lost trust. Once people stop believing dashboards, every data initiative starts on the back foot.
"But we already have a business glossary"
Glossaries and warehouse semantic layers help. They don't close the gap.
- A glossary records words, not how they relate. It ends up with one definition two teams ignore, or "Customer (Sales)" beside "Customer (Finance)" with nothing linking them.
- It describes columns, not the business. It can't tell you that Acme in the sales system and Acme in the finance system are the same company.
- A semantic layer stores one team's choice, in one platform. The systems outside it keep their own meanings.
The tools aren't the limit. The approach is: a list of definitions is not a shared model.
Why AI agents raise the stakes
Ask an agent to "send renewal offers to customers whose contracts end next quarter." It must decide what customer means, match records across sales and finance, and judge whether two Acmes are one. Without agreed meaning, it guesses, silently.
- It doesn't ask. People question numbers that disagree. Agents carry on.
- Errors compound. Count prospects as customers, and offers go to companies that never paid.
- It sounds right. Fluent, confident, and counting the wrong thing.
A smarter model won't fix this. An agent needs context it can act on: clear rules, connected concepts, and a way to tell when two records are the same thing. That is what an ontology provides.
Making meaning explicit
Picking one "official" definition rarely works. Sales still needs prospects, and support still needs people. Instead, give each meaning its own name and say how they connect:
- Organization: a company we deal with.
- Prospect: an organization with an open deal and no paid invoice.
- Paying customer: an organization that paid an invoice in the last 12 months.
- Contact: a person who works for an organization.
That agreed set of things and how they relate is an ontology. It isn't software. It's a shared agreement, precise enough for both people and systems to follow.
One word, three meanings, no collision
An ontology stops treating the word as the meaning. Each meaning gets its own identity, and "customer" becomes just a label. Context, such as the team or system, decides which meaning applies.
- The sales customer is an Organization with a deal.
- The finance customer is a Paying customer.
- The support customer is a Contact.
Because all three are built on shared concepts, they meet at Organization. And a record that claims to be both a person and a company gets flagged, instead of quietly inflating a count.
Each unit keeps its own word, and all point to one shared concept
Sales (CRM) calls it "account" and Finance (ERP) calls it "bill-to customer"; both map to Organization. Support (help desk) records a person, the "requester", which maps to Contact. In the shared ontology, a Contact works for an Organization, two Organizations are the same if their official IDs match, and an Organization can hold the roles Prospect (open deal, no paid invoice) and Paying customer (invoice paid in the last 12 months).
What makes it hold across the business
- Connected concepts. Contacts work for organizations; orders and invoices belong to them. That's what lets a question cross teams.
- An identity rule. An official registration number, or similar, decides when two records are the same company.
- Readable by systems. Written in a formal structure, so software can check the data against it. NASA's specification existed; nothing enforced it.
- One model, owned parts. Finance owns Paying customer, Sales owns Prospect, and everyone builds on Organization.
Back to the quarterly review
No winning definition. One shared model, with a place for every meaning.
Prospects, paying customers and contacts sit on one slide, each labeled, each traced to the same organizations. The meeting gets back to the business.
And the AI agent stops guessing. It answers from the meaning the business agreed on.
