Episode 19: Why Supplier Data Is Never Usable

Supplier data should be a solved problem by now. We have had PIMs for years. We have built supplier portals, written onboarding templates, adopted standards, added validation rules and mapped workflows.

On paper this should be easy. For most teams it is still one of the most painful processes in the business.

Data arrives late. It looks complete. Then you try to use it and everything comes apart, and somebody spends the afternoon fixing it by hand before it can go live.

The instinct at that point is to assume something is missing. Another system. Another template. But the problem is rarely tooling and it is never effort. It is that the way supplier data gets collected does not match the way the business needs to use it later.

Why this got harder rather than easier

Every requirement is growing at once. More specification attributes, more content fields, more compliance obligations, more channel specific demands.

At the same time supplier bases are getting larger, not smaller. Hundreds of suppliers, sometimes thousands, all at wildly different levels of digital maturity. And the volume does not come from your biggest, most sophisticated partners. It comes from the long tail: smaller suppliers with no clean internal product model, working from spreadsheets and PDFs, who cannot reshape their data into the format you have asked for.

What changed underneath all of that is who reads the output. In search-led commerce, humans were the safety net. Basic attribute models, free text and PDFs were survivable because a person could compensate for the gaps.

Product data is now consumed primarily by machines. Search engines, recommendation engines, marketplaces, comparison tools and increasingly generative systems. None of them guess, and none of them compensate for ambiguity. A missing or badly structured attribute means the product does not surface, the filter breaks and the comparison fails.

You can see the cost in the process itself. Getting a single product live routinely takes 10 to 15 back and forths with a supplier, and teams spend a couple of hours per SKU verifying and correcting what arrived. What should be straightforward becomes weeks, sometimes months. Almost none of that effort adds value. It compensates for how the data was collected in the first place.

1. Structure: separate how data arrives from how it must exist

Say structure and most people think of the target schema, the list of attributes a product ends up sitting in. That is only half of it.

Structure means holding two things apart that usually get tangled: how supplier data arrives, and how it needs to exist internally to be useful.

Supplier data never arrives neatly mapped to your model. You get spreadsheets with inconsistent columns, PDFs with the specs buried inside tables, links with half the information missing. Length sits in a dedicated column for one supplier and inside a free text field for another. Units vary. Dimensions vary.

The usual response is to force alignment at the front door. Send it back, ask them to use your template, insist everything is mapped to your attributes before anything begins. It feels like control. What it actually does is push your internal complexity onto people who have no reason to understand it, and slow the whole thing down.

The better approach is to accept that supplier data will always arrive in its own shape. Capture it at source, do not block onboarding, and preserve exactly what the supplier gave you. Once it is inside your world you can map, normalise and enrich it into the structure you need.

Decouple those two things and onboarding scales. It works the same way whether you have hundreds of suppliers or thousands. This is not lowering your standards. It is building a process around reality rather than fighting it.

2. Usability: remove the guesswork

Bad supplier data is not suppliers being careless. It is suppliers being uncertain.

Somebody opens your form and finds a field called product type, or application, or form factor, with no explanation of what you mean by it. So they guess, or leave it empty, or put something plausible in to get to the end. From their side the submission is complete. From yours, you have just inherited ambiguity that somebody on your team now has to untangle.

Good usability removes that at the point of entry. Every attribute needs a clear name, a stated purpose and guidance sitting right there while the decision is being made. Not in a definitions PDF nobody opens.

Friction matters just as much. Every extra login, approval step and unnecessary click adds resistance before a single value has been created, and that resistance shows up later as half-finished submissions.

It also means letting suppliers work the way they already work. Pasting from Excel, uploading the file they have, dropping in text from a data sheet. Force them to restructure everything before they can submit and you have designed a process that fails.

Usability is not about lowering standards. It is about making good data the easiest outcome.

3. Automation: last, not first

This is where teams hope the problem disappears, and it is the reason so many PIM implementations deliver almost nothing on the automation they were sold on.

Automate a broken intake process and you amplify the same problems faster. More data arriving, no improvement in quality, more clean-up on the other side.

Automation earns its place when it is aimed at the mechanical, repetitive work nobody should be doing at scale. Normalising units. Standardising formats. Checking consistency. Flagging missing values.

Missing data is the clearest example. The default response today is to chase the supplier. The better one is a system that gap fills from known sources and similar products, then surfaces those values with a confidence score attached. The human role shifts from manipulating data to reviewing it.

That is the point. Automation is not about removing people from the process. It is about people spending their time on the judgement calls that actually need one.

These three only work in this order. Structure, then usability, then automation. Jump to the third and you get the same problems, at greater scale.

Two businesses that did it in order

A home improvement and trade retailer in Australia decided to capture supplier data directly from suppliers rather than let spreadsheets circulate internally. Crucially, they did not simply issue a portal and ask people to fill it in. They invested in guidance: clear attribute definitions, plain messaging on what each field meant, and validation that stopped obvious problems ever reaching the internal team.

They were also realistic about what suppliers would tolerate. Rather than demanding every attribute be keyed in perfectly, they gave options. Paste the data, upload whatever you already have, or let AI tools extract and enrich it as part of the submission. That is usability done properly.

A global distributor with a very large supplier base took the structure principle to its conclusion. They accepted early that forcing every supplier into a single format was never going to happen, so they now capture source data first: the spreadsheets, documents and exports suppliers already hold, messy as they are. That becomes the input for extraction and enrichment into a clearly defined target model.

The separation changed everything. Suppliers no longer need to understand the internal model at all. They just provide what they have. Accept first, improve second, and the process finally scales.

Four things to change

Get clear on structure before you touch tools or process. Be explicit about what usable data means for you, and keep that separate from how supplier data arrives. Blur those two and everything downstream gets harder.

Reduce friction without relaxing requirements. Those are different things. Low friction submission with good guidance produces better data than strict policing does.

Stop chasing perfection. You do not need every attribute before a product can move. Define a minimum viable set per product family, let the product progress, and improve it incrementally rather than blocking everything behind completeness.

Then use automation to close the gaps, so people spend their time reviewing and deciding.

Supplier data is not broken because suppliers do not care, or because your team is not working hard enough. It is broken because the way data comes in does not match the way it needs to be used. Fix that order and onboarding becomes a capability you can scale rather than a fight you keep having.

Listen to the full episode

Episode 19 of Product Data Weekly is available now. For more episodes and the weekly newsletter on operational issues inside product data and ecommerce teams, visit productdataweekly.com.