15 May 2026 · Pedro Aldea
Standardize before you automate: why a messy catalog makes AI fail
Step 2 of the Zero Friction Method is standardize. Without it, automation amplifies the chaos and the AI learns the errors. Here's how it's done in a real operation.
Standardising before automating is what separates AI projects that scale from those that get stuck in pilot. When a company has the same brand spelled four different ways (BOSCH, Bosh, BOCH Inc., B0SCH), putting AI on top produces a probabilistic answer: it works 80% of the time, fails 20%, and the 20% that fails is structural — brands with fewer examples. Standardising isn’t imposing rigidity; it’s defining three things in order: the canonical (which is the default version), the exception rules (what’s a variant to collapse and what’s a real exception), and the maintenance mechanism (who decides when a new spelling shows up). When those three are in place, the AI of step 5 does what no deterministic system can: matching new variants against an already-defined canonical. The hard part — deciding what that canonical is — isn’t done by a tool, it’s decided by a head of operations.
When somebody tries to sell an AI solution on top of that, what happens is predictable: the AI learns four different entities. Sales still can’t search. Procurement still can’t compare. And brand-level reporting still doesn’t exist, because to the system they’re four different brands.
That’s step 2 of the Zero Friction Method: standardize. And it’s what separates the projects that scale from the ones that get stuck at pilot.
Why automation isn’t the first answer
The easy narrative says “we have a dirty data problem, let’s stand up an automated cleaning system with AI.” That narrative works in the deck. It doesn’t work in the operation.
Cleaning variants with a model on top of a heterogeneous catalog gives a probabilistic answer. Works 80% of the time, fails 20%, and the 20% that fails is structural: the lower-frequency brands, the ones that don’t have enough examples for the model to group them well. The salesperson searching for a part from a small manufacturer still can’t find it. The procurement lead still doesn’t know whether the new supplier entry is the brand they already had in another form.
And the AI, by confirming matches with confidence, introduces a new problem: errors that are hard to audit. Before, the catalog was dirty but the catalog manager knew it was. Now it’s semi-clean and nobody knows exactly what got collapsed and what didn’t.
Standardization isn’t done with AI first. It’s done with human decision first.
What standardizing actually means, concretely
Standardizing isn’t imposing rigidity. It’s defining three things, in this order:
First, the canonical. For each category of variation, write down what the default version is. BOSCH (all caps, no Inc., no suffix). The canonical gets decided in a 30-minute meeting with the catalog manager, not in a six-person committee. It gets documented in a table, not a PDF.
Second, the exception rules. For each case that doesn’t fit the canonical, define whether it’s a real exception (there’s a present reason) or a variant to collapse (it’s the same entity written differently). Real exceptions are few. Variants to collapse are the majority.
Third, the maintenance mechanism. When a new invoice comes in with a new spelling, who decides if it’s an exception or a variant? The right answer isn’t “the AI.” The right answer is: a person on the team, with a tool that shows them the new spelling next to the existing spellings and asks for a binary decision. The AI can suggest, but the person decides.
When those three pieces are in place, the AI in step 5 does what it’s supposed to do: matching new variants against the already-defined canonical. The hard part is already solved.
What happens when this gets done right
When the catalog of an industrial distributor goes through this exercise, the first thing that shows up are uncomfortable numbers. Hundreds of brands with multiple variations. Hundreds of thousands of references uncategorized. Historical tables disconnected from current inventory. And the question nobody wanted to ask themselves: how many years ago should we have done this?
Once it gets attacked with order, the result shows up in the operation, not in the deck. The salesperson searches “BOSCH” and the entire associated inventory appears, regardless of how the person who entered it in 2015 spelled it. Procurement compares prices across suppliers on the same SKU, not on four different entities. Brand-level reporting, which had been approximate for years, starts being exact. And cross-selling, which until then was manual and depended on the memory of veteran salespeople, becomes an automatic suggestion based on data that’s already clean.
We wrote about it in detail in the product categorization case, where over three million rows across five hundred tables went through this process. What matters about that case isn’t the numbers, it’s the human decisions beforehand that made it possible for the numbers to exist. Without them, the technical pipeline would have produced a worse result with more effort.
Why it gets skipped so often
Standardizing is unglamorous work. It doesn’t sell in pitches because there’s no attractive slide for a brand canonical. Nobody runs case-study presentations on three months of catalog cleanup, even though that’s exactly what makes the AI project that comes after work or not.
And there’s another, deeper reason: standardizing demands taking decisions that have been postponed for years. Are we OK with that old brand no longer appearing in its historical spelling? Do we decide that supplier X’s invoice format has to land at the canonical at intake time, not after? Do we accept that the catalog manager has authority to collapse variants without asking permission for each case?
Those decisions don’t get taken by a tool. They get taken by a director of operations. And they’re the ones that unlock everything that comes after.
When AI shows up
When the canonical is defined, the exception rules are written, and the maintenance mechanism is active, the AI in step 5 walks in to do what no rule-based system can: matching new variants that don’t fit exactly into any known spelling. A brand that arrives written in a never-before-seen form, with a typo, with a suffix the regex didn’t account for, with an accent the old system didn’t recognize.
For that, AI is the right tool. For defining the canonical, no. For deciding what’s exception and what’s variant, also no. For making sure the customer’s team can maintain the system after we leave, much less.
Standardize before you automate isn’t a methodological detail. It’s the difference between a project that scales and one that stays at pilot. How many variants of the same entity coexist today in your database without anyone having officially decided which one is canonical?
If your company has a catalog, a supplier base or a customer table with years of accumulated variants and you want to know what can be collapsed before putting AI on top, the 2-week operations roadmap leaves in writing the recommended canonical and the standardization decisions ranked by impact.