Product Information Management Problems: The 7 That Cost Retailers Real Money, and How to Avoid Them

Why does a product information management build turn into a replacement for the ERP and the storefront?

The project that gets funded is narrow and correct: kill the master spreadsheet. Merchandisers are spending half their week reformatting files for Amazon, Walmart, a marketplace template and the storefront, and one bad lookup puts the wrong specification on hundreds of live listings.

Then scope drifts outward. If the system holds product data, should it not hold inventory. If it holds inventory, should it not price. Should it own the storefront content model. Should it replace what the enterprise resource planning (ERP) system does for cost and case pack. Within a few meetings a product data platform has become a competitor to NetSuite and to your commerce platform, and the merchandisers are still working from the spreadsheet.

What makes this expensive in retail specifically is seasonality. Your catalogue work is not evenly spread. A build that misses the window before a seasonal drop means another drop onboarded by hand, and the products earn nothing until they are live, so speed to list is revenue you cannot recover later.

The discipline is to define the system of record per field group and hold that line. The ERP wins for cost and case pack, merchandising wins for titles and copy, the supplier feed wins for materials and compliance data. In Digital Heroes delivery experience a focused first release covering the canonical catalogue with your real variant model, migration from spreadsheets with deduplication, completeness scoring and export to two channels runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding the supplier portal, the image pipeline, live syndication with the error feedback loop, ERP synchronisation and localisation runs $150,000 to $400,000 phased over 6 to 12 months. Start with the smallest release that kills your worst spreadsheet.

What goes wrong migrating a decade of spreadsheet catalogue data?

Migration is the dangerous part of this project and it is dangerous because live listings are downstream of it.

The specific problems are consistent. Identifier quality first: recycled barcodes, malformed identifiers, the same product under two internal codes because two buyers created it, and variants entered as separate parent products. Deduplicating on identifier alone will merge things that should not be merged and miss things that should.

Conflicting values second. The same field has a different value in the ERP, in the supplier line sheet, in the spreadsheet and in what is actually published on a marketplace, because somebody hotfixed a title in the seller portal two years ago and nothing pulled it back. Deciding which source wins is a business decision per field group, not a technical one, and it needs a merchandising lead who can make calls quickly.

Unit and format drift third. Dimensions in one unit for one channel and another elsewhere, weights recorded inconsistently, and copy that contains channel specific formatting baked into the value rather than applied at export.

The sequence that works is profile, deduplicate, define golden record rules, run dry imports, then run the new system in parallel with the spreadsheet on one channel before cutover. Live listings are never touched until the new output matches what is currently published, field by field. Treat migration as a named workstream with its own budget and its own owner, because the state of your spreadsheets sets the bill and ten years of inconsistent entry does not clean itself.

Why do the marketplace and ERP integrations break after launch?

Marketplace integrations do not break, they drift, and the drift is invisible until items stop selling.

Specification changes are the main cause. Marketplaces revise required attributes, valid values and category taxonomies several times a year, usually with notice that lands in an inbox nobody reads. A feed that validated last month starts producing partial failures, and if your pipeline treats a partial acceptance as success, some items simply never went live. Read the processing reports back, always, and map each error code to the exact field on the exact stock keeping unit rather than logging a count.

Throttling is the second. Submission and reporting interfaces enforce rate limits, and a pipeline that assumes unlimited throughput works fine on a small catalogue and falls over on a full re-syndication. That failure looks like a stalled job rather than an error, which is why it survives testing.

ERP synchronisation breaks on identity and on direction. If cost and case pack flow one way and merchandising data flows the other, a bidirectional sync without a clear per field owner produces a loop where two systems overwrite each other on alternating cycles. Define ownership per field, make the sync one directional per field, and reconcile rather than trusting the transfer.

The fix in every case is the same shape. Every feed reports its own health, a submission with no processing report inside an expected window raises an alarm, and a scheduled reconciliation compares what you believe is published against what the channel says is published. That last check is the one that catches suppression before the sales report does.

What happens when identifier and regulatory attributes are not covered?

Two data obligations get skipped in early scoping and both cause rejections that look like software faults.

Global Trade Item Number handling is the first. Validation on intake, including check digit arithmetic, is a small piece of work that prevents a whole class of marketplace rejections caused by recycled or malformed barcodes. Per channel identifier rules matter too, since channels differ in what they accept and in how they treat products that genuinely have no identifier. Aligning attribute naming to a recognised standard also makes every future channel mapping cheaper, because you are mapping from a defined vocabulary rather than from whatever a spreadsheet column was called.

