Planogram and Space Planning Software: Why Your Resets Cannot Be Executed as Drawn

Why a planogram fails at the shelf and not on the screen

Reset night, 9pm, store 214. Four people from a merchandising crew stand in front of a 40 foot cereal run with printed planograms in a binder. The drawing shows twelve four foot bays at seven shelves each. The actual run is eleven bays, one of them is three feet because a structural column eats the corner, and two bays are older fixtures whose top shelf is fixed at a height the drawing does not know about. The crew improvises. They drop two facings of the slow granola, wedge the new launch in at the bottom, and finish at 1am. The reset is closed out in the labour system, so head office believes store 214 is running the approved planogram. It is not, and nobody finds out until a supplier field rep photographs the bay in March.

The stack around this is almost always the same: a space planning seat or two on Blue Yonder Space Planning or Nielsen Spaceman, a fixture library maintained by one person who inherited it, floor plans last surveyed when the store was remodelled, item dimensions typed in by a category admin, POS (Point of Sale) movement the space team queries through an analyst, and product images on a shared drive. Nobody owns the join. The planogram is drawn against an idealised store that exists nowhere in the estate.

The cost lands in three places. Reset labour gets paid twice, once to execute and once to fix. New launches underperform because the item ended up somewhere the drawing never intended. And supplier confidence erodes, which matters because your category captains audit compliance whether you do or not.

Problem 1: the fixture library is a work of fiction

Every space planning tool assumes a fixture library that describes real bays: width, depth, shelf count, shelf heights, notch spacing, base deck depth, peg board zones, and whether the run is straight, an endcap, or wraps a corner. In practice that library holds ten or fifteen archetypes, every store is mapped to the nearest one, and the mismatch only shows up at 11pm with a pallet on the floor.

Blue Yonder Space Planning and Nielsen Spaceman can both hold store specific planograms. That is not the gap. The gap is that maintaining a store specific fixture record for 400 stores across 90 categories is a data operation, and those tools are drawing and optimisation engines licensed per seat to a small central team. So the data never gets maintained, because the only people with access are the people drawing. DotActiv and RELEX are more accessible and RELEX in particular ties space to replenishment properly, but both still start from a fixture library somebody has to keep true.

What a custom build does: makes the store the system of record and puts fixture survey into the hands of the store or the reset crew. A tablet form that captures bay count, bay width, shelf positions and obstructions, with photos attached, turns a one time consultant survey into a living record. Then planograms are generated per store from a category template plus that store's actual fixture profile, not assigned from a cluster. The drawing that arrives on reset night matches the run in front of the crew, which is the entire point and the reason every other benefit downstream becomes possible.

Problem 2: compliance is claimed, never proven

Ask a retailer what their planogram compliance rate is and you get a number from a sample audit done by district managers on a clipboard, or a number supplied by a vendor with an obvious interest. Neither is evidence. The reset was marked complete in a labour app because somebody pressed a button.

No space planning tool solves this because compliance is not a space planning problem, it is a field execution problem with a photo in it. The tools produce the intent. Nothing in the standard stack closes the loop on what actually happened at the fixture.

What a custom build does: the crew photographs each bay at sign off and the photo is compared against the planogram published for that store. Shelf level product recognition is genuinely usable for this and it is one of the few places in retail where AI earns its cost outright. The output should be an exception list rather than a compliance score: three bays wrong in store 214, named items, photo attached, routed to the district manager the next morning. We would rather ship a build that catches 80 percent of deviations and names them than one reporting a confident 96 percent nobody can act on.

Problem 3: facings are set by eye, not by days of supply

A facing is not a design decision, it is an inventory decision. The right number of facings is the one that keeps the shelf full between deliveries given case pack, capacity per facing, and the item's rate of sale in that store. Get it wrong low and the top seller is empty by Saturday afternoon. Get it wrong high and you are holding a week of dead granola in prime eye level space.

