Assortment planning & store space optimisation

Retailers must decide which few thousand of many possible products each store carries and how the limited shelf is divided. Demand-transfer models estimate what happens to sales when an item is delisted (customers switch to substitutes or leave), space-elasticity models estimate the value of an extra facing, and an optimiser builds range and planograms under constraints. Typical benefit: better sales and margin per metre of shelf, less complexity, and consistent localisation at scale.

Problem & value

• Today: category managers build ranges per store cluster in spreadsheets and planogram tools, often once or twice a year, with "similar stores get the same range" rules and manual rules of thumb. Localising to hundreds of stores is rarely done properly; delist decisions rely on sales rank, ignoring that a "slow" item may be bought by loyal basket-builders or that its demand transfers to a substitute.
• AI value: (1) causal demand-transfer / substitution estimates from basket data, (2) store clustering on local demand, (3) a combinatorial optimiser that respects shelf size, pack sizes, supplier funding, brand-presence and private-label targets, (4) automatic planogram generation, so that a cycle of weeks becomes days.
• Market: an established analyst category (e.g. IDC MarketScape on retail assortment and space planning) with vendors RELEX, Blue Yonder, SymphonyAI and others [1][2]. Vendors report deployments at European grocers and drugstore chains; treat vendor-quoted uplift percentages as marketing claims and verify in your own test-and-control pilot.

Variants

• Grocery / drugstore range & space: thousands of SKUs per store, strong substitution, perishables constrain space; ties into supply (OPT-005, OPT-008).
• Fashion / general merchandise: short life cycles, size-curve and depth planning, open-to-buy linkage; demand data are sparse so attribute-based models dominate.
• Space-only variant: macro-space (category blocks across floor plan) vs. micro-space (facings per SKU on a fixture); many retailers start with one of the two.

How it works

1. POS/basket + loyalty (pseudonymised) + product attributes + store master + shelf data
2. demand model per SKU/store (forecast, price, promo and cannibalisation effects)
3. substitution / demand-transfer model (what is lost when X is delisted?)
4. store clustering (local demand, format, size, demographics)
5. macro-space allocation (category -> metres) using space-elasticity curves
6. range optimisation per cluster (MIP: maximise margin s.t. space, min/max per segment, supplier rules)
7. micro-space / planogram generation (facings, shelf position, merchandising rules)
8. category-manager review, scenario comparison, approval
9. export to planogram/store-execution tools; post-launch test-vs-control measurement

• Demand transfer: choice models (multinomial logit, latent-class) or ML models over product attributes; some vendors use causal methods and "like-for-like" experiments. Pure sales-rank delisting overstates losses or gains.
• Space elasticity: diminishing return of facings per SKU/segment estimated from store variation; confounded by placement, so experiments help.
• Optimiser: mixed-integer programming or constraint programming; heuristics at the scale of hundreds of stores. LLMs are not the optimiser, but are useful as a copilot for rule capture, what-if queries and explanations (see OPT-018).
• Human-in-the-loop: category managers approve ranges, set strategic constraints and handle supplier negotiation; store managers can request local overrides.

Data preparation

Needed are POS/basket transactions, article master data (attributes, hierarchy, pack sizes), store master data (size, format, cluster), planogram or shelf-space data and, optionally, pseudonymised loyalty data. In an SMB these typically live in the ERP or POS back office, merchandise-management exports, Excel sheets of buyers and paper planograms.

Typical gaps: inconsistent or duplicate article numbers, missing attributes (brand, size, colour), changing hierarchies over the years, stock-outs that distort demand (zero sales are not zero demand), promotions that are not flagged, and shelf data that exists only as photos or PDFs. Loyalty data needs a legal-basis check and pseudonymisation.

