2,065 free-text products, a warehouse with no codes: how we got out in two days

This is the story of a company that had all the data and could use none of it. It produces and sells modular products — the same item might be a set of two chairs, a set of four, a table with matching chairs — on Amazon, eBay and other marketplaces, with orders connected to the ERP. On paper, a digital operation. In practice, every automation stopped at the same point: product descriptions were free text written by hand, each one different from the next.

The company

• Business: production and sale of modular products
• Channels: Amazon, eBay and other marketplaces, connected to the ERP
• Catalogue: 2,065 products
• The blocker: no component coding — free-text descriptions

The «before»: value trapped in text

Rows in the ERP looked like this:

• A-001 | "Set of 2 Elegance model chairs, white"
• A-002 | "Set 4 chairs mod. Elegance white"
• B-010 | "2 Elegance chairs wht. + 1 Urban tbl. grey"

Three rows, three different spellings for the same chair. Non-standard abbreviations, and colour, material and quantity crammed into a single text field. No component codes: to the system, the white Elegance chair in the two-set and the one in the four-set were different objects. Invisible duplicates, by the thousand.

The consequences were not an IT annoyance but a daily operating cost: internal estimates put around 30% of operators' time into fixing data, and getting a new product into the catalogue took 3-4 times longer than it should have. Above all, without coded components the two things the company actually wanted were impossible: generating bills of materials automatically, and running the warehouse by component instead of by description.

The data existed. It was unusable.

What we did: a four-stage AI pipeline

The manual route — someone reading 2,065 descriptions and recoding them by hand — was estimated at 3-4 weeks of work. Instead we built a pipeline in four stages, where each stage uses a language model with a specific prompt plus programmatic validation of the results: the AI proposes, the code verifies.

1. Extraction. The model reads the raw description and returns separate fields: component type, model, colour, material, quantity.
2. Normalisation. Spellings are unified: every abbreviation becomes the same standard word, everywhere.
3. Deduplication. Semantic matching recognises identical components written differently by different people — the step no hand-written rule had ever managed to cover.
4. Coding. Every component gets a unique speaking code: the white Elegance chair becomes SED-ELG-BIA, the grey Urban table TAV-URB-GRI.

From there, bills of materials generate themselves: B-010 = 2x SED-ELG-BIA + 1x TAV-URB-GRI, QR code ready for the producers.

The numbers, with their caveats

• 2,065 products analysed, yielding 1,631 variants and 893 unique components
• 95% accuracy of AI extraction, validated on a 20% sample
• Zero errors in the final coding — after human review, which is part of the method, not a fallback
• Two days instead of the estimated 3-4 manual weeks, review included
• 2,065 products coded out of 2,065

That 95% deserves a word, because it's the number that usually gets hidden: on its own, the AI got one extraction in twenty wrong. That is why the pipeline includes human review of uncertain cases — and it is the review, not the model, that takes the final result to zero errors. Anyone promising you 100% from AI alone is describing a demo, not a production process.

Then we built on top of it: the warehouse app

Cleaning the data was not the goal, it was the prerequisite. With 893 coded components and QR codes generated, the warehouse became governable — and we built two custom applications on top.

The mobile app, for the people among the shelves. The operator frames a product's QR code and does everything from there: adds quantities, removes them, corrects them. It also keeps the physical order of the warehouse: when a product changes place, its location updates from the scan, and the warehouse on screen matches the real one again.

The web app, for the people at a desk. The live warehouse picture — quantities and locations — with product search instead of scanning, and the same management operations. Plus the part that closes the loop: label printing, for products and for locations, to physically map shelves and sheds with the same codes that now live in the data.

That is the right order of operations, and it holds for any company: structure the data first, build the software second. A warehouse app on dirty data would only have digitised the chaos.

When this approach works (and when it doesn't)

Three conditions, without which it is better not to start:

• You have the data. Dirty, free-text — fine. But it has to exist. AI structures what is there; it doesn't invent what is missing.
• You know what you want. «Coded components to generate BOMs and run the warehouse» is a goal; «bringing AI into the company» is not.
• You accept human review. The automatic 95% becomes 100% only with a human eye on the doubtful cases. If a supplier doesn't offer it, be suspicious.

AI didn't replace data governance here. It made it possible — in two days instead of a month.

A note on this case

The company preferred not to be named, as most of our clients do. The numbers — catalogue, variants, components, timings and accuracy — come from the real project, and the methodology is replicable on any catalogue with unstructured descriptions. If your data looks like the «before» in this story, the first step is a free assessment.