This is where most space work quietly fails: the planogram is drawn against chain average movement, then applied to a store whose cereal mix is nothing like the chain average. RELEX handles the space to replenishment link better than most, and if that is your only gap, look at them seriously before commissioning anything. It still breaks when your replenishment logic, delivery frequency and minimum presentation quantities live in your own systems and do not map onto anyone else's model.

What a custom build does: compute facings from store level movement, capacity per facing derived from real item dimensions, delivery frequency for that store, and a minimum presentation rule per category. Then flag the collisions before the reset rather than after: this store cannot hold the range at safe days of supply, so either the range drops two items here or the bay gets a shelf. That decision made in the office is cheap. Made at 11pm by a crew with a pallet, it is a guess.

Problem 4: item dimensions and images are the actual blocker

Every planogram project 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. 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. Blue Yonder, Spaceman and DotActiv all render whatever dimensions you feed them, and bad dimensions produce a confident, beautiful, unbuildable drawing.

What a custom build does: treat dimension and image capture as a first class workflow rather than an assumption. Supplier spec sheets and GDSN records get parsed for dimensions 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. Items below a confidence threshold do not enter a published planogram, they enter a work queue. Unglamorous, and the difference between a working system and a dead pilot.

Problem 5: the reset calendar has no idea what a reset costs in labour

Resets compete with promotional set up, seasonal changeovers, counts and remodels, and the coordination happens in a shared calendar and a chain of emails. A custom build holds one reset calendar per store with hours estimated from the actual planogram change, meaning items moved rather than a flat hours per bay assumption. Then it answers the question the space team is always asked and can never answer: what does this range change cost in store labour across the estate, and can the stores absorb it in November.

What this costs and how long it takes

A focused first release, meaning the store fixture record with tablet survey, per store planogram generation from a category template, facing calculation from store movement, and reset packs the crew can actually follow, runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding photo based compliance with product recognition, the reset calendar with labour modelling, supplier and category captain portals, shelf label and tag file generation, and two way sync with your merchandising and replenishment systems runs $180,000 to $450,000 phased over 6 to 12 months.

What pushes the number up in this category specifically: the number of fixture types across the estate, because acquired banners bring their own; whether you need to import and export existing planogram files so the space team can keep working in their current tool during transition; product recognition scope, since a model that reads a health and beauty bay with 300 small facings is a harder problem than a chilled dairy door; and shelf edge label integration, since electronic labels and printed tags are entirely different plumbing. What keeps it down: start with three categories and 40 stores, including your two worst stores by fixture chaos, because those two teach you more than the other 38.

Build versus buy, and when buying is the right call

Buy if you have fewer than about 60 stores with consistent fixtures. DotActiv gives you competent drawing, floor planning and analytics at a price that a build cannot compete with 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.

Build when two or more of these are true. Your fixture reality varies enough that cluster planograms are routinely unexecutable. You cannot produce evidence of what is actually on shelf in any store today. Facings are set centrally against chain averages while store level movement varies widely across the estate. You have grown by acquisition and now run three fixture standards and two space planning tools. Or supplier funded resets are a meaningful part of your category economics and you have no compliance evidence to show for the money.

The honest tipping point is not store count, it is variance. A 700 store chain with three fixture standards and disciplined data can live in an off the shelf tool for years. A 200 store chain built from four acquisitions cannot, and no amount of licensing will change that, because the product assumes an estate you do not have.

How to choose a developer for space planning software

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

Ask how they will handle item dimension quality, and reject any answer that assumes the item master is correct. The right answer includes a confidence flag, a capture workflow and a rule that blocks publication of a planogram containing unverified items.

Ask what happens to 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.

Ask who owns the code, the model weights if product recognition is in scope, and the image data, and get it written down before kickoff. At Digital Heroes the client owns the repository, the infrastructure accounts and the training data from the first commit. Any developer who wants to keep the recognition model on their side of the fence is selling you a subscription with extra steps.