When Customer Stopped Meaning Customer

[#1]

David thought the problem was solved.

A few weeks earlier, a quarterly dashboard had exposed something uncomfortable: three teams were using the word Customer to mean three different things. Sales used it for companies with an active commercial relationship. Product used it for organisations already using the service. Support included companies still going through onboarding because, from their point of view, they were already customers.

The numbers had looked consistent. The definitions were not.

So the teams did what sensible teams do. They agreed on a definition.

Priya documented it. Emma updated the project template. David checked the reports. For a while, everything looked cleaner.

Then Noah joined the company.

He had been there for eleven days when Emma asked him to prepare a simple analysis of active customers. Nothing particularly ambitious. He needed a list, some basic context, and a few numbers for a planning session later that week.

Noah searched Confluence.

He found a recent Product page using the new definition of Customer. He found an older Sales page where the same field still included late-stage opportunities. He found a Support page using the phrase Customer account for organisations that had started onboarding but were not yet paying.

None of the pages looked obviously wrong. So Noah did something completely reasonable.

He asked Rovo. The answer was excellent.

Clear, concise, well structured and apparently supported by the information already stored in Confluence.

There was only one problem. Emma recognised three companies that should not have been on the list.

David checked the properties. Priya opened the page where the agreed definition had been documented.

The definition was still there. The organisation had simply continued evolving around it.

A definition does not freeze reality

It is tempting to think that consistency is solved once everyone agrees what a field means.

Sometimes it is, for a while.

But organisations are living systems.

Teams create new templates. Old pages remain in circulation. Processes change. New tools appear. People copy existing pages rather than starting from the latest template. Departments inherit terminology from systems they used before. Acquisitions introduce completely different vocabularies.

And slowly, almost invisibly, meaning starts to drift.

The interesting part is that the individual pieces of information can still look perfectly reasonable.

A page may contain:

Customer: Northwind

Nothing about that value looks suspicious. The question is what Customer means on that particular page.

• Is Northwind evaluating the product?
• Has it signed a contract?
• Is it already using the service?
• Is it an account that Support has started working with?

The visible value does not tell us. The context does.

Structured information still depends on shared meaning

We have become much better at structuring information in Confluence.

Templates help teams create consistent pages. Content Properties and Page Properties make information reusable. Databases give us another way to model structured information. Reporting tools can aggregate that information into useful views.

All of that matters.

But structure and meaning are not the same thing.

A field can exist everywhere and still mean something different depending on who filled it in.

The same status can represent different stages.

The same owner field can refer to an approver in one team and an operational owner in another.

The same word can slowly acquire several definitions without anyone consciously deciding that it should.

This is one of the strange things about organisational knowledge.

We tend to notice when information disappears.

We are much worse at noticing when its meaning changes.

AI makes this more visible, not less

There is another reason this matters more now.

For years, people reading Confluence provided a hidden layer of interpretation themselves.

An experienced employee might open an old Sales page and immediately understand that the word Customer was being used differently at that time.

They know the history of the team. They recognise the template. They remember when the commercial process changed.

A new employee does not have that context.

Neither does an AI system unless we have made that context available somehow.

This does not make AI the problem.

Quite the opposite.

AI can expose inconsistencies that were already present in the knowledge base.

If several pages use the same language to describe different realities, an AI can combine those pages into a perfectly plausible answer.

The inconsistency existed before the answer was generated.

The AI simply allowed it to travel faster.

The question behind the field

After Noah's analysis, Priya did not immediately change the template again.

Instead, she asked a different question.

Not:

What values should the Customer field contain?

But:

Who owns the meaning of Customer?

That question led somewhere more useful.

The team documented a canonical definition, but they also identified who was responsible for it. They reviewed the places where the term appeared. They noted which historical pages used an older definition. They agreed what should happen when a company moved from prospect to contracted customer. And they decided when the definition itself should be reviewed.

None of this was particularly sophisticated.

It was simply recognition that shared meaning needs maintenance.

A small test

There is a simple exercise I like for this kind of problem.

Take five fields that appear in one of your important Confluence reports.

Choose fields such as:

• Customer
• Owner
• Status
• Priority
• Risk

Then ask three different teams to define each one without looking at the template.

If the answers are identical, great.

If they are not, you may have found something more important than a formatting problem.

For the fields that matter most, it may be worth agreeing:

• what the field actually represents;
• who owns that definition;
• which values are valid;
• what the authoritative source is;
• how exceptions should be handled;
• and when the definition should be reviewed.

This is not about adding bureaucracy to every property in Confluence.

Most fields do not need it.

But the fields that drive important decisions probably deserve more than a label.

The strange thing about names

Noah had not made a mistake.

Neither had Rovo.

The pages were not necessarily wrong either.

The problem was that the same word had accumulated several meanings over time, while continuing to look perfectly consistent on the surface.

That is what makes these problems difficult to spot.

When a field disappears, someone notices.

When a field changes meaning, everyone can keep using it.

Sometimes for years.

Names change quietly. Meaning breaks loudly.

A question for the Community

Which word in your organisation sounds perfectly clear until you ask three different teams to define it?

I'd genuinely love to hear the examples. I suspect Customer is far from the only one.