Assortment Planning Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does store clustering get scoped on sales volume so often?

Because volume is the one number every retailer already has, clean, for every store, going back years. Nothing else is that easy to reach. Attribute level sell through requires tagged products. Trading area and demographic data require external sources. Size profile by store requires transaction detail nobody has queried in a while. So the clustering runs on volume, the output looks orderly, and the flaw is invisible until the season ends.

What makes it specific to assortment work is that a volume cluster is not merely imprecise, it is systematically wrong in one direction. High volume stores tend to be high traffic locations in markets with very different customers, so a volume cluster reliably groups an urban store with a suburban one that shares nothing except a revenue line. That is close to the worst possible grouping for range decisions.

Cluster instead on demand behaviour at attribute level, meaning share of sales by colour family, price tier, size profile and occasion, combined with store physical and market attributes such as trading area, climate zone and competitor proximity. Then constrain the result to something your buying team can operate. Fifty statistically optimal clusters are useless because nobody can manage fifty ranges. Six to twelve, stable across a season, with a documented reason each store sits where it does, is a tool people will use. Flag the marginal members explicitly, because those stores are where localisation actually earns its keep and they are invisible in a cluster list.

What goes wrong when you normalise attributes across historic seasons?

This is where assortment projects lose their schedule. Every meaningful question in this discipline is an attribute question: are we over indexed in dark neutrals, is there a gap at the opening price point in the mid size range, did last season's sell through vary by sleeve length or by fabric. None of those can be answered if history carries a description field, a vendor style number and a department code.

So the project starts with retro tagging, and retro tagging goes wrong in three predictable ways. First, the taxonomy is defined by the project team rather than by merchants, which produces controlled values nobody uses and a second shadow taxonomy in spreadsheets within a season. Second, the tagging is bulk applied with no confidence scoring and no review, so errors enter silently and every model built on that history inherits them. Third, the taxonomy is not versioned, so when a merchant adds a value mid project the history becomes inconsistent in a way that is hard to detect later.

Treat attributes as a governed asset. Define controlled values per category with merchants in the room, version the taxonomy with effective dates, and run extraction from product copy, vendor specification sheets and images as a proposal with a confidence score into a merchant review queue rather than as a direct write. The queue is the important part. Extraction accuracy is a tuning problem and it will improve. A wrongly tagged season is a permanent defect in the foundation of your clustering, your like item modelling and your transference model, and nobody will find it until the numbers stop making sense.

Why do space planning and merchandising integrations break after launch?

The space planning link is the first. Capacity data lives in a planogram system in formats built for drawing fixtures rather than for constraining a plan, and mapping it is real work rather than a connector. After launch, the failure is drift: stores get refitted, fixtures change, a format is refreshed, and the capacity figures in the plan quietly stop describing the estate. A plan constrained by stale capacity is worse than one with no capacity data at all, because it carries authority. Build a freshness expectation into the integration, show the date the capacity for a cluster was last confirmed, and treat an unrefreshed figure as a warning on the planning screen rather than a silent assumption.

The merchandising system link is the second, and it fails on write rather than read. Generating item setup from an approved assortment is straightforward until the hierarchy changes, a supplier record is restructured or a new attribute becomes mandatory upstream. Then the handoff starts rejecting records, and because the rejections land in a technical queue nobody is watching, buyers discover it when items do not appear. Route integration failures to a merchandising person with a name, not to a system administrator, and stamp the approved assortment version on every generated record so any line can be traced back to the decision that produced it.

What happens when fixture capacity and vendor packs are not constraints?

This is the gap that produces the photograph from a district manager: seven options stacked in the back room of a small format store while a flagship with three bays runs the same range and looks thin. Both stores will mark down, for opposite reasons.

It happens because the assortment decision is made in options and units while the store operates in facings, linear feet, shelf depth and fixture type. If capacity enters as a validation report after the plan is built, it is advisory, and advisory constraints lose to merchant advocacy in every line review. As a hard constraint during planning it changes the conversation entirely: this cluster holds eleven facings, presentation minimum is two units per facing, so the maximum viable option count at acceptable depth is a number, and if you want another option the system asks what comes out. That is what a planning tool is for.

Vendor packs are the same failure in the buying direction. A plan that cannot be bought in the pack configurations and minimums your suppliers actually sell is not a plan, it is a wish, and the reconciliation happens in a buyer's spreadsheet weeks later with nobody recording what changed. Apply pack constraints and order minimums inside the planning step, so the depth you approve is a depth you can purchase. The compounding effect is what makes this worth fixing: an unconstrained plan generates a buy that gets adjusted, the adjusted buy gets allocated against the original plan, and the variance analysis at the end of the season compares actuals to a plan that was never executable.

Should you build custom or configure what you already own?

This is not a build by default category, and we would rather say so early. There are serious products here. Oracle Retail Assortment Planning is deep and suits conventional processes with a standard merchandise hierarchy. Blue Yonder is credible at scale. RELEX Solutions is strong in grocery where forecasting, space and replenishment need to work together. Nextail handles localisation and allocation well in fashion. First Insight approaches the problem from a different angle entirely by testing consumer response to product before you buy it, which may be more valuable than any planning grid if your real question is what to buy rather than where to send it.

The honest limitation of the packaged options is that each expects your attributes, clustering approach and hierarchy in a particular shape, and where yours differs you either reshape the business or extend inside their framework at their pace. That is a real cost and also a real discipline, since many retailers discover their process was idiosyncratic rather than differentiated.

Build when two or more of these are true. Your attribute taxonomy is genuinely a competitive asset, which is common in specialty retail where merchandising judgement is the business. Your formats differ enough that fixture capacity has to be a first class constraint. You already hold clean sales history in a data platform, which removes the largest cost from a build. You implemented a packaged assortment tool and abandoned it because merchants would not adopt it. Or your category mix spans buying rhythms so different that one vendor model cannot serve both.

How do hidden costs get into an assortment planning quote?

Category count is the first and the most consistently underestimated. A taxonomy that works for apparel does not transfer to hardlines, and each category needs merchant time to define controlled values, agree what drives variance, and validate the tagged history. A quote priced for one category will not cover four. Ask for the scope to be written per category.

History quality is the second and it is the largest single variable. Attribute normalisation across several seasons is genuine effort even with extraction assistance, and the price depends on how consistent your product data has been, which nobody can know without sampling it. Insist on a sample from your messiest category before the number is fixed.

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

The successful projects do two categories at cluster level for release one and defer store level localisation until the clusters have proven themselves across a season. The failed ones try to localise everything immediately, produce a technically impressive system, and hand merchants more decisions than they have hours to make.

The second difference is merchant ownership. Assortment planning is not a system merchants use, it is a system that encodes their judgement, and that only works if they defined the attributes, agreed the cluster count and accepted the capacity constraints. Projects where merchandising leads and technology supports get adopted. Projects run the other way produce a tool that is quietly bypassed with a spreadsheet, which is exactly the pattern that made a previous packaged implementation fail.

Third, prove it backwards before you plan forwards. Take last season, run your clustering and your option count logic against it, and compare the ranges the system would have produced with what actually happened. That exercise finds broken assumptions faster than any amount of specification review and it builds credibility with the merchants whose adoption you need.

Finally, settle ownership before kickoff, including the repository, the cloud accounts and any models trained on your product data and images. At Digital Heroes the client owns all of it from the first commit. An attribute model built from your own assortment history is precisely the asset you should never leave in someone else's account.