Preparation steps: (1) export two to three years of sales and map article IDs across systems, (2) clean and deduplicate master data (DATA-003), (3) enrich attributes, partly with an LLM from product texts, (4) flag promotions and out-of-stock periods, (5) convert planogram PDFs to tables (DOC-014), (6) pseudonymise loyalty data (PREP-022) and clarify purpose (PREP-025). Tools: ERP export, Python/pandas, dbt or Power Query. Expect about 50 to 60 percent of the total project effort in data preparation. See PREP-005 and PREP-011.

Implementation paths

Which path for whom

• SMB: Path A. Mature retail planning suites and ERP/merchandising add-ons exist at SMB prices and the process (range review, space planning) is standard.
• Enterprise: Path B. Assortment is a core competitive lever; own POS and loyalty data plus integration with existing planning systems favour a tailored build on cloud APIs and solvers.
• Developer: Path B. Solver, forecasting and LLM APIs can be combined into a product; self-hosting is rarely needed as the data is commercial, not highly sensitive.

Path A — Buy

• Retail planning suites: RELEX Solutions (Finland, EU; space and assortment modules with planogram optimisation [1]), Blue Yonder (Luminate category/space planning), SymphonyAI Retail CPG (assortment and space, formerly Symphony RetailAI), o9 Solutions, Oracle Retail, SAP (Merchandising/Assortment Planning) and NIQ Space Planning. EU-based options: RELEX, SAP.
• Planogram tools: Blue Yonder (formerly JDA Space), NIQ Spaceman, DotActiv (smaller retailers), check import/export formats (PSA, Spaceman, Apollo).
• Choose A when: more than ~50 stores or categories with strong substitution, and a planning team that can adopt the tools; implementations are projects of months.

Path B — Build on cloud APIs

• Data and ML: warehouse (Snowflake, BigQuery EU, Azure Synapse/Fabric) with demand models in LightGBM or cloud AutoML; substitution models in Python (statsmodels, PyTorch).
• Optimisation as a service: Gurobi, FICO Xpress, Hexaly (France) or CPLEX as licensed solvers; cloud solver APIs.
• LLM layer: frontier LLMs with tool calling for what-if queries over results, rule extraction from category-strategy documents and generated rationale texts; keep numeric decisions in the solver.
• Choose B when: a data science team exists and the problem is specific (e.g. just one category or one micro-space step).

Path C — Self-host (open source)

• Solvers: Google OR-Tools (CP-SAT, GLOP; open-source MIP/CP toolkit [4]), HiGHS, SCIP, Pyomo or PuLP modelling layers.
• Modelling: statsmodels / PyTorch for choice models, LightGBM, scikit-learn for clustering, PyMC for hierarchical space-elasticity curves; Nixtla (StatsForecast) for demand baselines.
• Orchestration: Airflow/Dagster, dbt; planograms generated as CSV/JSON/image and loaded into the planogram tool.
• Hardware: HW1 (CPU servers suffice; the problem is combinatorial, not GPU-bound).

Path D — Custom training

Custom substitution or learned space-response models are worth it for large chains with long data histories; reinforcement learning or learned heuristics for large placement problems remain research-leaning. Requires several years of store-SKU-week data, shelf images or planogram history, and experiments (test-and-control) to ground causal estimates.

State of the art (2026)

• Integrated range-space-supply optimisation is now a product feature of planning vendors, and GenAI front ends (copilots, natural-language what-if) are being added to the main suites.
• Causal demand transfer is the differentiator: transaction-based substitution (e.g. share of customers who switch vs. leave), plus attribute-based estimation for new items.
• Computer vision closes the loop: shelf images give actual facings for compliance (VIS-009) and space data; generative approaches for planogram drafts exist but remain experimental.
• Limits: poor-quality product dimensions and fixture data; sparse data for new and slow items; space-elasticity confounding by location on the shelf; the optimum is only as good as the constraints that capture brand strategy; store-execution discipline limits realised uplift; optimisation can reduce choice and local relevance if loyalty effects are ignored.

Shared resources & combinations

