Matt Burgess

Customer.

“We need to understand what our customers really want” - strategy meeting, Tuesday.

“Which customer? The account or the contact?" - CRM administrator, same Tuesday.

“She’s not a customer yet, she’s a prospect” - sales, pushing back on the report.

“We have a customer on the phone. She hasn’t had her delivery” - contact centre, 11am.

“Historically this customer has purchased every Christmas without fail” - loyalty analyst, quarterly review.

“The customer agreed to the contract terms” - legal.

“What does the customer actually think?" - researcher, holding two hours of interview nobody has watched.

Did everyone in those quotes sound like they knew what they were talking about? Oui? That’s the problem. Same word, spelt c-u-s-t-o-m-e-r, every time, used for all of those different things.

And that’s just the conversations. The word is in the decks and on the walls too - Customer Experience strategy, Customer First initiative, Customer 360 platform, Customer Insights deck, each one a different owner, a different implicit model of who they’re actually building for, launched with confidence, never debugged.

Underneath all of that, in every system the organisation runs, ‘customer’ sits as a silent structural assumption - built into the architecture, inside schemas and tables and APIs, meaning something slightly different in each one, load-bearing in ways nobody has fully mapped. No organisation has ever produced a cheat sheet for this word, not one, and for a long time this didn’t matter enough to force a fix.

To understand how this got so entrenched, let’s go back about twenty years.

In the late 1990s, technology teams ran into a problem that turned out to be embarrassing in a very specific way. Every enterprise system had its own ‘customer’ - the CRM had one, the billing system had one, the logistics platform had one - and all of them used the word while meaning something slightly different by it, all of them assuming that the rest of the organisation meant the same underlying thing. Not a name and address necessarily, but the same concept of a person, the same mental model of who they were dealing with. Nobody noticed they were all different until they tried to make the systems talk to each other.

Run a report across systems and you got three different numbers for the same question. Merge two companies and you had 400,000 customers in one database, 380,000 in another, and no reliable way to know how many were the same people. Try to build a single view and you found that CUSTOMER in the CRM referred to an account, in billing a contract, in logistics a delivery address. The problem wasn’t unique to the tech stack - the word was carrying the same impossible load everywhere else in the organisation, but because integrating systems together made the inconsistency unavoidable, and because systems failed in tech, that forced a fix.

The fix was an agreement about authority. Pick one system as the source of truth, say the customer’s name lives here and their address lives here and their account number lives here, and if any other system disagrees, this one wins. A golden record wasn’t a better guess, it was the record everyone agreed to treat as correct - canonical - meaning authoritative, the version everything else has to derive from. The practice got a name - Master Data Management - and eventually a whole category of tooling sprang up, which named the problem and gave people something to point at.

[Of course, tech ran into a version of this again a decade later with DevOps with a different wall, the same invisible inconsistency, the same forcing function. Tech folks will shrug at both stories, they have names for them, toolsets, some scars, and maybe a twitchy eye. Or maybe that’s just the ones I drink with.]

There was a limit to ‘canonical’ as a solution, though, and it’s something the tech world is still working through. It works cleanly for facts - addresses, account numbers, transaction histories, a customer either lives at this postcode or they don’t - but when the question shifts from data fields to understanding - who is this person, what did they actually say, what do they need - a single authoritative version starts to look less like a solution and more like a different kind of problem. The researcher’s ‘customer’ and the product manager’s ‘customer’ and the commercial team’s ‘customer’ aren’t just wrong versions of a right answer, they’re legitimately different relationships with the same person, and forcing one reading on everyone doesn’t resolve the difference, it just relocates it.

And more vitally, on the tech side, the actual work told tech when something was wrong - code runs or it doesn’t, a test passes or fails, and when systems try to share data and their versions of ‘customer’ don’t agree, something breaks visibly, in a way that has to be resolved before anything can ship. Unfortunately, the same can’t be said on the business side. A strategy deck doesn’t call a halt to the meeting when its assumptions about customers contradict each other between slides (and boy does it), a persona doesn’t flag when three teams are using the same word for three different journey simulations, and a quarterly theme doesn’t tell you when it was built for the wrong idea of a person. The meeting ends, the deck gets filed, the roadmap gets approved, and you never find out - not because the assumptions were right, but because nothing in the work demanded they be tested.

On the business side, everything has appeared to be working - strategy decks, personas, service blueprints, customer journey maps, each a serious attempt to pass a version of the customer to the next register. Teams doing good work, in good faith, with no visibility of how their version of ‘the customer’ contradicts everyone else’s. Nobody could see the contradiction, because nothing in the work made it visible.

Enter AI, stage left.

The most common worry about AI right now is that it gives wrong answers, and it can, but the deeper problem isn’t wrongness, it’s that the outputs look… well… right. An AI reasoning about your customers reads every version simultaneously - the research synthesis, the persona deck, the NPS summary, the loyalty model, the sales narrative - and it can’t reconcile them because it doesn’t know which one to trust, so it produces something that averages across all of them, fluent and coherent with nothing real underneath. Unfortunately, a beautifully written summary that has quietly dropped the-most-important-thing-the-customer-said is worse than no summary precisely because it looks like the job got done. AI distributes that at speed, across every surface, to every team, at once.

