Why “Customer” Does Not Mean the Same Thing Everywhere

The word “customer” has no single meaning in a company. Each department uses it for a different thing. If your data platform treats it as one thing, some of your numbers are wrong, and nobody can say which.

This post shows where the meanings split, why a single customers table causes harm, and what I build instead.

The same word, different things

Take a B2B software company. Ask four teams what a customer is.

• Sales: a company that signed a deal. The record lives in the CRM. It is an account.
• Finance: whoever receives the invoice and pays it. The record lives in the billing system. It is a billing entity, and it may be a parent company, a subsidiary or a reseller.
• Support: a person who opens tickets. The record lives in the help desk. It is a contact, and it may belong to an account that never signed anything.
• Product: a workspace or tenant that logs in. The record lives in the application database. It is a tenant.

None of these people is wrong. Each definition fits the work that team does. The problem starts when the data meets.

How a shared word breaks a join

Someone wants revenue per customer. They join billing to the CRM on company name, because both tables have a column called customer_name.

SELECT c.customer_name, SUM(i.amount) AS revenue
FROM crm.customers c
JOIN billing.customers b ON b.customer_name = c.customer_name
JOIN billing.invoices i ON i.customer_id = b.id
GROUP BY c.customer_name;

This query runs. It returns numbers. It is wrong in at least three ways:

• Names differ between systems (Acme Ltd, ACME Limited), so some rows drop out of the join.
• One CRM account may have several billing entities, so revenue lands on the wrong row or is counted twice.
• Two different accounts may share a name, so their revenue merges.

No error appears. The dashboard looks fine. Two teams then report two different customer counts and argue about whose number is right. Both are right for their own definition.

Do not force one definition

The usual fix is a meeting to agree on “the” definition of customer. It rarely holds. Either the agreed meaning fits one team and breaks the others, or it becomes so vague that it means nothing.

I take another route. Keep the meanings apart, name each one, and connect them on purpose.

1. Name each concept for what it is

Stop using the bare word in table names. Use account, billing_entity, contact and tenant. Each one gets a short written definition: what counts, what does not, and who owns it.

2. Model each concept in its own context

Each source system keeps its own model. Do not merge them early into one wide table. Staging models clean and type the data, and they keep the source meaning intact.

3. Write the mapping down

The link between concepts goes in an explicit mapping table.

CREATE TABLE mapping.account_billing_entity (
  account_id        TEXT NOT NULL,
  billing_entity_id TEXT NOT NULL,
  match_method      TEXT NOT NULL,  -- 'manual', 'tax_id', 'domain'
  valid_from        DATE NOT NULL,
  valid_to          DATE,
  owner             TEXT NOT NULL
);

Now a join goes through the mapping. The match method is visible. The owner is named. A wrong match can be fixed in one place, and the fix carries into every report that uses it.

4. Let a metric say which concept it counts

“Customers” becomes “active accounts” or “paying billing entities”. The metric name tells the reader what is being counted. Two numbers that differ no longer look like a bug.

What this buys you

• Joins that fail loudly. A record with no mapping shows up as unmapped instead of vanishing.
• Numbers that reconcile. You can explain why sales and finance differ, line by line.
• Changes that stay local. When billing is replaced, you update one mapping, not every dashboard.
• Better inputs for AI. A workflow that reads your data needs to know which “customer” a question means. A named concept with a mapping gives it that. A bare word gives it a guess.

Who this is not for

If you run one system and one team, and everyone already means the same thing by customer, you do not need this. A single table is fine. Add the mapping layer when a second system or a second meaning appears, not before.

Check your own platform

The quickest test: pick one number that two teams report differently, and trace both back to source. You will usually find two definitions behind one word.

To review the wider platform, the free Data Platform Teardown gives you a checklist you can run yourself, with no sign-up.