• Same stack: tabular-ml, time-series and optimization-solver shared with OPT-005 (replenishment), OPT-016 (promotion optimisation), OPT-004 (pricing), PRED-001 (demand forecasting).
• Upstream/downstream: PRED-001 supplies baselines; OPT-005 and OPT-008 turn the range into stock and flows; VIS-009 checks execution; REC-001 handles individual personalisation.

Effort, cost & KPIs

• Path A: 3-9 months for a first category wave including data cleansing; licence per store/module plus integration.
• Path B: 4-9 months for a team of data scientists/engineers; solver licences and cloud data costs.
• Path C: similar effort, lower licence cost, higher in-house maintenance.
• KPIs: sales, margin and gross profit per linear metre, availability/out-of-stocks, SKU count and complexity, customer retention in delisted categories, planogram compliance, cycle time for range reviews, test-vs-control uplift per category.

People & change

Involve management and the category/department leads from day one: they own the assortment decisions and must accept that the model proposes, buyers decide. End-users (buyers, space planners, store managers) join the pilot early, because their domain knowledge is the best test of recommendations. IT and data owners clarify ERP/POS exports; suppliers are affected when range changes alter listings and should be informed by the buyers, not by the tool. The DPO is needed if loyalty data is used (pseudonymisation, purpose, possibly a DPIA).

Works council: depends. If the tool only works on article and sales data, there is little employee monitoring. Once buyer overrides or planner activity are logged per person, §87(1) no. 6 BetrVG applies. In any case inform the works council in good time under §90(1) no. 3 and consider an expert under §80(3).

AI literacy: support staff with short trainings on forecast uncertainty and model limits (Art. 4 AI Act, supporting measures). Start with one category and a few stores as a pilot, compare model proposals with buyer decisions, and document overrides. Typical concern: "the model replaces the buyer". Address it by keeping the final listing decision with humans. See GUIDE-009, GUIDE-008 and GUIDE-004.

Risks, regulation & compliance

• EU AI Act: minimal risk; no Annex III category. AI literacy (Art. 4) applies to planners.
• GDPR: basket analysis is largely aggregate; if loyalty-card data are used, pseudonymise, keep a legal basis and avoid individual profiling in range decisions; DPAs with vendors, EU hosting.
• Competition law: supplier-category-captaincy and exchange of competitively sensitive data (EU Art. 101 TFEU, Vertical Block Exemption Regulation) need guardrails; the same applies to pooled data among competing retailers.
• Supplier relations / UTP Directive: listing fees, delisting terms and payment terms for agricultural and food products fall under EU Directive 2019/633 (unfair trading practices).
• Operational risks: delisting that harms loyal customers; local diversity lost; data errors causing impossible planograms. Mitigate with pilots in test stores, guardrail constraints and review by category managers.

Getting started

1. Pick one category (e.g. 200-500 SKUs) and 20-50 stores; assemble 2+ years of POS, product dimensions and current planograms.
2. Quantify baseline: sales/margin per metre, SKU count, review cycle time.
3. Check shelf and product master data quality; many projects stall here.
4. Run a vendor proof of value or a Path B/C prototype on historical data (backtest of delist decisions) and then a store test with control stores.
5. Define constraint library (brand presence, private label, supplier funding) and a governance for category-manager overrides; scale category by category.

Sources

1. RELEX Solutions — assortment and space planning — https://www.relexsolutions.com/products/assortment-planning/
2. IDC MarketScape (retail merchandising/assortment & space planning) — https://www.idc.com/
3. Blue Yonder — category and space planning — https://blueyonder.com/
4. Google OR-Tools — https://developers.google.com/optimization
5. HiGHS solver — https://github.com/ERGO-Code/HiGHS
6. Directive (EU) 2019/633 on unfair trading practices — https://eur-lex.europa.eu/eli/dir/2019/633/oj
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Commission Vertical Block Exemption Regulation (EU) 2022/720 — https://eur-lex.europa.eu/eli/reg/2022/720/oj