What assortment planning software actually decides
Assortment planning software decides which SKUs you carry, in which stores, and at what depth, before the period starts. It reads sell-through by store cluster, scores each SKU against the benchmark for that cluster, and produces a range: a list of SKUs per cluster with depth attached. Everything else in the category is machinery for getting to that list.
Enterprise suites bundle the range decision with space planning, allocation, and open-to-buy, then hand it to a planning organization to run. Lighter tools handle the range decision on its own and read from the POS and inventory systems already in place. Which one fits is mostly a question of whether you have planners to operate the suite.
Three assumptions the enterprise suites make
Oracle Retail, Blue Yonder, RELEX, and SAP all build capable assortment modules. They assume three things a 40-to-400-store chain usually does not have.
01
A planning organization
The suite produces a plan a planner reviews, adjusts, and publishes. With no planner in the seat, the module runs unattended and its output goes unread. Most mid-market chains run assortment out of merchandising, part time.
02
Clean item master data
Category hierarchies, attributes, and store attributes have to be complete before clustering means anything. The cleanup is usually the project, and it is quoted separately from the license.
03
A rollout window
Six to nine months from signature to first published range is normal. That is two selling seasons of decisions made the old way while the implementation runs.
None of that makes the suites wrong. It makes them the wrong first purchase for a chain that needs the range decision this quarter and has nobody to staff a planning function.
How Ward builds the range
Four steps, all of them running on data your registers and inventory systems already produce.
01
Cluster the stores
Stores group by demographic, traffic, and sales pattern rather than by region. A downtown store and a suburban store in the same district usually belong in different clusters, which is the thing a regional rollup hides.
02
Benchmark every SKU
Each SKU is scored against its cluster, not the chain average. A SKU that looks dead estate-wide is often carrying one cluster, and a SKU that looks healthy is often being propped up by two stores.
03
Find the whitespace
Where a cluster underperforms its peers on a category, Ward names the SKUs the comparable cluster carries and this one does not. That is the add list, with the gap quantified.
04
Route the decision
Output is an insight card naming the cluster, the SKUs, and the expected impact, sent to whoever owns the category. Not a dashboard someone has to open and interpret.
Cluster B stores (urban, high-traffic) underperforming on premium snacks vs Cluster A by 34%. Assortment gap: 12 SKUs missing.
Enterprise suite, spreadsheet, or a signal layer
Three real ways to make the range decision. The honest comparison is not on feature count, it is on what each one needs from you before it produces anything.
|
Enterprise suite |
Spreadsheet + BI |
Ward |
| Time to first range recommendation | 6 to 9 months | Weeks per category, every time | 48 hours |
| Planning team required | Yes, to operate it | Yes, an analyst | No |
| Master data cleanup first | Yes, usually the project | Manual, per refresh | No, reads as-is |
| Store clustering | Configurable, planner-driven | By region, if at all | Automatic, behavioral |
| Runs again after go-live | On the planning calendar | When someone rebuilds it | Continuously |
| Writes back to the planner | Yes | No | Yes, closed loop |
| Also does space and allocation | Yes | No | No |
| Cost model | License + implementation | Analyst salary | Software only |
If you have planners and a space-planning requirement, buy the suite. If you need the range decision and do not have a planning function to build around it, the suite is a nine-month detour to a list you could have had this week.
Planning sets the range. Management keeps it honest.
Planning is a forward decision: what the range should be for the period ahead, built from cluster behavior and whitespace. It happens on a calendar, ahead of the season or the reset.
What happens after the range ships is a different job. SKUs decay, localization drifts, and the tail grows back between reviews. That work is continuous, and it is covered on assortment management software. Most chains need both. They buy them as one thing, then discover the suite planned a range nobody rationalized for two years.
The first 30 days
Week 1. Read-only connections to POS and inventory. Store clusters form and every SKU gets a cluster-relative baseline. First cards arrive at 48 hours, on the clearest gaps.
Week 2. Category owners review the drop list. This is where you find out how much of the tail is genuinely dead and how much is one cluster's core range being read as chain-wide noise.
Week 3. Whitespace cards go to merchandising with the comparable cluster attached, so the add decision has a reference range rather than an opinion.
Week 4. Measure. Take the SKUs actioned in weeks two and three and compare post-change velocity against the cluster benchmark. That number, not the size of the recommendation list, is whether it worked.
Assortment planning by vertical
Cluster logic and range cadence differ by format. The vertical pages carry the specifics.
Metrics this moves