AI Assortment Management: Where Manual Logic Breaks
The product matrix is revised once a quarter — in a spreadsheet, based on the closed period.
While items are coordinated between procurement, commercial, and warehouse teams, demand has time to move: what was top moves to the tail, and newly introduced items arrive for a season that is already over.
Manual assortment management relies on the category average. Five to ten thousand SKUs, each with its own demand profile and its own response to promotions and discounts, but the decision is made from a general report for last month.
This creates two distortions at once: introducing an item without checking whether there is sustained demand for it, and discontinuing based on warehouse stock rather than sales dynamics.
The cost of such a failure accumulates slowly. Dead stock takes up space and working capital, while stockouts grow for items that are actually selling.
The mismatch between supply and demand shows up after two or three procurement cycles — and it is convenient to attribute it to seasonality or to the supplier.
Classic ABC/XYZ analysis based on monthly results does not remove the problem: it also looks backward and averages out spikes. Local growth by channel, region, and size is not visible in it, so the decision is still made by a human — based on experience and the latest export.
AI assortment management changes the point of inquiry: the model calculates demand for each item separately and by channel, and the decision to introduce or discontinue is based on a forecast rather than the past period. Let's break down what such a system consists of and what it delivers in numbers.
What Changes After Implementation: Measurable Effects
We do not evaluate the effect of recommendations by eye: the system records four values — demand forecast accuracy, inventory turnover, share of dead stock, and speed of assortment matrix reassembly.
The first two show how accurately the model describes future demand; the latter two show how much capital is sitting idle in the warehouse and how quickly the category manager can respond to a market shift.
We calculate demand forecast accuracy separately — by SKU, warehouse, and week, not averaged by category: within a group, errors cancel each other out, and the metric starts to lie.
We build the baseline seasonal profile on the open-source Prophet model, and on top of it the model is further trained on promotions and local spikes. Forecast error over a comparable horizon drops by 20–35% versus planning by the average for the previous period.
Turnover grows not by cutting the matrix, but by redistribution: recommendations suggest what to move between warehouses, what to reorder, and what to drop.
The share of dead stock decreases first through early detection of items with falling demand, then through managed markdowns and replacements.
The fastest change is in the speed of assortment reassembly: instead of a quarterly spreadsheet cycle, the matrix is recalculated by event — a demand spike, a supplier change, a new product launch.
A run takes minutes, so the manager checks several scenarios and immediately sees their impact on turnover and dead stock.
Model Operating Modes: Batch, Streaming, Hybrid
The recalculation mode determines how quickly a demand change reaches the matrix and what the delay costs.
Batch, streaming, and hybrid options solve the same problem in different ways: the first calculates on a schedule across the full volume, the second reacts to events, and the third separates hot and cold loops.
The choice is determined by two things — the required frequency of recommendation recalculation and the demand variance within the matrix.
If most items behave stably, and only a few dozen SKUs need a reaction, event-driven processing of the entire catalog provides nothing but load on the data source.
| Mode | When it fits | Limitations |
|---|---|---|
| Batch recalculation | Stable demand, a matrix of thousands of SKUs, decisions made once a day | The recommendation goes stale between runs; a demand spike is reflected with a delay until the next cycle |
| Streaming | Promotions, seasonal peaks, a rapidly changing assortment top | Sensitive to noise: with weak signals the matrix "trembles"; calculation is harder to reproduce and analyze after the fact |
| Hybrid | Heterogeneous catalog: the core is stable, some items live in constant fluctuation mode | Requires explicit prioritization and protection from version conflicts between loops |
In practice, hybrid is more often chosen: top items and promotional groups are recalculated by events, while the rest of the matrix is handled by a scheduled batch.
Both loops write to a single recommendation mart with versioning, so matrix updates remain reproducible, and discrepancies between calculations are resolved by priority, not by database write time.
How We Implement the System: Stages of Engineering Work
Implementation proceeds in iterations: each stage ends with an artifact that is validated on historical data, not with a status in a report.
The model is not launched across the entire matrix at once — first a narrow loop where recommendations are comparable to the current procurement policy, and only then expansion. Below is the sequence of work.
- Data audit. We collect sales, inventory, supply, discount, and promotion history for the available period; we check the completeness of the "product — day" matrix, duplicates, gaps, and breaks in reference data. We record which data categories are sufficient for forecasting and which will have to be managed by manual rules.
- Model design. We define the forecast horizon and decision level — an individual SKU or a cluster of interchangeable items. Features include seasonality, promotions, demand elasticity, shelf life, and cannibalization; the design is validated on a holdout period that the model has not seen.
- Setting selection rules. Business constraints are layered on top of the forecast: minimum display, pack multiplicity, shelf space, supplier limits. The rules sit separately from the model, so they can be changed without retraining and are coordinated with category managers.
- Checking recommendation quality. We compare the proposed procurement policy with the actual one over the same periods: we calculate accuracy, stockout share, excess volume, and the number of manual edits. If the recommendations do not outperform the current process, we return to the model design rather than expanding the pilot.
- Pilot on a limited loop. We launch on several categories in parallel with the previous process, compare plan and actual weekly, and tune trigger thresholds.
- Handover to operation. We provide the retraining schedule, a dashboard for monitoring forecast degradation, instructions for managers, and the procedure for rolling back to previous rules if quality falls below the agreed threshold.
What We Hand Over: Configurations and Regulations
We hand over not a "working system," but a set of artifacts your team can use to change the rules itself — without contacting us for every adjustment. We check each item at acceptance: if a step cannot be reproduced from the document, it is not considered delivered.
- Model configuration: features, trigger thresholds, rule weights, and boundaries beyond which a decision goes to manual review — with an explanation of how the setting affects the output.
- Assortment reassembly regulation: frequency, data sources, launch procedure, checkpoints, and conditions under which reassembly is stopped and the previous version is restored.
- Access policies and roles: who changes the rules, who can only view, who approves category discontinuation — with level separation and an action log.
- Integration scheme with the accounting system: where reference data and inventory come from, how often synchronization runs, what to do in case of discrepancy, and how to read the exchange log.
- System documentation: decision logic, data dictionary, instructions for the analyst and operator, and the incident escalation procedure.
- Set of checks: scenarios for typical and edge cases — a new category, zero stock, a seasonal spike — so that edits do not break the output.
- Handover plan: a joint review with your team, a reassembly run on your side, and a period of change support.
After acceptance, your team closes rule edits, reassembly launches, and incident analysis according to the regulation — we stay in touch when the logic itself changes.
Case Study: Assortment Reassembly and Moving Away from Dead Stock
A distributor with a matrix of about 9,000 SKUs reassembled its assortment once a season. Category managers consolidated sales, inventory, and supply terms in spreadsheets — one reassembly took three weeks, and by the end some of the calculations were already outdated.
The cost of such a mode is visible in the numbers for that period: the share of dead stock remained at 34%, demand-hit accuracy did not exceed 58%, and previously discontinued items returned to the matrix by inertia — there was not enough data for a confident decision.
What Was Changed
The model calculates demand for each SKU daily: seasonality, turnover, the influence of neighboring items, and promotions. The output is four classes of recommendations: keep, reduce share, discontinue, introduce a replacement.
Data is pulled from 1C without manual exports, so reassembling the matrix takes two business days instead of three weeks.
Metrics Before and After
- Share of dead stock: 34% → 11% over two quarters.
- Demand-hit accuracy: 58% → 84%.
- Matrix reassembly: three weeks → two days.
- Revenue per SKU: +19% with the same shelf volume.
- Time to effect: first discontinuation decisions in the third week, sustained shift by the end of the second quarter.
The decision remains with the category manager: the system shows the calculation and the reason, disputed items go into a limited test rather than manual rotation.
That is where the result comes from — we reduced not the assortment, but the time spent on decisions that used to be postponed.
How a Ranking Model Differs from Threshold Rules
Threshold rules are a deterministic layer: a product enters the output only if conditions on stock, delivery time, and marketplace constraints are met. Such a layer is explainable and reproducible — any impression can be broken down step by step.
Where an error is costly (prohibited category, zero stock, expired shelf life), rules are more reliable than any model.
The ranking model works not instead of them, but within the allowed set: it orders what has passed the threshold and decides what to show first when there is a limited number of slots. Training uses feedback from shoppers — views, add-to-cart events, returns. The quality metric here is revenue lift on occupied positions, not hit accuracy.
A separate problem is item cold start: a new product has no history, and the model underestimates it because it has not seen interactions.
Features from attributes and proximity to working products help, plus a reserved share of impressions for exploration — otherwise new items get no chance, and the system learns only on the old assortment.
We keep recommendation constraints in the rules: a closed feedback loop amplifies the popular, the popular gets more impressions, and the assortment compresses toward a dozen hits.
Therefore we set a cap on the share of one product in the output, a limit on repetitions, and re-evaluate weights on a holdout period.
In practice, this is one loop: rules define what is permissible to show, ranking defines in what order. The first provides predictability and incident analysis, the second provides flexibility for demand.
Technical Doubts Before Starting a Project
Doubts before starting concern not algorithms, but data and processes. Below are five questions we close before launch so that the result does not depend on the quality of the initial exports.
The data is dirty — will the system even work?
We profile transaction history: duplicate items, gaps in prices, incorrect returns. We build normalization and category reference data before training — otherwise the model learns accounting errors as a pattern.
Is there enough sales history volume?
For a weekly forecast, one and a half to two full sales cycles are needed — otherwise declines are not visible. We aggregate short history to categories: accuracy for individual SKUs is lower, and we state this in advance.
Why does the system recommend this?
The recommendation is broken down into factors: elasticity, promotion contribution, cannibalization of neighboring items, stock, and delivery time. The buyer sees what they are disputing and rejects the advice with justification.
Will you account for our seasonality?
We build seasonal profiles for each category separately, adjusted for holidays, promotions, and local events. The chain calendar is set explicitly — past peaks are not mechanically transferred to a new period.
Who supports the model after launch?
The model drifts along with the assortment and demand. The regulation: accuracy monitoring, alerts on deviations, scheduled retraining, and review of disputed recommendations together with your category team.
Let's Discuss the Task and Come Back with a Work Plan
To come back with a timeline estimate and work plan, we need a description of the current process: where sales, inventory, and supply data come from, who makes decisions on introducing and discontinuing items and how often.
It is useful to know exactly where time is lost — manual reconciliation of reports, scattered spreadsheets, delay between signal and decision.
From such a description, we build the full picture and come back with specifics:
- Process breakdown — we will break assortment management into steps and find which ones can be automated and which remain with humans.
- Data and integration scheme — we will show where the system gets sales history, inventory, and external factors, and what is needed from the accounting systems.
- Timeline estimate — we will state the duration of the stages and the point when the first management decisions based on data will appear.
- Team composition — we will define who leads analytics, who is responsible for the model, who is responsible for implementation and support.
- Work plan — stages with a verifiable result at each, without a long "blind" period at the beginning.
- Acceptance criteria — we will agree in advance on which metrics we consider the solution working: forecast accuracy, share of items with auto-suggestions, speed of reaction to demand change.
- Project start — we will determine the first assortment segment for launch so that the effect is visible before full deployment.
Describe the task in free form — the current process, bottlenecks, what you want to achieve. We will come back with an estimate, solution design, and implementation plan, and then you can decide whether the team composition and timeline fit.
