LOADING CASE STUDY

When Chocolate Has No Spine:
PIM as the Catalog Nervous System

A global confectionery brand with dozens of SKUs, flavors, formats and bundles looked powerful on a slide, but fragile in reality. Changes in packaging, naming or composition took months to reach distributors and marketplaces. We didn’t “polish the catalog”. We gave it a spine.

01 // THE LAG

Three to Six Months of Being Technically Wrong

At this scale, “product” is not a single bar or box. It’s a tree: SKUs, flavors, grammage, multipacks, seasonal editions, bundles. For a brand like this, the catalog is reality. When the catalog is wrong, reality doesn’t reach the shelf.

Before we touched anything, the cycle looked like this: HQ changes something in a product — packaging design, wording on the label, size, composition. Then everyone waits. Distributors update their systems on their own schedule. Sellers update graphics when they have time. Marketplaces eventually show some version of the truth.

"By the time the new chocolate bar ‘existed’ online, it was already old news in the factory."

In practice this meant 3 to 6 months of latency between “we decided” and “the customer actually sees it correctly”. For a brand fighting for space in the cart, that’s not just sloppiness, that’s direct economic loss.

FIG 1.0 // CATALOG UPDATE LATENCY (BEFORE VS AFTER)
Before PIM Spine
Fragmented
HQ → Distributors 4–8 weeks
Distributors → Sellers 2–8 weeks
Sellers → Marketplaces “When we get to it”
Multiple local files, manually patched layouts, e-mails and chats. At the end of the chain, chocolate bars on screen simply didn’t match what was shipping out of the warehouse.
After PIM Spine
Centralized
HQ → PIM Same day
PIM → Distributors Hours
PIM → Marketplaces Export window
One canonical source of truth for every SKU and bundle. When something changes in a product, it doesn’t go into an email thread — it flows through the spine.

For the team this was the first “oh” moment: the problem wasn’t that someone was lazy. The problem was that there was no nervous system.

02 // WHAT THE PIM ACTUALLY DID

Not a Database. A Backbone.

When I first described a PIM solution, it sounded to them like “one more system”. Only after mapping their SKU universe did it become clear: this isn’t yet another tool, this is the only place where the whole brand can be seen at once.

We structured not just SKUs, but the logic around them: flavors, multipacks, boxes, limited editions, seasonal packaging — the real portfolio, not just a price list.

FIG 2.0 // DATA SPINE: FROM HQ TO SHELF
HQ (Brand Team)
Owns the meaning of each SKU: recipe, messaging, visual identity and role in the portfolio. Previously: locked in decks and local files.
PIM Core
Canonical record of every product variant and bundle. Attributes, images, descriptions, constraints. The place where “we changed something” becomes structured data instead of a story.
Distributors
No longer retyping or reinventing specs. Pulling from the same spine, with clear mapping to their own systems and languages.
Marketplaces / Retailers
Receive consistent, up-to-date product cards and bundles ready to publish. When a label changes, the shelf reflects it without a seasonal delay.
What Changed in Practice Instead of waiting months until “all the sellers update their cards”, headquarters finally had a lever. New packaging? New flavor? Corrected ingredient line? It went into the spine once, then flowed to the market as a controlled export, not as hundreds of manual edits.

The funniest part: for them it was a “discovery” that such a solution even exists. For the brand, this “one more system” quietly removed a whole layer of operational waiting and errors.

You can’t seriously build modern FMCG presence across marketplaces if every part of your catalog lives in a different file. The PIM spine turned “messy but familiar” into “boring but predictable”. Which is exactly what you want for product data.

03 // LESS ROMANCE, MORE CORRECTNESS

The Silent Effect: Fewer Errors, Faster Moves

No customer will ever say “thank you for your PIM implementation”. They will simply stop encountering wrong images, obsolete packaging and random differences between online and offline shelves.

Internally, though, the difference was obvious: what previously took quarters could now be planned in weeks — because time was no longer spent unblocking the same catalog problems over and over again.

FIG 3.0 // ERROR HEAT STRIP
Catalog Inconsistency Across Regions & Channels
Error cluster “before” – misaligned images, names, compositions Residual noise “after” – edge cases, not systemic chaos

There is no dramatic “before/after” graph here. Just the very specific relief of brand and distributor teams that no longer had to spend entire seasons synchronizing what should have been synchronized from the beginning.

// FINAL EXECUTION LOG STATUS: PIM SPINE INSTALLED
Portfolio Mapping COMPLETE

Full structure of SKUs, flavors, packs, bundles and seasonal editions captured in a single model instead of scattering across decks and local files.

PIM Implementation DEPLOYED

Introduced a proper PIM solution as the canonical source of truth, connecting HQ, distributors and marketplaces via one controlled backbone.

Export Discipline IN USE

Established a cadence for pushing updates out of PIM instead of relying on ad hoc seller-by-seller edits, which previously took months.

// IMPACT TELEMETRY DATA SOURCE: POST-ROLL OUT
STREAM: SPEED
3–6 months → weeks
Catalog Update Latency
Packaging and composition changes now reach the shelf within planning cycles, not long after campaigns have ended.
STREAM: ERRORS
Systemic → Local
Nature of Catalog Issues
“Everyone has a different version” turned into isolated edge cases, not a permanent background condition.
STREAM: EXECUTION
Unlocked
Campaign & Launch Planning
Brand and trade teams could finally plan launches and promos knowing the catalog would follow, instead of budgeting time to clean up after it.
← Return to Experience Logs