On top of that, AI - in the form of bots - is contaminating the quant inputs and has been for some time. NPS scores increasingly gamed or bot-generated, survey panels stuffed with synthetic responses, review data you’d rather not look at too closely. AI is two sources of risk: in the numbers the whole downstream stack runs on, and in the summarising layer bolted on top. AI doesn’t diagnose any of this, it can’t. It just processes the contaminated inputs with the same confidence it processes everything else and hands you something that looks like insight.

AI is supposed to be the productivity unlock. Sure, it’s faster. But faster what? Productivity depends on what you’re fast with, and the inputs - every register’s version of ‘customer’, contradicting each other across every system - have never been clean. The output looks like a summary, an acceleration of the divergence that was already there, dressed as insight. That, ladies and gents, is the business side’s forcing function. Not a broken system, a broken promise.

The obvious answer to this is the one tech reached for twenty years ago: pick one definition of the customer, make it canonical, and require everyone to derive from it.

Picture what that looks like though. Say Finance’s ‘customer’ register wins. Sales can’t call a prospect a customer - they haven’t contracted yet, so they don’t exist in the schema. The researcher’s subject - a person with a life, an opinion, two hours of interview nobody has watched - has no home in a contract. The contact centre agent dealing with someone who hasn’t had their delivery is referring to them as a contract reference number, not a person. Every register knows this is wrong for their work. Every register carries on using the word the way they always have, because they have to. The canonical fix works when there’s one right answer. For addresses and account numbers, there is. For the expressed customer - the relationship, the meaning, the person - there isn’t. The diversity of meanings isn’t a mistake, it’s load-bearing - force one reading and you don’t fix the problem, you break the work.

What’s needed is something multi-register. Holding all of those legitimate readings simultaneously, without requiring any of them to surrender their own. Finance has always had its ‘customer’. So has the researcher. So has sales. None of them are going anywhere, and none of them should be forced into an averaged one-size-fits-all. But that’s what AI is doing. Work still has to get done, decisions still have to get made - a reconciliation happens whether you design for it or not. The question is whether it happens knowingly, with signals that are focused and additive, or passively, with whatever averaged version of ‘customer’ the AI just produced.

So what does the AI forcing function actually demand?

It can’t be a golden record - there is no single correct version of the customer, and forcing one reading on everyone just relocates the disagreement.

It can’t be another summary tool - more summarising, faster summarising, better summarising all moves further from the source.

It can’t be an AI layer - AI is the forcing function here, not the fix. Putting AI on top of the problem it created is not a triage, it’s a burial. And with AI costs going up, paying every team to run their own version of ‘customer’ through their own AI isn’t just epistemically bad. The duplication is now expensive.

It has to hold multiple legitimate readings simultaneously without any one overwriting the others. Why? Because the researcher’s reading and the commercial team’s reading aren’t competing errors - they’re different legitimate relationships with the same person. A system that can only hold one of them just moves the argument somewhere else - into every meeting where those two teams sit together.

It has to be traceable. Why? Because the negotiation over what the customer said is supposed to happen - that’s the work that seeks out value. Right now it doesn’t, and we all know it. A decision you can’t trace back to the expressed moment is a decision you can’t defend. AI is just producing something that looks and sounds negotiated - but that word ‘customer’ is still in there, doing different jobs for different folks, with nothing resolved.

And it has to hold the expressed moment at source - before the first crossing, before the first paraphrase. Why? Because every crossing has been a loss, not through incompetence but through architecture, and the only way to prevent it is to not move the source. Let each register come to it.

The tech stack has canonical accounts, canonical transactions, canonical prices - one record, agreed, that everything else derives from. Not the CRM version of what they want, not the research synthesis, not the persona, not whatever ‘the customer’ meant in last Tuesday’s meeting - every version has equal standing because nothing does, so the most persuasive voice wins, every time.

What’s been missing is canonical customers - and that adjective is borrowed deliberately from tech, which applied canonical to data. The expressed customer - what someone actually said, in their own words, at a specific moment - was simply beyond what the architecture could hold. (Yes, tech folks, canonical data is its own ongoing argument. That’s a different post.) With canonical data, someone inside the enterprise has to decide which version wins. That takes authority, and authority takes politics. Canonical customers bypasses that entirely. Nobody inside the enterprise gets to settle whose ‘customer’ is right - because the customer already settled it. The enterprise just needs to stop losing it.

Canonical here doesn’t mean the one true interpretation. It means the one true source. Think papal infallibility - but not infallibility by decree, infallibility by origin. The customer expression is the record, it doesn’t get revised by whoever argues most convincingly after the fact, everything downstream is interpretation and the expressed moment is not. And because the expressed moment is a boundary object - readable by every register in their own terms, consumed by none - the researcher stays in research, product stays in product, loyalty stays in loyalty, design stays in design. They don’t have to agree and they don’t have to convert because they’re reading from the same origin. And when AI reasons from that origin - not averaging across contested versions but working from the expressed moment itself - it might finally do what it promised.

When the thing you’re working from is real, the work feels different.

That’s what Stratum is for.

Follow along: mattburgess.micro.blog/subscribe… mattburgess.micro.blog/feed.xml micro.blog/mattburge… Mastodon @mattburgess@micro.blog