Six shops, one panel: sorting out a catalogue drifting apart across three markets
When the same item is sold across six shops on three markets, sooner or later it turns out to be called something slightly different in each. Then somebody tries to build a report out of it.
What the drift looks like
It does not start as a mess. It starts with the first shop being built three years ago, the second a year later, and the third arriving with a company you acquired. Each has its own category structure, its own manufacturer names and its own way of writing down the same thing.
The symptoms are always identical: the same goods carry three different names, the warehouse does not agree with the shop, and the question „how much of this did we sell in total” requires exporting three files and an afternoon in a spreadsheet.
The fix: one reference catalogue, shops as consumers
Rather than sorting out six shops separately, we built one master catalogue in which every item exists once — and eight tables describing the world around it: countries, product groups, specific products, manufacturers, distributors, warehouses, sales channels and packaging types.
The shops stop being the source of truth and become consumers of it. A change of name or description happens in one place and travels outwards. The question about total sales stops needing a spreadsheet, because there is one place where the same item is the same item.
Descriptions and translations: where the time actually goes
Entering a hundred products into a shop by hand is not difficult work — it is long and dull work in which mistakes creep in towards the end of the day. On top of that come descriptions and translations for further markets.
The system produces descriptions and translations by machine, with two independent providers — one primary, one as backup. That is not excessive caution: around 2% of requests do end up with the backup, because the primary is momentarily unavailable. Without that safeguard, uploading a hundred products would break at a random point and have to be resumed by hand.
I deliberately do not quote a number of hours saved, although it would look impressive. Nobody at this client measured it before the change, so any figure would be invented. What is solid is what can be checked: the scale, and the fact that running this tool costs nothing beyond the services it uses.
The trap projects like this fall into
It is tempting to start with a grand unification: clean up all six shops, agree a shared category structure, and only then build the tool. That is a quarter-long project which usually dies half-way, because in the meantime you have to keep selling.
The sensible order is the reverse: build the master catalogue alongside the existing shops first, then connect them one at a time. The shops keep running and order accumulates. The end state is the same, but there is no moment when everything is torn open at once.
Where the drift comes from — and why it will not fix itself
It is worth understanding the mechanism, because without it the order you create once will drift apart again within a year.
A product name in a shop is usually created in a hurry: somebody adds the item, types the name as it appears on the supplier's invoice, and moves on. The second shop gets the same goods from a different distributor, with a different name on the paperwork. The third came with an acquisition and the name there is historical. None of those people made a mistake — each typed what was in front of them.
So order is not a one-off renaming exercise. It is having a place where it is decided what is what. When new goods arrive, they are entered once into the master catalogue and only from there reach the shops. Without that step, a year from now you have the same mess in newer names.
Eight tables, or why so many lookups
The master catalogue is not a single product list. It is a list surrounded by eight lookups describing the world it lives in: countries, product groups, specific products, manufacturers, distributors, warehouses, sales channels and packaging types.
That looks excessive until the first question of the form: „how much of this manufacturer's goods did we sell in Austria through shop B, in pallet packaging”. Without lookups such an answer needs an export and a spreadsheet. With them it is one query, because each of those concepts exists as its own thing rather than as a fragment of a product name.
A practical tip for projects like this: build lookups from the questions the company already asks and cannot answer. Not from what might theoretically be useful. The latter gives you thirty tables of which four get used.
Stock levels: where the drift hurts most
A catalogue that drifts is inconvenient. Stock levels that drift cost money — because either you sell something you do not have, or you fail to sell something sitting in a warehouse.
In this case the goods sit across 229 warehouses and are sold through six shops in three countries. Without a shared catalogue the question „how much of this do we have” had no single answer, because each shop asked its own installation about its own name for the same thing.
After unification there is one answer and each shop receives its own slice of it. This is the part of the project that pays for itself fastest — and also the hardest to show in a screenshot, because its output is the absence of problems.
What it costs to run
Worth stating, because with internal tools the question of the bill is usually skipped — and those are the ones that quietly generate cost for years.
The catalogue described here runs today with no fixed infrastructure fee: it fits inside the free tiers of the services it uses. The only paid part is machine-generated descriptions and translations, charged by usage — so in a month when nobody adds products, it costs nothing.
That is not a rule for every internal tool, but it shows something important for planning: a tool serving one or two people a day has a completely different cost profile from a system for a whole company. A quote treating both the same is either too high for one or too low for the other.
Who this is for
- For companies with more than two places selling the same stock — shops, a wholesale arm, a marketplace.
- For companies where the same product has different names in different systems and nobody knows which is right any more.
- Not for companies with one shop and a stable catalogue — there the shop's own admin panel is entirely sufficient.