What assortment management software does
Assortment management software keeps a live range correct. It watches how every SKU performs in every store after the range is set, then flags the ones that no longer earn their space: dead SKUs holding facings, items overstocked in the wrong cluster, gaps opening where a store's demand moved. The unit of work is a change to a range that already exists.
That is a different job from deciding the range in the first place. Assortment planning software builds the range ahead of a period from cluster behavior and whitespace. Management is what happens for the eleven months afterward, and it is the half most chains do not staff.
Four things that go wrong in a live range
01
The tail grows back
Every range review cuts dead SKUs. Then vendors push new items, buyers add one-offs, and seasonal carryover never gets pulled. Within a year the tail is back at the size it was before the cut, holding the same facings.
02
Localization drifts
Store clusters are set once and stores keep changing. A location whose trade area shifted is still carrying the range for the cluster it belonged to two years ago, and its sell-through quietly separates from its peers.
03
Depth stops matching demand
The SKU is right and the facing count is wrong. Overfaced items tie up capital and drive markdowns; underfaced items go out of stock mid-week and read as a replenishment problem instead of an assortment one.
04
Nobody owns the drop
Adding a SKU has a sponsor. Dropping one has none. Without a routed owner and a number attached, the delist decision defers to the next review, and then the one after that.
All four are visible in POS and inventory data long before they show up in a category P&L. They stay invisible because nothing is looking between reviews.
03
ProblemThe cost of waiting
What review cadence costs you
Assortment management is usually bought as a calendar: an annual range review, sometimes quarterly for fast categories. The cost of that calendar is the time a bad SKU keeps its space after it stopped earning it.
| Review cadence |
Average delay on a delist |
What it needs to run |
What it catches |
| Annual range review | 6 months | Planner weeks per category | Clear dead SKUs, chain-wide |
| Quarterly review | 6 weeks | Planner weeks, four times a year | Dead SKUs and obvious depth errors |
| Ad-hoc, on complaint | Unbounded | Whoever noticed | Whatever a store manager escalated |
| Continuous signal | Days | Read-only data feeds | Decay, drift, and depth, per store |
The delay column is the whole argument. A SKU that stopped earning its facing in February holds it until the August review, and the facing next to it that would have sold never got the space. That loss does not appear as a line item anywhere, which is why the calendar keeps surviving budget review.
How Ward manages a live range
Ward connects read-only to POS, inventory, and your ERP, then scores each store-SKU pair against its cluster benchmark on a rolling window. When a SKU separates from its benchmark, a card goes out naming the store, the SKU, the size of the gap, and the recommended change.
Four decisions come out of it. Drop, when a SKU is below benchmark across every store in its cluster and has been for long enough to rule out a supply gap. Re-depth, when velocity and facings have separated in one direction. Reallocate, when a SKU is dead in one cluster and healthy in another, which is a move rather than a delist. Add, when a store's demand pattern has drifted toward a cluster whose range it does not carry.
Phantom stock and supply gaps get ruled out before a drop is recommended, because a SKU that is not selling due to an empty shelf is a stockout problem, not an assortment one. Delisting a healthy SKU that was simply out of stock is the most expensive mistake in this category, and it is the one a velocity-only report makes constantly.
05
SolutionThe constraint
SKU rationalization without a planning team
Most assortment management tools are modules inside a planning suite, priced and scoped for a retailer with planners to run them. The rationalization work then needs someone to build the analysis, defend the cut list to buyers, and re-run it next cycle. Chains between 40 and 400 stores rarely have that seat, so the tool goes unused and the range decays on schedule.
Ward inverts the order. The analysis arrives already done, as a card with the store, the SKU, the gap, and the recommendation, sent to the category owner in a channel they already read. What stays human is the judgment: vendor terms, category role, whether a SKU is there for traffic rather than margin. Those are decisions, not analysis, and they should not be waiting on an analyst's queue.
The output writes back. When a delist or a re-depth is actioned, Ward measures the affected space against the cluster benchmark afterward, so the next recommendation is scored on what actually happened rather than on the projection. That loop is described on closed-loop intelligence.
06
SolutionWhat it runs on
What you need to connect
POS transaction data, on-hand inventory, and item master. Read-only, no writes to your systems and no new hardware. Ward reads whatever you already run, including Oracle Retail, SAP, NetSuite, Snowflake, and Shopify. Item master gaps do not block the start; cluster scoring runs on transaction behavior, and attribute quality improves the recommendation rather than gating it.
First cards land in 48 hours. Cluster baselines stabilize over about two weeks, which is when the drop list is worth acting on in volume.
Who this lands on
Assortment decay shows up differently depending on which number you own.
Metrics this moves