Catalogues with thousands of SKUs

A catalogue does not become unusable because it is large. It becomes unusable because the size is held as thousands of separate items with their specifications buried in descriptions — so nothing can be filtered, compared or reasoned about. Fix the structure and ten thousand items is navigable. Leave it and four hundred is not.

Most large catalogues in technical trades are a price list with photographs attached, and everything downstream inherits that.

What does badly structured actually look like?

Four symptoms, and most businesses have all four.

Specifications live in the product name. “40mm CPVC Elbow 90deg Class 6” carries four attributes as text. A person can read it. Nothing can filter on it, count it or check compatibility with it.

Naming is inconsistent. The same attribute written three ways because three people entered products over five years. Any filter built on it returns partial results, silently.

Variants are separate products. Six sizes of the same item as six unrelated entries, so a customer cannot switch between them and you cannot report on the design as a whole.

Nobody owns it. New products are added by whoever is asked, in whatever format seems reasonable that day.

What does the structure need to be?

Layer	Holds	Why separate
Product family	The thing a customer names	What they search for and remember
Attributes	Size, rating, material, finish — as fields	Filtering, comparison, compatibility rules
Item	The specific orderable combination	Stock, price, code
Packaging	Units per box, coverage, weight	Turning a requirement into an order quantity
Media	Images, data sheets, drawings	Reused across every channel

The fourth row is the one most often missing and the most quietly expensive. Without units per box or coverage held as data, a customer with a measurement cannot reach an order quantity — and neither can your own counter staff.

How do people actually navigate a deep catalogue?

Not by browsing. Nobody scrolls through four thousand items.

Three routes, and a large catalogue needs all three.

• Search, tolerating how customers actually write. They type abbreviations, trade names and competitor codes. A search that only matches your official product name fails constantly.
• Filtering on the attributes that matter in your trade. Not category alone — the technical fields buyers select on.
• A selector, for people who do not know the specification. Covered in when choosing the product is the hard part.

The first is underestimated everywhere. Watching what people type into your own search box is the cheapest catalogue research available, and most businesses never look at it — the failed searches in particular are a list of things customers wanted and did not find.

Should everything be published?

Usually yes, and it is a decision worth making deliberately rather than by omission.

A slow-moving item still gets searched for, and being the only manufacturer whose site lists it wins the enquiry. Publishing the full range also tells a specifier that you can supply the whole requirement rather than most of it, which matters on project work.

The exception is anything you cannot actually supply. A catalogue full of discontinued items produces enquiries you have to decline, which is worse than not listing them. Mark availability honestly rather than hiding it — “made to order, four weeks” is a useful answer.

What breaks when the catalogue is wrong?

Everything built on it, which is the argument for fixing it first.

A selector cannot reason about attributes that do not exist as fields. A calculator cannot produce order quantities without packaging data. A dealer portal shows stock in units the dealer does not order in. Compatibility cannot be enforced. And every new system brings its own copy of the product data, so within two years there are four versions that disagree and no authoritative one.

One catalogue, one place, everything else reads from it. That single decision determines what everything afterwards costs — see what to digitise first.

How long does fixing it take?

The structural design is quick. The cleaning is not, and it is the part nobody budgets for.

Deciding the attribute model for a trade takes days. Going through several thousand existing items, extracting specifications from names, resolving inconsistent terminology and filling gaps takes considerably longer — and it surfaces disagreements between systems that nobody knew existed.

Two things make it tractable. Do the fast-moving items first, since a minority of your range carries most of your volume. And put rules in place for new products at the same time, or you will be cleaning again in three years.

Common questions

Can we do this without replacing our ERP?

Usually, and usually you should. The ERP keeps doing finance and stock; a separate catalogue layer holds the structure, attributes and media, and feeds everything customer-facing. Replacing a working accounting system to fix a catalogue is a large project solving the wrong problem.

Who should own the catalogue?

A named person or small team, with authority to refuse badly specified additions. A catalogue with no owner drifts within months, and a drifted catalogue is how businesses end up back with spreadsheets.

How many attributes is too many?

Hold everything that is true; expose only what customers select on. There is no cost to storing a field nobody filters by, and considerable cost to a filter panel with twenty options.

What about products from several principals?

For a distributor this is the central problem — each brand structures its data differently and none of it matches. Mapping them onto one attribute model is the first job, and it is what makes a multi-brand catalogue usable rather than three catalogues in one place.

More on this: when choosing the product is the hard part and selling online when nobody pays online. See also product catalogues & dealer locators.