Regulatory and compliance attributes are the second. Fibre content, material declarations, country of origin, safety and warning text, and state level disclosure requirements are product data with legal weight, and they usually arrive from the supplier rather than from merchandising. If the model has no home for them, they end up in a description field where nobody can query them, and when a customer disputes a claim you cannot prove what was published on which channel on which date.

Field level audit history is what closes that. Being able to reconstruct exactly what value was live on which channel on which date has settled chargeback disputes in projects we have delivered, and it costs almost nothing to build in at the start. If you sell into the European Union, ask your developer to reserve structure for digital product passport requirements rather than discovering the need later.

Should you build custom or configure what you already own?

For a large share of retailers the honest answer is buy, and we say so regularly.

If your catalogue is under roughly 10,000 stock keeping units in standard categories on two or three channels, with attributes the existing connectors already understand, Akeneo or Plytix will serve you well, and Akeneo's Community Edition is free and open source. Below about 2,000 items, a disciplined spreadsheet with a bulk import tool is genuinely defensible. Do not build to save money in year one, because you will not.

The other honest case is that many teams own a capable product and never finished the implementation. Attribute groups were never defined properly, completeness rules were never configured, and the channel connectors were set up once for the vanilla path and never revisited. If that describes you, finishing the configuration is faster and cheaper than replacing anything, and any developer who will not say so is not being straight with you.

Where these products genuinely run out is at three places. Your product model, if bundles, kits, components, units of measure and regional variants do not fit the vendor's variant scheme. Channel specifics, since state level compliance text, per channel unit conversion and category specific title formulas land in implementation consulting and every future change routes back through it. And licence shape, since seats, item counts and locales are metered, which is why the freelance copywriters end up working in spreadsheets and pasting back in.

The deciding question is whether product data is a competitive weapon for your business or plumbing. If speed to list and catalogue breadth are how you win, build. If not, buy the plumbing.

How do hidden costs get into the quote?

Five things drive a product information management quote and only the first is usually named.

Each additional marketplace integration is its own project with its own interface quirks and certification steps, and the third is not a third of the effort of the first. Bidirectional ERP synchronisation adds engineering and testing weight. Configurable bundles, kits and cut to size products complicate the data model in ways that touch everything downstream. Large image volumes need real processing infrastructure rather than a folder. And the state of your spreadsheets sets the migration bill.

Then the ones that never appear on a proposal. Your merchandisers' time, because only they can decide which conflicting value wins and what the channel specific transformation rules actually are, and that decision load is heavy in the first six weeks. Parallel running on one channel before cutover, which is real hours during a period when the team is still doing the old process too. Supplier onboarding, since a supplier portal only helps once suppliers use it, and getting them there is relationship work rather than engineering. And ongoing integration upkeep, because marketplaces change specifications several times a year and a system that is finished at launch is a system that degrades from launch.

Budget for maintenance explicitly rather than assuming the build ends.

What separates a build that works from one that fails here?

Make them draw the product data model before anything is signed. A team that has built this asks immediately about variant dimensionality, parent and child relationships, kits and bundles, unit conversions and channel level overrides. A team that has not will sketch a products table and promise flexibility later, and you will pay for that promise in month five.

Demand marketplace scars. Ask specifically how they handle processing reports, throttling and specification version changes on the channels you actually sell on. Vague answers about integrating any interface mean you are funding their education on your catalogue.

The builds that work treat channel requirements as data rather than as code. A schema registry per channel, transformation rules a merchandising lead can edit in an administration screen, and pre-flight validation that runs the channel's own rules before a feed ever leaves the building. That last part is what turns a rejection into a warning, and it also means onboarding a new merchandiser is reading a rule set rather than months of shadowing.

The builds that fail leave transformation logic in code, which means every seasonal change is a developer ticket, and the team quietly goes back to the spreadsheet because it is faster.

The other marker of a serious build is completeness scoring that is channel specific rather than generic. An item is ready for one channel at one hundred percent of that channel's required fields and not ready for another, and expressing readiness that way is what makes speed to list measurable rather than anecdotal.

Get code ownership in writing as work for hire, with the repository in your own organisation from the first commit and documentation and deployment scripts named as deliverables. A developer who resists that is offering you a dependency rather than an asset.