Thousands of product codes and nobody dedicated to them: where to start

A wholesaler with thousands of product codes always has the same conversation pending. The catalogue is maintained by whoever can, whenever they can: someone in admin updating prices between two invoices, a salesperson fixing a description because a customer complained, the IT person who uploaded the photos once, in 2019.

The work exists, it is enormous and it is continuous. What does not exist is somebody whose job that is, every day. And every incomplete record ends up turning into a phone call, a mis-picked order or a credit note.

In distribution, the catalogue is not marketing

In consumer ecommerce the product page sells. In distribution the product record is the tool your customer works with: it gets read by a purchasing manager who knows more about the product than you do, and they read it to decide in thirty seconds whether to order from you or from the firm next door.

When a field is missing, the customer does not leave: they call you. And that call has a cost that appears nowhere, since it is answered by someone on your team who was doing something else. Codes with no description, no cross-reference, no clear selling unit, or with stock out of date, translate into phone traffic, picking errors and refunds.

That is the real reason to put someone permanently on the catalogue, rather than having a pretty website. A complete catalogue means fewer calls.

Order matters more than speed

With thousands of codes, the temptation is to start at the top of the list or with whatever is most visible. That is the most common way to spend three months and notice no improvement at all.

The order that works has three stretches, and it is worth respecting even where it feels counter-intuitive:

• First, what sells. The codes that genuinely move, complete and current: live price, stock, attributes, selling unit, lead time and photos. They are a fraction of the catalogue and they concentrate almost all the enquiries. Fixing them shows in the first week.
• Then, the incomplete records with demand. The ones somebody has ordered at some point but whose record is half-done. This is where the most wasted work sits: codes that exist, that would sell, and that nobody finds because they have neither a description nor a category.
• Last, the discontinued lines. They have to be dealt with —flagged, cross-referenced, decided whether to hide them or leave them visible with their replacement— but they come last. Starting here means spending weeks on codes that will never generate another order.

And one rule across all three: the catalogue never ends. The supplier arrives with a new price list, the packaging changes, a whole range is discontinued. So this is not a project with a finish line, it is a role. A push every six months leaves the catalogue better for three weeks and then back where it was, and it is exactly what a catalogue maintenance role covers.

Who authorises a change to master data

This is the question almost nobody asks before starting, and the one that blocks everything else. With no answer, every correction sits waiting.

A catalogue has two kinds of field, and it is worth separating them in writing before day one:

What gets corrected without asking. A badly written description, an obvious category, a missing attribute, a photo that belongs to something else, a selling unit that contradicts the delivery note. Those are errors, not decisions, and asking permission for each one turns the role into an approvals queue.

What needs a signature. The selling price, your own internal code for the item, the link to a supplier, the minimum order quantity, creating or retiring a code. There, each change has consequences for orders, price lists and accounting, and someone has to be the one who says yes.

What matters is not where you draw the line, it is that it exists and has a name behind it. A badly drawn line is corrected in a week; a non-existent line means that by month two there are a hundred corrections noted and none applied, and then nobody knows whether the catalogue is right or wrong.

Add one more thing, which costs ten minutes: where changes get logged. A simple history of which code, which field, what value it held and what value it holds now. That is what lets you undo an import error without rebuilding it by hand.

B2B order entry

The second delegable block is the order that arrives by email, by phone or through the portal, and that somebody has to turn into an order in your system.

Receiving it, checking the codes exist and are available, confirming back to the customer with a lead time, and following it through until it ships. It is repetitive work, with written criteria, and it is what most frees up your sales team's phone.

It has two known traps. The first: the order that arrives in the customer's format rather than yours —their own coding, an order typed into the body of an email, a spreadsheet with four different columns every time. That is solved with a cross-reference table between their code and yours, built once per customer.

The second: the order that does not add up. A discontinued code, a quantity below the minimum, a lead time the customer assumes and that is not the real one. Nothing gets improvised there: it gets escalated.

What gets escalated, written as cases

As with everything else, this works if it is written as a list of cases rather than a principle. A reasonable list for a wholesaler:

• A special lead time or an urgent delivery that breaks the usual route.
• A stock exception: part-shipping, reserving product, taking stock allocated to another customer.
• A discount, free carriage or any term not on that customer's price list.
• An order from a customer with outstanding payments.
• A return that falls outside policy, and any credit above the amount you decide on.

Anything not on that list gets resolved without asking. And whatever gets escalated is escalated with the case put together: which customer, what they ordered, what they have been told and what is being proposed. An escalation that is only «look at this order» hands the whole job back to you.

Customer price lists are not negotiated: they are applied

This deserves its own section, since it is the most important line in the whole split.

In B2B the price list is the entire relationship. The volume discount, the rebate, the special price a customer has carried for eight years: you decide those, and negotiating them is sales work that is not delegated and that you should not let anybody promise you.

What does get done is applying them without mistakes and flagging whatever does not add up. A customer on list B buying at general list prices, a discount left switched on after the campaign ended, a price list never updated after the supplier's increase. Spotting those gaps is one of the things that pays for itself soonest, and they surface precisely when somebody looks at the catalogue every day.

Same with purchasing: whoever decides what gets bought and from whom takes on the stock risk, and that risk is yours.

Delivery incidents, which arrive afterwards

There is a third layer that is neither catalogue nor order entry, and it eats afternoons: the shipment that never arrived, the pallet that arrived damaged, the delivery note signed with reservations, the return that has to be collected and credited.

It is the work of chasing third parties —carriers above all— and keeping the customer informed while the chasing goes on. It needs no commercial judgement, it needs persistence and a record of what has been claimed and when. It is exactly what the returns and incidents role covers, and it is usually the second one to be filled, after the catalogue.

How you can tell it is moving

Four numbers, and you already have the first three in your system.

Codes with a complete record over the total, counting only the ones that move. It is the one that measures the real work, and it has to be read by stretch rather than overall: 40% of the catalogue complete can be 95% of what you sell.

Orders entered with no salesperson involved. That one tells you whether the phone is being freed up.

Incidents per hundred orders, separating data incidents —wrong code, wrong unit shipped— from transport ones. The first fall as the catalogue improves; the second do not.

And the fourth, which is on no dashboard: what people ask about on the phone. Ten calls asking for the same dimension are one record that does not say what it should.

Where to start

Before touching a single code, settle the master data question: who authorises what. It is half an hour, and without it nothing else moves.

Then the catalogue that sells, by stretches and with a weekly target. Then order entry, with its escalation list written down. And the rest of the catalogue in batches, knowing it never finishes.

The full path, with your ERP, your PIM if you have one and the portal your customers buy from, is set out on the wholesale and distribution page.

And if you want one figure to decide whether you need this, count how many calls this week were to ask something that should have been on the record.