What Cataloguing 3,000 Electrical SKUs Taught Us About Product Data

Building the VendorStocks catalogue took ⟨duration⟩ and roughly ⟨share⟩ of the manufacturer-supplied data needed correction before it could be listed. Three problems accounted for most of that work: part numbers that are descriptions rather than identifiers, HSN codes that were missing or wrong, and technical attributes that exist only inside PDF datasheets.

Nobody in Indian electrical distribution publishes this kind of write-up, which is why we are doing it. If you are a distributor thinking about going online, this is the work you are actually signing up for.

Where the data came from

Three sources, in descending order of quality.

Manufacturer price lists, usually Excel or PDF. Reliable for part number and rate. Thin on everything else.

PDF datasheets and catalogues. Where the real technical attributes live — current ratings, wire ranges, dimensions, approvals. Not machine-readable in any useful sense, and often organised by product family rather than by orderable SKU, so a single page might cover forty part numbers with a matrix you have to read carefully.

What was in our own heads. Thirteen years of trading means we knew things about pack sizes, common substitutions and what buyers actually ask for that appear in no document anywhere. This turned out to be a larger share of the final catalogue than we expected, and it is the part that cannot be outsourced.

The work was done by ⟨who — name the team or the number of people⟩ over ⟨duration⟩.

Problem one: part numbers are sentences, not identifiers

This is the problem that generated the most duplicates and it is worse than it looks because it appears solved.

In this trade a part number encodes attributes. A base code, then suffixes for packing, colour, revision, sometimes rail type or accessory inclusion. The same physical item sitting in one box in a godown appears across different files as:

• the base code alone
• base code plus a packing suffix
• base code plus a colour suffix
• base code with a bracketed revision on the end

All four are correct. All four refer to the same thing. And if you load all four from different source files, your catalogue now contains one product four times — frequently at three different prices, because the files came from different revisions.

What we did: picked a canonical form, wrote the rule down, and mapped everything else onto it as aliases so that a buyer searching any variant lands on one page.

What we would do differently: write that rule before loading anything, rather than after discovering the duplicates. We did it in the wrong order and the cleanup cost more than the rule would have.

A related trap: search. A buyer who types the base code must find the product, and so must a buyer who types the full suffixed code from an old invoice. If your search only indexes the canonical form, half your buyers conclude you do not stock it.

Problem two: HSN cannot be inferred

You cannot derive an HSN code from a product description, and everything that tries to is guessing.

Two items with nearly identical descriptions can classify differently based on construction or function. Two items with very different descriptions can share a code. And the consequences of getting it wrong land on your buyer months later, when his input tax credit does not reconcile and he takes it up with you rather than with the platform.

What we did: mapped HSN by product family rather than by individual SKU wherever the family was genuinely homogeneous, verified against manufacturer documentation where it existed, and flagged anything uncertain for a human rather than letting a default through.

What is still unresolved: a small number of items where the manufacturer’s own documentation is ambiguous. We would rather carry a flagged uncertainty than a confident wrong code.

Problem three: attributes live inside PDFs

The attributes a buyer filters on — current rating, wire range, width on rail, pole count, approval marks — are almost never in the price list. They are in the datasheet, in a table, often as a matrix covering a whole family.

There is no clever way around this. Somebody opens the PDF and types.

What made it tractable for us was deciding early which attributes actually mattered per category, rather than trying to capture everything a datasheet contains. For terminal blocks, six attributes cover most of what a buyer searches on. For MCCBs it is a different six. Capturing those six across the range beats capturing thirty for a tenth of it, and it is the difference between finishing and abandoning.

The rule we ended up with: an attribute earns a column if a buyer would filter on it or reject a product because of it. Everything else goes in the description.

Problem four, the one we did not anticipate: descriptions

Manufacturer descriptions are written for people who already know the product.

Push-in Din-Rail TB is accurate and useless. It contains no size, no function, no material, and nothing a buyer would type into a search box. A buyer looking for that item searches for a 2.5 sq mm push-in DIN rail terminal block, possibly with the colour, possibly with “feed through”.

So every listing needed a description rewritten for somebody who is looking for the product rather than confirming it. Three thousand times.

This is also, incidentally, the entire difference between a catalogue that gets found and one that does not. The technical data makes the listing correct. The description makes it findable.

What we would automate, and what still needs a person

Automate: part-number normalisation once the rule exists, HSN mapping at family level, unit conversions, pulling structured tables out of well-formed datasheets, and flagging anomalies — a price that moved forty per cent, a duplicate, a missing mandatory attribute.

Keep human: deciding the canonical part-number form, resolving ambiguous HSN, writing descriptions, and judging which attributes matter for a category. All four of these are judgment calls that look mechanical until you try to automate them and get plausible-looking nonsense.

The honest summary is that automation makes a catalogue maintainable but it does not make one. The first version is typed by somebody who knows the products.

What we got wrong

We treated it as a project with an end date. It has none. Manufacturers revise part numbers, discontinue variants and change pack sizes, and nobody sends you a notice. Data decays quietly, and a stale listing is worse than no listing because a buyer orders against it. Decide who owns the catalogue after launch before you begin — that person has a permanent job, not a project.

We built breadth before we had buyers. ⟨If you can say what share of your early orders came from a small subset of SKUs, put it here — it is the most useful thing in the article for another distributor.⟩ Fifty parts listed properly with real stock and a real price would have taught us more in a month than three thousand thin listings taught us in six.

We underestimated the description work. We budgeted for data entry and got a writing project. In hindsight that was predictable and we did not predict it.

We did not version the source files. When a rate looked wrong three months in, we could not always tell which price list a number had come from. Keep the source files, dated, from day one. This costs nothing and we wish somebody had told us.

If you are about to do this

Four things, in order.

Write the part-number rule before you load anything.

Pick six attributes per category and capture those across the full range rather than everything across part of it.

Do fifty SKUs end to end — data, description, HSN, price, stock — and put them live before you touch the other 2,950. You will learn more from those fifty in operation than from any amount of planning, and you will almost certainly change your schema afterwards.

And decide who owns the file in month thirteen. If the answer is nobody, you are building something that will be wrong within a year and wrong in ways your buyers discover before you do.

Related reading: How to sell electrical products online in India · Switchgear brand cross-reference · Documents you need to get verified as a seller