Planogram and Space Planning Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the fixture library end up describing stores that do not exist?

Because maintaining it is a data operation and the software is licensed as a drawing tool. Blue Yonder Space Planning and Nielsen Spaceman can both hold store specific planograms, so the capability is not the gap. The gap is that keeping a true fixture record for hundreds of stores across ninety categories requires input from people in those stores, and the only people with access to the system are the two or three planners drawing in it.

So the library holds ten or fifteen archetypes, every store is mapped to its nearest neighbour, and the mismatch surfaces at 11pm with a pallet on the floor. Nobody is at fault. The organisation has no route by which a store can tell the system that bay four is three feet wide.

The fix is to make the store the system of record and put fixture survey into the hands of the store or the reset crew. A tablet form capturing bay count, bay width, shelf positions, notch spacing, fixed versus adjustable shelves, base deck depth, peg zones and obstructions, with photographs attached, turns a one off consultant survey into a living record. Planograms are then generated per store from a category template plus that store's real fixture profile rather than assigned from a cluster. Every downstream benefit in this category depends on that one change, which is why it belongs in the first release and not phase two.

What goes wrong with item dimensions, pack shots and your existing planogram files?

Every project of this type hits the same wall in week three. The item master has dimensions and they are wrong. Case dimensions typed into unit fields. Heights measured to the cap on one item and the shoulder on another. Private label items with nothing at all, because nobody asked the factory when the item was set up. Half the catalogue has no usable pack shot either, so the drawing shows grey rectangles the crew cannot match to the product in their hands.

This is not a problem you can buy your way out of. Every tool in the category renders whatever dimensions you feed it, and bad dimensions produce a confident, attractive, unbuildable drawing.

The fix is to treat dimension and image capture as a first class workflow rather than an assumption. Parse supplier specification sheets and Global Data Synchronisation Network records where they exist. Where they do not, a capture station or a store tablet takes measurements and a pack shot straight into the catalogue with a confidence flag attached. Then apply a hard rule: items below a confidence threshold cannot enter a published planogram, they enter a work queue. Unglamorous, and it is the difference between a working system and a dead pilot.

The second data problem is your existing planogram files. If the space team cannot import their current work and export in a format their tools and their suppliers accept, adoption fails in month two regardless of how good the new system is. Category captains send you files in their format and expect files back. Make file interchange a named deliverable in release one, not a nice to have.

Why do the merchandising, replenishment and shelf label integrations break after launch?

All three break on the same underlying fact: they are downstream of decisions made by other teams who have no idea your system depends on them.

Merchandising item feeds break when a category admin changes a pack size, delists an item without a replacement, or sets up a new item with a placeholder dimension so it can be ordered on Monday. Nothing in that workflow warns the space system, so a published planogram silently references a product that is now a different size.

Replenishment breaks when a store's delivery frequency changes, which happens for operational reasons and is never treated as a space event. Facings computed against three deliveries a week become wrong when the store moves to two, and the symptom is empty shelves on Saturday afternoon rather than an error message.

Shelf edge labels break most visibly. Electronic labels and printed tags are entirely different plumbing, and a planogram change that does not produce the right tag file leaves the crew with correct product in front of wrong prices, which is the one failure a customer notices immediately.

The fixes are the same shape each time. Subscribe to change events rather than re-reading a nightly file and hoping. Flag any published planogram whose items have changed since publication, and hold it as an exception rather than republishing automatically. Reconcile counts on every import and fail loudly rather than parsing what you can. And treat label file generation as part of the publish action, not as a separate job someone runs afterwards.

What happens when compliance evidence and supplier funded reset obligations are not covered?

Ask most retailers their planogram compliance rate and you get a number from a clipboard sample or from a vendor with an obvious interest. Neither is evidence. The reset was marked complete because somebody pressed a button in a labour app.

That matters commercially, not just operationally. Supplier funded resets are a meaningful part of category economics, and category captains audit compliance whether you do or not. If they can photograph your bays and you cannot, the next negotiation happens on their data.

The fix is to close the loop at the fixture. The crew photographs each bay at sign off and the photo is compared against the planogram published for that specific store. Shelf level product recognition is genuinely usable for this and it is one of the few places in retail where the technology earns its cost outright. Two design points decide whether it works. First, the output should be an exception list rather than a compliance score: three bays wrong in store 214, named items, photograph attached, routed to the district manager the next morning. A score nobody can act on changes nothing. Second, expect lower detection on dense small item categories such as health and beauty than on chilled or grocery bays, and set the expectation before the pilot rather than after.

Should you build custom or configure what you already own?

Buy if you run fewer than about sixty stores with consistent fixtures. DotActiv gives you competent drawing, floor planning and analytics at a price a build cannot approach at that scale. Buy if space planning is a once a year exercise per category and your ranges are stable. Buy if your real problem is one space planner doing the work of three, because software does not fix a staffing shortfall and a new system will make it worse for a quarter.

Configure rather than build if your gap is specifically the link between space and replenishment. RELEX ties those together properly and is worth a serious evaluation before anyone writes code, because if that is your only unmet need you would be paying to reproduce a product that exists.

The honest tipping point is not store count, it is variance. A seven hundred store chain with three fixture standards and disciplined data can live in an off the shelf tool for years. A two hundred store chain assembled from four acquisitions cannot, because the product assumes an estate you do not have. Build when your fixture reality varies enough that cluster planograms are routinely unexecutable, when you cannot produce evidence of what is on shelf in any store today, when facings are set centrally against chain averages while store level movement varies widely, or when supplier funded resets are meaningful and you have no compliance evidence to show for the money.

How do hidden costs get into the quote?

Five items, each usually a single line.

The fixture survey itself. This is the largest cost in the whole programme and it is frequently outside the software quote entirely. Someone has to walk every store. Plan it as a parallel workstream starting in week one, not as a prerequisite that delays the build.

Fixture type count. Acquired banners bring their own standards, and each one is modelling work. Count your real fixture families before accepting an estimate.

Product recognition scope. A model reading a chilled dairy door and a model reading a health and beauty bay with three hundred small facings are different problems with different accuracy and different labelling effort. Ask which categories the quote assumes.

Shelf edge label integration. Electronic and printed are separate builds. If you run both, that is two.

File interchange with your current tool. Import and export in the formats your planners and suppliers use is real work and it is the thing that decides adoption.

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

Start with three categories and forty stores, and make sure two of those stores are your worst by fixture chaos. Those two teach you more than the other thirty eight, and a pilot that only covers tidy stores proves nothing about the estate.

The developer models the bay before they model anything else. A team that has done retail space will describe notch spacing, fixed and adjustable shelves, base decks, peg zones and obstructions, and will ask whether your bays are surveyed or assumed. A team that draws shelves as a number is about to build a very expensive picture.

Facings are computed rather than judged. The right number of facings keeps the shelf full between deliveries given case pack, capacity per facing derived from real item dimensions, and that store's rate of sale. The system should flag collisions before the reset, so the decision that this store cannot hold the full range at safe days of supply is made in the office rather than improvised by a crew with a pallet at 11pm.

Publication is gated on data quality. Unverified items cannot enter a published planogram. It sounds restrictive and it is the single rule that prevents the failure everyone in this category has lived through.

And ownership is settled before kickoff: the repository, the cloud accounts, the labelled shelf images and any fine tuned model weights. At Digital Heroes the client owns all of it from the first commit. Image data is the part developers most often try to retain, because a labelled shelf image set from your own estate is the expensive asset, and an agency hosting the model on their side is renting your own photographs back to you.