March 2026 · 8 min read
Nobody Agrees on What a Customer Is
Before you build a dashboard, a forecast, or an AI agent, you need to answer a question most companies skip: what are the nouns? Entity design is the unglamorous foundation that everything else breaks without.
I was two months into a data management engagement when I asked the room a question I assumed had been answered years ago: “What is a customer?”
Eight people. Four definitions. One of them was arguably a definition of “account.” Another was a definition of “user” that only applied to one product line. The finance team counted customers by billing entity. The CX team counted them by support ticket originator. Marketing counted them by email address. Sales counted them by opportunity contact.
Everyone had a customer count. None of them matched. And every cross-functional report for the prior three years had been a negotiation about whose number to use, conducted informally over Slack, resolved differently each time, documented nowhere.
This is not a data quality problem. The data was clean. The pipelines ran. The warehouse was well-architected. The problem was upstream of all of it: nobody had agreed on what the nouns meant.
Why this gets skipped
Entity design is the least exciting work in data strategy. It does not produce a dashboard. It does not ship a model. It does not generate a demo that gets a standing ovation from the CMO. What it produces is a shared language, and shared language is invisible when it works and catastrophic when it does not.
Companies skip it for predictable reasons. The business wants outputs. The data team wants to deliver. Stopping to define “customer,” “order,” “product,” and “partner” in a way that every function agrees on feels like bureaucracy when there are dashboards to build and board decks to populate.
So the team builds on top of ambiguity. Each function develops its own implicit definitions, optimized for their use case, undocumented, and incompatible with everyone else’s. The divergence is invisible at first because each team is only looking at its own reports. It surfaces the moment someone tries to do anything cross-functional: a unified customer view, a lifetime value calculation, an AI model that needs to understand the relationship between a customer and their orders across channels.
That is usually the moment I get called in. Not because the technology failed, but because the foundation was never poured.
What entity design is
Entity design is the practice of defining the core objects in your business, their attributes, their relationships, and the rules that govern their lifecycle. It sounds like database modeling because it is adjacent to database modeling, but the audience is different. A data model serves the warehouse. An entity model serves the organization.
The difference matters. A data model can have a customer table with a technical definition that satisfies the schema. An entity model requires that the word “customer” means the same thing when the CFO uses it in a board meeting, when the CX team uses it in a retention report, and when an AI agent uses it to answer a question about churn.
The entities that matter in most businesses are not complicated. Customer. Product. Order. Partner. Location. Employee. Pipeline opportunity. The list is usually under fifteen. But each one needs three things that most organizations have never formalized.
A canonical definition that specifies the boundaries. When does a lead become a customer? When does a customer become inactive? Is a free trial user a customer? Is a churned account that returns a new customer or a reactivated one? These questions sound pedantic until you realize that every metric built on top of “customer” inherits the answer, and different teams inheriting different answers is how you get four customer counts in one room.
A canonical identifier that specifies how the entity is tracked across systems. If the CRM uses one ID, the billing system uses another, and the support platform uses a third, then “customer” is three entities pretending to be one. The identifier problem is usually where the technical debt lives, because resolving it means building an identity layer that most companies have deferred for years.
A relationship model that specifies how the entity connects to others. A customer has orders. Orders contain products. Products belong to categories. These relationships are the structure that makes cross-functional analysis possible without a two-week engineering ticket. Without them, every join is bespoke, every report is a negotiation, and every AI system that tries to reason across entities produces incoherent output.
The AI dependency most people miss
This is where entity design stops being a data governance exercise and becomes an AI readiness requirement.
Every AI system that interacts with your business data needs to understand what things are and how they relate to each other. When you ask an LLM to analyze churn risk, it needs to know what a customer is, what an order is, what the relationship between them looks like over time, and what “inactive” means in your specific context. If those definitions are ambiguous, inconsistent, or spread across twelve different tables with twelve different naming conventions, the AI does not produce bad answers. It produces confidently wrong answers, which is worse.
The companies that are getting value from AI in their analytics stack are not the ones with the best models. They are the ones with the cleanest entity definitions. The model is a commodity. The entity layer is the moat.
This is also why the “just connect an LLM to your database” approach fails so reliably. The LLM can read the schema. It cannot read the implicit tribal knowledge about what “active customer” means in the CX team versus the finance team. Without an explicit entity model, the AI inherits every ambiguity the organization has been quietly living with, and it surfaces those ambiguities as contradictions in its output.
I have seen this exact failure mode three times in the past year. Each time, the team blamed the model. Each time, the model was fine. The entities were the problem.
The relationship layer is where it gets interesting
Defining entities is necessary. Defining the relationships between them is where the real leverage appears.
Most organizations model entities as flat records. A customer is a row in a table with attributes. But a customer is not just a set of attributes. A customer exists in a web of relationships: they buy products, they interact with support agents, they belong to segments, they are managed by account teams, they have a history that changes their current context.
When you model those relationships explicitly, you create something more powerful than a data warehouse. You create an ontology: a formal representation of what your business knows about how things connect to each other.
This matters more than most data leaders realize, because the next generation of AI systems will not just query your data. They will reason over it. Agentic systems that monitor, detect patterns, and recommend actions need to understand not just what things are but how they relate and what those relationships mean. An agent that knows a customer’s order volume dropped 40 percent is marginally useful. An agent that knows the drop correlates with a change in their account team, a support escalation two months ago, and a contract renewal in six weeks is operating at a completely different level.
That level of reasoning requires a relationship model. Not a flat table. Not a join. A structured representation of how entities connect, what those connections mean, and how they change over time. That is ontology, and it is the foundation for everything that comes after the current generation of dashboards and reports. But that is a larger argument for a different post.
The practical path
If you are reading this and your organization does not have explicit entity definitions, the temptation is to launch a governance initiative with a steering committee and a twelve-month roadmap. Do not do that. Governance initiatives that start large die slow, political deaths.
Start with one entity. Pick the one that causes the most cross-functional friction. In most companies, that is “customer.” Get four people in a room: someone from finance, someone from CX, someone from sales, and someone from the data team. Define the boundaries, the lifecycle, and the canonical identifier. Write it down. Put it somewhere everyone can find it.
Then do it again with “order.” Then “product.” Each one takes a few hours if you keep the scope tight. Within a month, you have the core of an entity model that was never going to emerge from a twelve-month initiative.
The output is not a diagram. The output is that the next time someone asks “how many customers do we have,” there is one answer. And the next time someone tries to build an AI system on top of your data, it has a foundation that does not contradict itself.
The line
Every post in this series has circled the same claim: the hard part is not the technology. This is the most literal version of that argument. Before you build a dashboard, a forecast, a model, or an agent, you need to answer a question that most companies never formally ask: what are the nouns?
Entity design is where data strategy begins. It is also, I am increasingly convinced, where something much larger begins. But that is a different post.