Assortment Planning Software: Deciding Which Options Reach Which Store Cluster When Fixtures Set the Limit

Why assortments fail in stores that were never going to hold them

Line review for spring. The category plan says 18 options per store across four price tiers. It is signed off, bought, and allocated. In week three a district manager sends a photo from a 4,200 square foot store where the fixture holds 11 facings, so seven options are stacked in the back room or crammed onto a fixture where nothing merchandises properly. Meanwhile a flagship with three bays of space is running the same 18 options and looks thin. Both stores will end the season with markdowns, for opposite reasons, and the post mortem will blame allocation.

It was not allocation. It was a range decided in a spreadsheet that had no idea what those two stores physically hold or who shops in them. The clustering behind it grouped stores by total sales volume, which is the one attribute almost guaranteed to put a high volume urban store with a completely different customer next to a high volume suburban one.

The tools in this space are real and some are strong. Oracle Retail Assortment Planning is deep. Blue Yonder and RELEX Solutions are credible at scale. Nextail does localised ranging and allocation well in fashion. First Insight approaches the problem from a different direction entirely, testing consumer response to new product before you buy it, which is a genuine capability rather than a planning grid. The gap that sends retailers toward a build is narrower than the vendors' marketing suggests, and it is usually about two things: your product attribute taxonomy, and your physical capacity data.

Problem 1: clustering on volume groups stores that have nothing else in common

Volume tells you how much a store sells, not what it sells or why. Two stores with identical revenue can differ completely in size mix, colour preference, price tier response, seasonality and basket composition. Cluster on volume and you range them identically, then wonder why one sells through at full price and the other marks down.

What a proper build does: cluster on demand behaviour at attribute level, meaning share of sales by colour family, price tier, size profile, occasion and any other attribute that matters in your category, plus store physical and market attributes such as trading area, climate zone, demographic profile and competitor proximity. Then, critically, constrain the clustering to be operationally usable. Fifty statistically optimal clusters are useless because your buying team cannot manage 50 ranges. Six to twelve clusters that are stable across a season, with a documented reason each store sits where it does, is a tool people will use. The system should show which stores are marginal members, because those are the ones where localisation earns its keep.

Problem 2: fixture capacity is physical, finite, and absent from your planning data

This is the gap that produces the back room photo. The assortment decision is made in units and options while the store operates in linear feet, facings, shelf depth and fixture type. Space planning teams hold that data in a planogram system, and it typically reaches the assortment conversation as an opinion rather than as a constraint.

What a proper build does: bring capacity into the plan as a hard constraint per cluster and, where it matters, per store. Option count and depth are then solved against the space that exists: this cluster holds 11 facings, presentation minimum is two units per facing, so the maximum viable option count with acceptable depth is X. When a merchant wants to add an option, the system says what comes out. That single behaviour changes the tone of a line review from advocacy to trade off, which is what a planning tool is actually for.

Problem 3: attributes are the language of assortment and your item master does not speak it

Every meaningful assortment question is an attribute question. Are we over indexed in dark neutrals. Do we have a gap at the opening price point in the mid size range. Did last year's sell through vary by sleeve length or by fabric. If your item master has a description field, a vendor style number and a department code, none of those questions can be answered without a manual tagging exercise that takes weeks and is out of date on arrival.

What a proper build does: an attribute taxonomy per category with controlled values, versioned, plus normalisation of legacy items so history is usable. This is where AI does honest work: extracting attributes from product copy, vendor specification sheets and product images, proposing values against your taxonomy with a confidence score for a merchant to confirm. Retro tagging several seasons of history is a slow manual job that a model turns into a review queue, and without that history your clustering and your new item modelling both run on sand.

Problem 4: new items have no history and that is the whole point of assortment

The items you most need to plan are the ones you have never sold. Planners handle this by picking a like item, which is a reasonable heuristic executed badly, because the like item is usually chosen from memory rather than from attribute similarity, and nobody records the choice.

What a proper build does: model a new option against the attribute profile of comparable historic items, weighted by how similar they are on the attributes that actually drove variance in that category, and record the comparison so the forecast can be reviewed later. Demand transference matters here too: adding a fifth navy option rarely creates new demand, it usually takes it from the other four, and a plan that treats every option as incremental will always over buy. Modelling transference requires clean attributes, which is why problem three comes first and cannot be skipped.

Problem 5: the plan dies at the handoff

An approved assortment must become item setup in the merchandising system, a buy against vendor packs and minimums, an allocation plan by store, and a planogram request for space planning. In most retailers those are four spreadsheets emailed to four teams, each of which rekeys and interprets. By the time product arrives, what is in the warehouse does not match what was planned, and nobody can say exactly where it diverged.

What a proper build does: one approved assortment version that generates the downstream artefacts directly, with the version stamped on each so the origin of any line is traceable. Vendor pack configurations and order minimums are applied inside the plan rather than discovered later by a buyer, because a plan that cannot be bought in the packs the vendor sells is not a plan.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this category has a fairly consistent shape. A focused first release covering the attribute taxonomy with extraction assistance, multi factor clustering, and option and depth planning against fixture capacity for one or two categories runs $80,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding new item modelling with transference, store level localisation, vendor pack and minimum handling, and generated handoffs into allocation, item setup and space planning runs $220,000 to $500,000 phased over 8 to 14 months.

What drives cost up specifically: category count, since a taxonomy that works for apparel does not transfer to hardlines and each category needs merchant input to define. Store level localisation beyond clusters, because per store optimisation multiplies both computation and the number of decisions someone has to review. Space planning integration, as planogram systems hold capacity in formats that need real mapping work. And history quality, which is the largest variable, because attribute normalisation across several seasons is genuine effort even with model assistance.

What keeps cost down: two categories and cluster level planning for release one, with store level localisation deferred until the clusters have proven themselves for a season.

Build versus buy, and this market has serious vendors

Buy, and evaluate properly, because assortment planning is not a category where you should build by default. If your process is broadly conventional and your merchandise hierarchy is standard, Oracle Retail Assortment Planning or Blue Yonder will do the job with a real implementation effort behind them. If you are in fashion and the pain is localisation and allocation together, Nextail solves a well defined slice quickly. If your true problem is choosing which new products to buy at all, First Insight is addressing a different question through consumer testing and may be more valuable than any planning grid. In grocery, RELEX Solutions is strong and integrates forecasting and space in a way that suits high frequency replenishment categories.

The fair limitation of the packaged category is that these systems come with a view of your data. They expect an attribute model, a clustering approach and a hierarchy shaped a particular way, and where yours differs you spend the implementation reshaping your business to fit or building extensions inside their framework at their pace.

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 must be a first class constraint rather than a post plan check. You already hold clean sales history in a data platform, which removes the largest cost from a build. You have 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 to choose a developer for assortment planning software

Ask how they would cluster stores and, more importantly, how they would constrain the number of clusters to something a buying team can operate. A developer who returns statistically optimal clusters without asking how many ranges your merchants can manage has solved a maths problem rather than a retail one.

Ask how fixture capacity enters the plan. If it appears as a validation report after the assortment is built, you will keep getting the back room photo. It has to be a constraint during planning.

Ask how they will normalise attributes across historic seasons, and what the merchant review workflow looks like. If the answer is a bulk import with no confidence scoring and no review queue, your history will be tagged wrongly and every model built on it will inherit the error.

Ask who owns the code and get it in writing 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, and an attribute model built from your own assortment history is exactly the asset you should never leave in someone else's account.