Retail Manager to AI Demand Planner: Store Forecasts & Reorder

Demand planning is not a single forecast number; it’s a set of decisions made on a schedule. In-store you may think in terms of KPIs like on-shelf availability, shrink, waste, and labor. Demand planning translates those into outcomes like service level (probability of not stocking out), inventory turns (how fast inventory converts to sales), and waste/markdown risk (especially for perishables).

At the store-SKU level, the core decisions are usually: (1) what baseline demand to expect next week (or next few weeks), (2) what inventory position is acceptable given lead time and variability, and (3) what order quantity to place under constraints (case pack, shelf capacity, minimum order quantity). Your “forecast” is only useful if it connects directly to the reorder decision.

Practically, a demand planner works backwards from the business: if the store misses sales due to stockouts, the cost is lost gross margin and possibly customer churn; if the store overbuys, the cost is carrying cost, waste, and forced markdowns. This is why success criteria are not purely statistical. You will measure accuracy (e.g., WAPE), bias (systematic over/under-forecast), and then connect those to service level and inventory outcomes through simulation or simple calculations.

• Service maps to on-shelf availability and “did we lose the sale?”
• Waste maps to over-forecast, over-order, and expiration/markdowns.
• Turns map to how well orders match true demand over time.

Engineering judgment shows up in deciding which decisions are truly controllable (orders) versus observed outcomes (sales can be censored by stockouts). The forecast should target true demand, not just observed sales, otherwise you will systematically under-order the very items that stock out.

Retail managers often use heuristics like “we sell about 12 a week” or “add a little extra for the weekend.” Those averages fail because store demand is lumpy, affected by local patterns, and constrained by inventory. Averages also hide two different sources of variation: demand variation (customers) and supply variation (deliveries, substitutions, stockouts).

At store-SKU granularity, you will see intermittent demand (many zeros), promotion spikes, and weather/local-event sensitivity. Two stores with the same weekly average can behave very differently: one has stable weekday sales; another has weekend spikes; a third sells only when promoted. This matters because safety stock depends on variability during lead time, not on the average alone.

A practical way to reason about this is to separate your baseline forecast into components: trend (longer-term growth/decline), seasonality (weekly/annual patterns), and event effects (promos, holidays). Even before advanced ML, a baseline model that explicitly represents trend and seasonality will outperform naive averages and will be easier to explain.

Common mistakes when moving from store operations to forecasting include: treating stockouts as “low demand” instead of censored demand; averaging across stores and losing local signals; and optimizing for overall accuracy while ignoring bias. A forecast with small WAPE but consistent under-forecast can still cause chronic stockouts and poor service. Your goal is a forecast that is accurate and operationally safe.

Practical outcome: start thinking in distributions, not points. Instead of “we’ll sell 12,” think “we’ll sell around 12, but could be 8–16 depending on normal variation, and higher if promoted.” That mindset is what enables service-level-based replenishment.

Most store decisions run on a weekly cadence: promotions change weekly, orders are placed on certain days, and reporting is weekly/fiscal. Demand planning must respect the retail calendar, because features and targets depend on how time is defined. “Week” is not always Monday–Sunday; it may be a fiscal week, a 4-5-4 calendar, or a retailer-specific week ending on Saturday.

Define your decision week first: when do you place orders, and which sales days are included in the forecast target? If orders are placed every Tuesday for delivery Thursday, your model should forecast demand over the coverage period that inventory must support (often lead time plus review period). Misaligning weeks leads to forecasts that look accurate on paper but fail in execution.

Holidays and events are not just “special days”; they create shifted shopping patterns (pre-holiday stock-up, post-holiday lull). Many SKUs show lead/lag effects: turkey spikes before Thanksgiving; charcoal spikes before summer holidays; certain snacks lift during major sports events. Practical feature thinking: encode holiday windows (e.g., -2 to +1 weeks) rather than only the holiday date.

Another operational reality: promotions are scheduled in “ad weeks,” not calendar weeks. Your minimum viable feature set should include promo flags and price/discount depth aligned to the retail week. Common mistake: using daily promo start/end dates without aggregating correctly to the planning bucket, creating leakage or incorrect alignment.

Practical outcome: build a simple retail calendar table early (week_id, fiscal_period, start_date, end_date, holiday_flags). This becomes the spine that joins POS, inventory, and promo data without ambiguity.

In store operations you already know that “order what you need” is not literal. Replenishment is constrained by how products ship and fit. Case packs force discrete quantities (you can’t order 3 units if the case pack is 12). Minimum order quantities (MOQs) may apply by SKU, vendor, or category. Shelf capacity and backroom limits cap how much you can hold without creating labor and shrink problems.

These constraints are why demand planning connects forecasting to inventory policy. A forecast might suggest ordering 7 units, but the feasible decision could be 0 or 12. If you ignore pack sizes, you’ll “optimize” to impossible quantities, and the execution team will override the system—destroying trust in the model.

Translate constraints into model inputs and business rules: case_pack_qty, min_order_qty, max_shelf_qty, presentation_min (facings), and delivery frequency. Then choose a reorder policy that respects them. For example, a min-max policy sets a floor and ceiling inventory position; an (s, S) policy orders up to S when inventory position drops below s; a reorder point policy triggers orders when projected inventory during lead time hits a threshold.

Common mistake: using the same service target for every SKU. High-margin, high-velocity SKUs may deserve higher service; slow movers may be better with lower service to protect turns and reduce obsolescence. Practical outcome: your first portfolio-quality work sample can show how constraints change order quantities even when the forecast is identical.

A minimum viable dataset for store-SKU forecasting is smaller than people think, but it must be correctly joined and cleaned. At minimum you need: POS sales (units sold by store-SKU-day or store-SKU-week), inventory snapshots (on hand, on order, receipts), product master data (hierarchy, pack size, status), and promo/price data (promo flag, discount depth, display/feature where available). If you can add deliveries/receipts, that helps separate supply issues from true demand shifts.

Data issues are not edge cases; they are the main work early on. Stockouts censor demand: POS sales drop to zero not because customers stopped buying, but because the shelf was empty. You need to detect stockouts using on-hand near zero combined with lost sales indicators (high historical velocity, frequent replenishment). Outliers can come from data entry errors, one-time bulk purchases, or mis-scans. Returns and negative sales require clear handling rules.

To connect store KPIs to forecasting features, treat operational signals as explanatory variables: promo intensity (discount), display presence, price changes, delivery timing, and stockout indicators. Your baseline forecast (trend + seasonality) is the “expected” demand without special events; promo features then explain deviations.

Common mistakes: building models on observed sales without adjusting for stockouts (leading to chronic under-forecast), mixing units (each vs case), and using product hierarchies that change over time without versioning. Practical outcome: create a clean, documented “store_week_sku” table that includes sales_units, on_hand_end, receipts_units, price, promo_flag, and pack_size. This table is the foundation for forecasting and reorder simulation.

A strong demand planning use case is defined by decision points, not by algorithms. Start with the weekly cycle: when is the forecast generated, when is the order cut-off, what is the lead time, and how long must inventory last (review period + lead time)? Write this as an operational story: “Every Tuesday by 2pm, place orders for Thursday delivery; coverage must last through next Tuesday.” That story becomes your model’s target horizon.

Next, set success criteria in a way that balances accuracy, bias, and business costs. WAPE (Weighted Absolute Percentage Error) is a good retail metric because it weights high-volume items appropriately. Bias tells you whether you consistently over- or under-forecast. But you also need a service-level view: what stockout rate does this forecast and policy imply, and what is the expected inventory? This is where simple simulation becomes practical: use forecast distributions (or error history) plus lead time to estimate safety stock and compare service targets.

Then pick a replenishment policy to implement and evaluate: min-max for simplicity, (s, S) for control of order frequency, or reorder point for continuous review approximations. Incorporate constraints (case packs, MOQs, shelf capacity) as hard rules. Evaluate outcomes: service level, average inventory, number of orders, and waste/markdown risk if applicable.

Finally, create your personal transition plan and portfolio goal. Choose one category and 10–50 SKUs across 3–10 stores. Build: (1) a clean dataset with stockout flags, (2) a baseline seasonal+trend forecast, (3) WAPE and bias reporting, and (4) a reorder simulation that outputs service and inventory. This demonstrates the exact mindset employers want: translating store operations signals into a forecasting-and-replenishment system that can be measured and improved.

The most important design decision is the grain: what one row represents. For store forecasting and reorder, a common grain is store–SKU–week. That grain supports weekly ordering cycles, reduces transaction noise, and aligns with most retail promo calendars. Write the grain down in a sentence: “One row equals one SKU in one store in one ISO/fiscal week.” If you can’t state it, your dataset will drift.

Next define the keys that uniquely identify each row. At minimum: store_id, sku_id, week_id. Many failures come from “almost keys” (store numbers that change, SKU re-codes, UPC vs internal item IDs). Create a product-store master early: a crosswalk that resolves duplicate identifiers, effective dates, and pack changes. Without it, you will silently split one item into multiple time series and blame the model.

Watch for data leakage—features that accidentally include future information. Common retail leakage patterns include: using end-of-week inventory when predicting the same week’s sales; joining promo “post analysis” flags that are only known after the event; or using replenishment orders that were created because the week sold well. A practical rule: any feature used to predict week W must be known by the start (or at least not after the end) of week W.

• Checklist: verify uniqueness of (store_id, sku_id, week_id), enforce a calendar table, and log join rates (what % of POS rows found a matching SKU and store).
• Common mistake: building a beautiful model on a dataset where 5–10% of weeks are missing due to join failures; the model “learns” gaps as seasonality.

Engineering judgment here is conservative: prioritize correct keys and a stable grain over adding more columns. A smaller, trustworthy table beats a wide table with ambiguous meaning.

Raw POS is typically transaction-line level: timestamp, store, SKU, quantity, extended amount, and sometimes reason codes. Your task is to turn it into a weekly demand signal without smearing operational quirks into “demand.” Start by filtering to “saleable” activity. If you have both sales and returns as negative quantities, keep them—but treat them intentionally.

A robust aggregation approach is to compute weekly totals for: units_sold_gross (positive quantities), units_returned (absolute value of negative quantities), and units_sold_net = gross − returned. Net units often best reflects what left customers’ homes, but gross units can better reflect register throughput and shelf depletion. Choose one as your forecast target and document why. Many demand planners forecast net units but use gross to flag unusual operational periods (e.g., mass returns after holidays).

Voids and cancellations are different from returns. A void is frequently a cashier correction; it should not be interpreted as negative demand. If your POS includes a “void” flag or transaction type, exclude voided lines from both sales and returns. If you cannot identify voids cleanly, look for patterns like a sale and exact opposite quantity within minutes on the same register—then treat as operational noise, not customer behavior.

• Aggregate with a calendar join (fiscal week start/end), not by naïve date_trunc alone; retail weeks often start on Sunday and align to merchandising cycles.
• Compute price metrics carefully: a weighted average price per week (revenue / units) is more stable than averaging ticket prices across transactions.

A practical outcome of this section is a clean store–SKU–week table with defensible sales units and revenue, plus the metadata you’ll need later for promo and price features. You should be able to answer: “If I sum my weekly table, do I reconcile to POS totals within a small tolerance?”

Sales alone do not tell the full story because sales are constrained by availability. To interpret demand, you need inventory positions. Retail systems often provide multiple views: on-hand (physical units in store), on-order (expected inbound), in-transit, allocated, and sometimes available-to-promise (ATP). For store replenishment, ATP is usually closer to what the shelf can actually sell because it accounts for reservations and holds. However, many stores only reliably track on-hand, and even that can be noisy due to shrink and late receiving.

When you build the store–SKU–week table, decide what inventory snapshot timing means. A common pattern is:

• BOH_start: beginning-of-week on-hand (snapshot before selling starts)
• receipts: units received during the week (from delivery/receiving logs)
• sales: units sold during the week (from POS)
• BOH_end: end-of-week on-hand (snapshot after selling ends)

These four numbers should approximately satisfy an inventory balance equation: BOH_start + receipts − sales ≈ BOH_end. It will not be exact because of shrink, adjustments, and timing differences—but large, frequent gaps are a red flag. Use the gap as a data quality metric and as a signal for store process issues (late receiving, mis-scans, inventory corrections).

Engineering judgment: if ATP exists and is trustworthy, use it for stockout detection because a store can have on-hand in the backroom but zero available to sell due to holds or misplacement. If only on-hand exists, treat it as “best available,” but be cautious: a zero on-hand does not always mean a true stockout; it can mean inventory record inaccuracy.

The practical outcome is that your forecasting dataset becomes “operations-aware.” Later, when your forecast misses, you’ll be able to distinguish: was demand wrong, or was supply unavailable?

Stockouts create censored demand: you observe sales limited by inventory, not true customer desire. If you train a model on censored weeks as if they were normal demand, you teach it that “low sales” is expected—exactly the opposite of what you want for reorder decisions.

In practice, stockout detection is heuristic because perfect shelf-availability data is rare. Start with simple, explainable rules and refine. Common heuristics at store–SKU–week level include:

• Zero sales + low inventory: units_sold = 0 and BOH_end = 0 (or ATP_end = 0) suggests a stockout week.
• Sales collapse with inventory near zero: sales are far below recent average and end-of-week inventory is zero; this flags partial-week stockouts.
• Phantom inventory: on-hand shows positive but sales are zero for multiple weeks; could be record error, misplaced stock, or discontinued item incorrectly left active.

Once flagged, decide how to treat censored demand. Options include: setting the target to missing for those weeks (so the model does not learn the low value), imputing demand using a baseline estimate (e.g., median of last 8 in-stock weeks), or adding an explicit is_stockout feature and training a model that can handle it. The most conservative approach for baseline forecasting is to exclude heavily censored weeks from fitting and keep them for evaluation as “constrained periods.” Document your choice because it affects reorder parameters and service targets.

Also distinguish lost sales versus substitution. If a customer buys a similar SKU when one is out, total category demand may be less censored than item-level demand. If you have basket or category-level signals, you can later model substitution; for now, avoid treating stockout weeks as true low demand.

Practical checks: count stockout-flagged weeks per store–SKU; extreme rates (e.g., 40% of weeks) may indicate data issues or chronic availability problems that require a different replenishment strategy.

Retail time series are full of “events” that are not demand patterns: inventory corrections, one-time bulk purchases, POS glitches, and assortment changes. Treating these as normal demand can inflate forecasts and safety stock. Start by defining outliers in a way that respects seasonality: compare a week to a rolling window of recent in-stock weeks (e.g., last 8–12) rather than to the global average.

Practical outlier rules include: units greater than (median + 5×IQR) in the rolling window, or week-over-week changes above a threshold when price and promo did not change. Always check whether the “outlier” aligns with a known promo, holiday, or store event before removing it. The point is not to erase real spikes—it’s to remove non-repeatable noise.

Discontinuations and assortment resets look like demand decaying to zero. The mistake is to treat these as a forecasting problem. Add status fields in your master data: active dates, end-of-life flags, and replacement SKU links. When an item is discontinued, your forecast should stop, not drift downward slowly. Similarly, store openings, remodels, and closures should be explicit events in the store master.

Cold starts (new items or new stores) require different handling because lags and moving averages are empty. A practical approach is to borrow strength from: category averages in the same store, the same SKU’s performance in similar stores (cluster by region/size), or chain-level seasonal profiles scaled by early sales. The key is to label these periods with is_new_item / is_new_store so evaluation doesn’t penalize the model unfairly and reorder settings can start conservative.

The outcome is a dataset that separates operational lifecycle events from demand signals, which will improve both baseline forecasts and the credibility of your recommendations.

With a clean store–SKU–week table, you can engineer features that translate store operations into model-ready signals. Start with patterns that are robust, interpretable, and hard to leak.

Lags and moving averages: create lag_1, lag_2, lag_4, and lag_52 for weekly seasonality. Add rolling means/medians over 4, 8, and 13 weeks using only prior weeks. Rolling medians often outperform means when outliers exist. Pair these with rolling_std to represent variability—useful later for safety stock and reorder point calculations.

Price and promo: include a weekly effective price (weighted average), percent discount vs regular price, and promo flags (ad feature, endcap, coupon). If you have overlapping promo types, encode them explicitly rather than one generic “promo.” Ensure promo features are based on the plan known before the week starts to avoid leakage.

Events and calendar: join a retail calendar with holiday flags, pay-week indicators, and fiscal periods. Create store-region event flags (local festivals, weather disruptions if available). Calendar joins are where master data discipline pays off: one authoritative calendar_week table prevents mismatched weeks across systems.

Availability features: keep is_stockout, in_stock_rate (fraction of days with positive ATP/on-hand, if daily is available), and inventory balance gaps. Even if you exclude censored weeks from training targets, these features help explain performance and support exception reporting.

• Common mistake: creating features from the same-week sales target (e.g., “weekly share” computed using current week totals). Build features from prior weeks or exogenous plans.
• Documentation habit: for each feature, write: definition, timing (when known), and intended effect (e.g., “discount increases units, especially in category X”).

The practical outcome is a feature set that supports baseline forecasts with trend/seasonality components and sets you up to measure quality later with retail metrics like WAPE and bias—confident that the inputs reflect reality, not artifacts.

Retail forecasting is inseparable from replenishment constraints. Before choosing a model, specify the decision it supports and the horizon it must cover. A daily horizon is usually about shelf execution: labor planning, intraday stock risk, fresh categories, and short lead times. A weekly horizon aligns better with ordering cycles, vendor pack sizes, and weekly promotions. Your “best” forecast is the one that reduces costly decisions at the cadence you actually act on.

Start by mapping horizons to operational questions. For example: “Will I stock out before the next delivery?” is a daily risk problem tied to lead time in days. “How much should I order for next week’s promo window?” is weekly and often requires separate treatment of baseline vs event uplift. Many organizations run both: a weekly ordering forecast (primary) plus a daily monitoring forecast (exception management).

Engineering judgment: choose a horizon that matches your lead time and review period. If you place orders every Monday with a 3–5 day lead time, then a 1–2 week forecast is operationally meaningful. A 12-week forecast might look impressive but can be irrelevant if assortment resets every 8 weeks or promotions dominate the signal. Conversely, too short a horizon can hide trend and seasonality and create “nervousness” (overreacting to noise), leading to unstable orders.

Finally, decide refresh cadence. A daily refresh can improve responsiveness but may amplify noise unless you smooth it. A weekly refresh is calmer and aligns to business routines but can lag sudden demand shifts. A practical compromise is: compute forecasts daily, but only “commit” reorder decisions on the ordering schedule, using daily updates to flag exceptions (unexpected spikes, weather events, inventory errors).

Baselines are not “toy models.” They are the yardstick that protects you from building complexity that adds no value. In retail, three baselines cover most reality checks: last period, seasonal naive, and moving average. You should implement all three and keep them in your backtesting dashboard.

Last week (or last day) baseline: forecast equals the most recent observation. This is surprisingly hard to beat for stable, high-frequency series, and it reveals whether your data pipeline is aligned. If your model cannot beat “yesterday equals today” on daily items with steady sales, investigate data latency, missing days, and stockout censoring.

Seasonal naive: forecast equals the value from the same season in the prior cycle (e.g., same day-of-week last week for daily; same week last year for weekly). For store-SKU, weekly seasonality (day-of-week) is often the strongest predictable component; for some categories, annual seasonality (holiday period) matters more. Seasonal naive sets a high bar because it captures repeatable retail rhythms without any parameters.

Moving average: forecast equals the average of the last N periods (simple) or a weighted average (more weight on recent observations). This stabilizes noisy items and reduces overreaction. Choose N based on cadence: for daily forecasts, a 7-day moving average respects day-of-week patterns only if you compute separate averages per weekday, or if you first remove weekday seasonality. Common mistake: applying a single moving average across all days and then being surprised when weekends are consistently under-forecast.

Practical workflow: build the baselines first, then annotate where each wins. High-volume staples may be best with last-week; intermittent items may need moving average or even a separate intermittent-demand method later; strongly seasonal categories will reward seasonal naive. Your baseline should be strong enough that any advanced model must justify itself via forecast value-add (covered in Section 3.5).

Once baselines are in place, the next step is a “business-as-usual” model that explicitly represents level (typical demand), trend (direction over time), and seasonality (repeating cycles). Decomposition is useful even if you later use machine learning because it provides interpretable components and helps you engineer features cleanly.

Level is the anchor: the average demand after removing seasonal effects. For store-SKU, level shifts can happen when distribution changes, planograms update, or a competitor opens nearby. If your model assumes a fixed level, it will lag after real structural changes. Practical tip: use rolling estimation windows (e.g., last 26 weeks) so the level can adapt, but not so short that noise dominates.

Trend captures gradual growth or decline. Many SKUs have weak trend at store level, but categories or regions often show clearer trend. A common engineering mistake is forcing trend on every series; this can create drift and degrade short-horizon accuracy. Instead, add trend only when it is stable and supported by enough history (e.g., a year of weekly data) or borrow strength from higher-level aggregates (see Section 3.4).

Seasonality comes in multiple layers: day-of-week, week-of-year, payday effects, and holiday adjacency. In baseline forecasting, treat promotions and stockouts as exceptions—they should not “teach” your seasonal pattern. If you let promo spikes enter the seasonal component, you will permanently inflate future baselines. Practical approach: flag promo weeks and exclude them from estimating the seasonal profile, or down-weight them. Similarly, stockouts censor demand; if you estimate seasonality from observed sales during stockouts, you’ll learn an artificially low pattern.

• Additive vs multiplicative seasonality: additive assumes constant seasonal lift (e.g., +3 units on weekends), multiplicative assumes proportional lift (e.g., +20% on weekends). Multiplicative often fits better when volume varies widely by store or over time.
• Outcome: a baseline forecast that is stable, interpretable, and ready to accept event overlays later (promotions, price changes, weather).

Store-SKU forecasts rarely live alone. Leaders want to know category totals by region, finance wants chain-level demand, and supply chain needs DC-level volume. These are hierarchical views of the same reality: item-store rolls up to item-region, category-store, category-region, and total company. If each level is forecast independently, the numbers often disagree—your store forecasts may sum to 10,000 units while the category-region forecast says 9,200. That inconsistency creates planning conflict and erodes trust.

Hierarchical thinking starts with recognizing where signal-to-noise is strongest. Item-store can be noisy (especially low sellers), while category-region is smoother and reveals trend and seasonal shape more clearly. A practical technique is to “borrow strength” from higher levels: use category-region seasonal profiles as priors or features for item-store forecasts, particularly for new items or sparse series.

Aggregation is straightforward summing, but reconciliation is the process of making forecasts coherent across the hierarchy. Conceptually, you can:

• Bottom-up: forecast item-store, then sum upward. Works well when item-store data is reliable and you need detailed accuracy, but can be noisy at higher levels.
• Top-down: forecast higher level (e.g., category-region), then allocate down using historical proportions. Useful when item-store is sparse, but can miss local shifts.
• Middle-out: forecast at a stable intermediate level (e.g., item-region), then allocate up and down.

Common mistake: allocating using proportions computed on censored sales (stockouts) or during promotion-heavy windows; this silently biases allocation away from constrained stores. Practical outcome: even a simple reconciliation rule, consistently applied, reduces stakeholder disagreements and makes your forecast outputs actionable for both store operations and supply chain planning.

Forecast metrics should translate into retail consequences: inventory, service level, and labor. Retail demand is often intermittent and skewed, so you want metrics that remain stable when volumes differ across SKUs and stores. Three essentials are WAPE, sMAPE, and bias—plus a tracking signal to detect drift.

WAPE (Weighted Absolute Percentage Error) is widely used in retail because it naturally weights high-volume items more: WAPE = sum(|error|) / sum(actual). This matches business impact because missing 50 units of a top seller hurts more than missing 1 unit of a slow mover. Practical tip: compute WAPE at the decision level (store-SKU for replenishment) and at rollups (category-region) to ensure improvements aren’t concentrated only in low-impact items.

sMAPE (symmetric MAPE) helps when actuals can be small because it scales by (|forecast|+|actual|). However, it can behave oddly near zero and can penalize aggressively when both forecast and actual are tiny. Use it as a secondary diagnostic, not your only KPI.

Bias measures systematic over- or under-forecasting. In replenishment, bias often matters more than “accuracy” because persistent under-forecasting drives stockouts, while persistent over-forecasting drives waste and markdowns. Track bias as sum(error)/sum(actual) over a rolling window and by segment (fresh vs ambient, A-items vs C-items, promo vs non-promo).

Tracking signals operationalize bias: a simple version is cumulative forecast error divided by mean absolute deviation over a window. When the tracking signal exceeds thresholds, it flags that your baseline is no longer centered—often due to an unmodeled level shift, assortment change, or new competitor. This is where forecast value-add (FVA) becomes practical: compare your new model against the baseline (seasonal naive, moving average). If FVA is negative (worse than baseline), do not ship it—fix data issues or rethink features before adding complexity.

Backtesting is where forecasting becomes an engineering discipline. A good backtest answers: “If we had used this model at the time, would it have improved decisions?” The key is to simulate reality: only use information that would have been available when the forecast was made. Violating this creates look-ahead bias—models that look great on paper and fail in production.

Design your backtest around your operational horizon and refresh cadence. If orders are placed weekly, run a weekly backtest: every Monday in history, train using data up to Sunday, forecast the next lead-time-plus-review window, then score against what actually sold (or what demand would have been, if you later correct for stockouts). If you refresh daily, use a rolling-origin evaluation: move the cutoff day by day, forecast forward, and accumulate errors. This exposes how performance changes across weekdays and during seasonal peaks.

Common sources of look-ahead bias in retail:

• Using finalized promo calendars when, historically, promos were confirmed late or changed. Backtest with the version that would have been known at forecast time.
• Leakage from inventory fields (e.g., “on-hand after sales”) that implicitly contains future sales information due to accounting timing.
• Imputing missing sales using future periods (forward/backward fill across the cutoff) which smuggles future data into training.

Practical outcome: a backtest report that stakeholders trust. Include baseline comparisons (last week, seasonal naive, moving average), WAPE and bias by segment, and a clear statement of the forecast horizon. When the business asks to change the horizon or cadence, you can rerun the same backtest framework and show the trade-offs transparently.

Classical time series methods (seasonal naïve, ETS, ARIMA) shine when you have a stable pattern, limited external drivers, and a clean history. They are strong baselines for store–SKU forecasting because they are hard to beat on “boring” demand: items with steady weekly seasonality and few interventions. Use them when interpretability must be simple, data is short, or you need a reliable fallback for cold-start SKUs.

ML becomes valuable when demand is conditional on many operational signals: promotions, price changes, ad exposure, endcaps, local events, weather, or delivery constraints. In retail, those factors vary by store, by week, and by SKU—exactly where a feature-based regressor helps. ML also handles interactions that are common in practice (e.g., promo effectiveness differs by store size and by baseline velocity).

A pragmatic workflow is “baseline + effects.” Start with a classical baseline capturing trend and seasonality (or encode those components as features), then let ML model the residual impact of operations. This makes troubleshooting easier: if the model fails, you can ask whether it failed on seasonality, or on promo lift, or because data was censored by stockouts.

• Common mistake: training ML on raw sales without stockout flags. The model learns that low inventory causes low demand and will under-forecast exactly when you need inventory.
• Practical outcome: decide the simplest method that meets service targets; complexity is justified only if it improves WAPE/bias and improves simulated fill rate under your reorder policy.

In short: use classical models as baselines and guardrails; use ML when you can represent store operations signals as features and you have enough variation in history to learn their effects.

For store–SKU demand with engineered features, three model families cover most needs.

Regularized regression (Ridge/Lasso/Elastic Net, or Poisson/Negative Binomial GLMs) is your “glass box.” It trains fast, is stable, and makes it easy to reason about coefficients. It is often the best first ML model for price elasticity and promo flags because you can enforce sensible behavior (e.g., monotonic price effects via feature design, or constrain with log transformations). Use it when you need robust incremental lift estimates and straightforward communication.

Gradient boosting (XGBoost/LightGBM/CatBoost) is the default workhorse for retail tabular forecasting. It handles nonlinearities, missing values, and interactions with little preprocessing. It is typically strongest on WAPE for medium/high-velocity items. If you add features like “weeks since last promo,” “rolling 4-week average,” “day-of-week,” “holiday proximity,” and “in-stock rate,” boosting can capture complex patterns without requiring deep architecture work.

Tabular neural nets can help when you have very large data, many categorical identifiers (store, SKU, region) and want embeddings to generalize across similar stores/SKUs. They require more tuning and stronger validation discipline. They can be useful for cold-start transfer (new store or new SKU) when embedding similarity matters.

Regardless of model, treat feature engineering as product design. Typical demand features include: seasonal indicators (week-of-year, month), trend proxies (time index), lagged sales (t-1, t-7), rolling means/medians, promo depth, price index vs regular price, inventory/on-hand, delivery day flags, and stockout indicators. For promo/price effects, separate offer mechanics (discount %, multi-buy) from exposure (ad, display, aisle end). Then measure incremental lift by comparing predictions with promo features on vs off (keeping other features fixed) to estimate uplift in units.

Random train/test splits are a trap in forecasting because they leak the future into the past. Retail time series also has regime changes: new planograms, competitor entry, or macro shifts. Your validation must mimic deployment: you train on history up to a cutoff date and predict forward.

The practical standard is rolling-window cross-validation. Choose a forecast horizon that matches planning (e.g., 1 week ahead for daily ordering, or lead-time + review period). Then create multiple folds: train on weeks 1..T, validate on T+1..T+h; slide forward and repeat. This reveals stability across seasons and promo calendars. If promotions are heavy in Q4, make sure at least one validation fold includes Q4.

For store–SKU panels, be careful with leakage via aggregations. If you compute “rolling 4-week mean” for a date, it must only use past data. If you compute “category average,” ensure it is computed using only historical data available at that time, not the full series.

Use retail-relevant metrics: WAPE (sum |error| / sum actual) for volume-weighted accuracy, and bias (sum error / sum actual) to detect systematic under/over forecasting. Bias matters because it maps directly to service level and inventory. A model with slightly better WAPE but strong negative bias can create stockouts, hurting sales and trust.

• Common mistake: tuning hyperparameters on the same single holdout week. You end up optimizing for noise and the latest promo pattern.
• Practical outcome: a CV report that shows WAPE and bias by store cluster, SKU velocity band, and promo vs non-promo periods—so you know where the model is safe to automate reorder and where it needs guardrails.

At the store level, many SKUs are slow movers: long stretches of zeros with occasional sales bursts. Standard regressors trained on raw units can behave poorly: they either predict tiny nonzero demand every period (creating chronic over-ordering) or collapse to zero (missing sporadic sales). Intermittent demand needs explicit handling.

Croston-style methods separate two processes: the size of a nonzero demand and the interval between nonzero demands. You can implement classic Croston, SBA (Syntetos–Boylan Adjustment), or TSB (Teunter–Syntetos–Babai) as baselines for slow movers. They often outperform “fancy” ML when data is extremely sparse because they respect the structure of demand occurrences.

In ML terms, think two-stage modeling (a zero-inflated idea): first predict the probability of demand occurring (classification: demand > 0), then predict the demand size conditional on occurrence (regression on positive cases). The final expected demand is P(occur) × E(size | occur). This approach also supports operational features: stockout flags should reduce observed occurrence but not true occurrence; you may need a censored-demand correction where periods with low on-hand are excluded from training or modeled as “unknown.”

Practical feature tips for intermittent SKUs: include “weeks since last sale,” “count of sales in last 8 weeks,” and “on-hand days-of-supply.” For outliers (one-time bulk purchase), cap or winsorize the target, or add an “event order” flag if it is known (e.g., store-to-store transfer).

The goal is not perfect point accuracy; it is preventing systematic overstock while maintaining acceptable availability. Slow movers often use different reorder policies (higher minimum order constraints, less frequent review), and your modeling approach should align with that reality.

Reorder decisions require uncertainty, not just a single number. If you order to the mean forecast, you implicitly choose a service level that may be too low for high-variability items or too high for slow movers. To connect forecasting to service levels, you need prediction intervals or quantile forecasts.

A practical method is quantile regression. Many gradient-boosting libraries can train models to predict the 50th percentile (median) as well as the 80th, 90th, or 95th percentile. For a target cycle service level, you order to a high quantile over the lead-time demand distribution. For example, if lead time is 7 days and you want ~95% cycle service for a critical SKU, plan to the 95th percentile of lead-time demand (or approximate it by summing daily quantiles carefully, or forecasting directly at the lead-time aggregation level).

Calibration matters: a “90% interval” should contain the actual about 90% of the time on held-out periods. Check coverage by SKU velocity band and during promos. If your intervals are too narrow, you will see stockouts; too wide, you inflate safety stock. You can post-calibrate intervals using conformal prediction or simple scaling based on validation residuals per segment.

Translate uncertainty into inventory terms: safety stock is essentially the buffer between a reorder point and expected demand during lead time. Quantiles let you compute reorder points consistent with service targets. When you simulate replenishment (min-max, (s,S), reorder point), use the quantile forecast (or sampled demand scenarios) to estimate fill rate and inventory and then choose the service target that balances lost sales vs holding cost.

Demand planning fails when stakeholders cannot reconcile forecasts with what they see in stores. Explainability is not a presentation layer; it is a debugging tool and a change-management tool. You need explanations that answer: “What drove the forecast change?” and “How much did the promotion contribute?”

For tree-based models, SHAP-style explanations are a practical standard. They decompose a prediction into feature contributions relative to a baseline. In planner-friendly terms, you can show that next week’s 120 units forecast is composed of: baseline seasonality +15, trend +5, promo discount +40, display +25, price increase −10, and stockout risk adjustment −5. Store teams can validate the story: “Yes, we have endcap exposure,” or “No, the display was canceled,” which becomes actionable feedback.

Promo attribution should be designed, not improvised. Define a “promo off” counterfactual: set promo flags to 0 and price to regular while keeping seasonality and recent sales history the same. The difference between promo-on and promo-off predictions is your estimated incremental lift. Track lift by mechanic, by store cluster, and by SKU. Watch for common pitfalls: if stockouts occurred during the promo, observed sales understate true lift; your model may attribute low sales to a weak promo when the real issue was availability.

Build explainable outputs into routines: a weekly exception report highlighting large forecast deltas, top drivers, and whether the driver is controllable (price/promo) or uncontrollable (holiday). This supports better collaboration: planners can adjust inputs (e.g., confirm promo depth, correct delivery schedules) rather than manually overriding forecasts blindly. Over time, consistent explanations increase trust and reduce the “spreadsheet shadow planning” that blocks automation.

Section 5.1: Inventory math refresher: cycle stock, safety stock, service levels

Reorder policies are built from two inventory components. Cycle stock covers expected demand between replenishments. Safety stock covers uncertainty—demand that is higher than expected, lead times that run long, or both. If you’re ordering weekly with a two-day supplier lead time, cycle stock is shaped by that cadence; safety stock is shaped by variability during the “risk window” where you can’t react.

Two service concepts matter in retail. Cycle service level (CSL) is the probability you do not stock out during a replenishment cycle. Fill rate (often called β service level) is the fraction of demand you fulfill immediately from on-hand inventory. Stores often care more about fill rate because a single stockout event might be tolerable if it affects few units, while repeated small misses can destroy availability.

To connect service to safety stock, you typically use a normal-approximation “z-score” approach: Safety Stock = z × σ_LTD, where σ_LTD is the standard deviation of demand over lead time (or over the protection period in periodic review). The engineering judgment is in estimating σ_LTD correctly and choosing what “service level” means for your business (CSL vs fill rate) and category (fresh vs shelf-stable).

• Common mistake: using the standard deviation of daily sales without adjusting for stockouts. Stockouts censor demand; the observed sales understate true demand and artificially reduce σ.
• Common mistake: mixing time units. If lead time is in days but demand is weekly, your σ_LTD will be wrong by a scale factor.

Practically, start with a service target by category (e.g., 98% for staples, 95% for long-tail items, lower for highly perishable). Then treat safety stock as a controllable lever: raising it increases availability and inventory, and may increase waste for perishables. You’ll validate the tradeoff later via simulation, not by trusting a single formula.

Section 5.2: Lead time modeling (fixed vs variable lead times)

Lead time is not a single number in most retail networks. It has at least three layers: (1) supplier/warehouse processing time, (2) transportation time, and (3) store receiving/put-away time (including missed deliveries). Your reorder policy is only as good as your lead time model, because lead time defines the “no-control” window where you cannot replenish faster even if demand spikes.

Start by computing actual lead time from historical order and receipt timestamps per store-SKU (or store-vendor if SKU-level receipt data is limited). If data quality is uneven, you can approximate with shipment calendars, but be explicit about the assumption. Then decide whether to model lead time as fixed (useful when variance is low and schedules are strict) or variable (needed when lateness is common or seasonal).

To compute lead time demand (LTD), align demand to your lead time window. For continuous review: LTD is demand during the lead time L. For periodic review: the protection period is L + R, where R is review interval (e.g., order every 7 days). Compute:

• Mean LTD: μ_LTD = μ_d × L (if daily demand is stationary), or sum forecasted demand across the next L days.
• Std dev LTD (fixed L): σ_LTD = σ_d × √L (assuming independence; adjust if strong day-of-week autocorrelation).
• Std dev LTD (variable L): σ_LTD ≈ √(E[L]·σ_d² + (μ_d²)·Var(L)).

Engineering judgment: retail demand is rarely i.i.d. Promotions, weekends, and weather create autocorrelation and heteroscedasticity. Use your baseline forecast to compute μ over the lead time horizon, and compute σ from forecast errors (not raw sales), ideally after correcting for stockouts and removing one-off outliers. This is where your earlier work—turning promos and operational signals into features and correcting censored demand—directly improves replenishment parameters.

Finally, segment SKUs. Fast movers with stable lead times can use simpler models; slow movers and items with erratic lead times benefit from pooling information at vendor/store level and applying shrinkage (regularization) so you don’t overfit noise.

Section 5.3: Reorder point (ROP) and order-up-to (S) policy design

The classic continuous-review policy is: when inventory position (on-hand + on-order − backorders) falls to or below a reorder point (ROP), you place an order. The ROP is designed to cover expected demand during lead time plus safety stock:

• ROP = μ_LTD + z × σ_LTD

In practice, most stores don’t run true continuous review; they review daily or a few times per week, and orders batch by vendor. Still, the ROP logic is useful because it separates two concerns: “when to order” (trigger) and “how much to order” (quantity).

For the order quantity, an order-up-to level S (also called base-stock level) is often easier operationally than EOQ. You compute S to cover the protection period (lead time plus review interval). Then order quantity is:

• Q = max(0, S − inventory_position)

How do you set S? Use the same structure as ROP but on the protection period: S = μ_PP + z × σ_PP. This is where you align reorder logic with your forecast horizon. For example, if you order every Monday for Wednesday delivery, your protection period must include Monday→Wednesday lead time plus the time until the next order can arrive.

Common mistakes show up immediately in stores:

• Using on-hand instead of inventory position: you ignore orders already placed, causing double-ordering.
• Forgetting pending allocations/holds: inventory that is damaged, reserved for e-commerce picks, or sitting in receiving is not truly available.
• Ignoring forecast bias: if your forecast is systematically low, ROP and S will look “right” on paper but still produce chronic stockouts. Measure bias (signed error) and correct it before parameterizing safety stock.

Planner outcome: you should be able to produce a per store-SKU parameter set (ROP, S, and implied safety stock) from cleaned demand and lead time data, then check reasonableness with quick diagnostics: days of supply implied by S, expected order frequency, and whether the ROP is above average on-hand for steady sellers.

Section 5.4: Min-max, periodic review, and (s,S) policy selection

Retail replenishment often uses min-max language because it matches store behavior: if inventory position drops below a min, order up to a max. This is essentially an (s,S) policy, where s is the reorder threshold and S is the order-up-to level. In periodic review systems (order on a fixed schedule), you may skip the threshold and always order up to S; but min-max adds a useful guardrail to prevent tiny, noisy orders for slow movers.

Policy choice is less about math purity and more about operational fit:

• Order-up-to (S) every review: good when ordering is cheap and frequent, and demand is high enough that small corrections matter.
• (s,S) / min-max: good when you want to avoid frequent micro-orders, when vendors have minimums, or when store execution prefers fewer line items.
• Pure ROP with variable Q: useful in systems that can place orders continuously and when lead times are stable.

To parameterize min and max, reuse the same demand-over-protection-period approach, but define:

• Max (S): target stock after ordering, typically μ_PP + z·σ_PP.
• Min (s): reorder trigger, often μ_LTD + z·σ_LTD, or a fraction of max for slow movers.

Engineering judgment: slow movers break normal assumptions. If an item sells 0–2 units per week, a normal-based z approach will produce awkward fractional safety stocks that do not map to reality. In those cases, consider discrete-demand methods (Poisson/negative binomial), or simpler guardrails such as “keep 1 on hand” with a small max. Your job is to pick a policy that the store can execute and that behaves sensibly under lumpy demand.

Finally, incorporate operational signals: planned promos should raise μ over the relevant horizon; known store events (resets, holidays) can alter both μ and σ. This is where the “forecasting features” from earlier chapters become reorder inputs, not just analytics artifacts.

Section 5.5: Constraints: pack size, shelf capacity, truckload, budget

The biggest difference between a classroom reorder policy and a real store policy is constraints. The math might tell you to order 7 units, but the vendor ships in cases of 12. The model might order up to 60, but the shelf plus backstock only holds 40. If you ignore constraints, your “optimal” policy becomes operationally impossible and gets overridden manually—often inconsistently.

Implement constraints as explicit transformations after computing the unconstrained order quantity Q:

• Pack/case rounding: Q_case = ceil(Q / pack_size) × pack_size. Consider a minimum order multiple per vendor to reduce receiving complexity.
• Shelf/backroom capacity: cap S (or cap the resulting on-hand after receipt) to physical capacity; if capacity is unknown, estimate from planograms or historical max on-hand.
• Truckload/route constraints: if orders must fit pallet or cube limits, allocate space by margin, velocity, or service criticality. This turns replenishment into an optimization problem; start with simple heuristics and simulate.
• Budget/open-to-buy: scale orders when spend exceeds limits, but track the expected service impact. Cutting all SKUs equally is usually worse than protecting high-velocity items.

Common mistake: applying rounding first and then computing inventory position. Always compute based on true inventory position, then round the final Q. Another mistake is hiding constraints in ad hoc rules (“never order more than 2 cases”) without documenting why; that makes policy evaluation impossible.

Planner overrides should be treated as a controlled input, not a hidden patch. Create exception rules such as: block orders when inventory is likely inaccurate (negative on-hand), raise S temporarily for a confirmed promo, or reduce orders for perishables when waste risk is high. Require an override reason code and an expiry date. This makes the human-in-the-loop system auditable and improves the data you use to refine policies.

Section 5.6: Policy evaluation via simulation (fill rate, OOS, waste, turns)

You do not choose safety stock or a policy family by formula alone—you choose it by outcomes. Simulation is the practical bridge between analytics and store reality. A simple day-by-day (or week-by-week) inventory simulator can replay history using your forecast (or actual demand) and emulate ordering, receiving, and constraint logic. Then you compare policies on metrics leaders care about: availability and dollars tied up.

A useful simulation loop tracks: beginning on-hand, demand (censored-corrected or true demand estimate), sales fulfilled, lost sales (or backorders if allowed), receipts, and ending on-hand. You also track inventory position for ordering decisions. Inject lead time as fixed (deterministic) or sample from the empirical distribution to capture late deliveries.

• Fill rate: fulfilled units / true demand units.
• OOS rate: fraction of days with zero on-hand (or fraction of demand lost). Define it carefully; different definitions drive different behaviors.
• Waste/expiry: for perishables, model spoilage with a simple shelf-life clock or use shrink as a function of days on hand.
• Turns: annualized sales / average inventory (units or dollars). Higher isn’t always better if it harms service.

Run A/B comparisons: ROP-only vs order-up-to; min-max with different mins; different z values (service targets); and different constraint strategies (strict capacity caps vs prioritized allocation). Look for failure modes: oscillation (over-order then under-order), chronic under-service on promo weeks, and “death by rounding” where case packs cause systematic overstock.

Engineering judgment shows up in how you interpret results. If fill rate improves but waste spikes, you may need category-specific service targets or perishability-aware caps. If turns look great but OOS is unacceptable, your safety stock is too low or your lead time variability is underestimated. Simulation gives you a defensible way to tune parameters and to explain tradeoffs to store operations, finance, and merchandising in the same language: service, waste, and working capital.

Section 6.1: From notebook to pipeline: orchestration and data contracts

A notebook proves you can forecast. A pipeline proves the organization can depend on forecasting. Start by writing down the “job” as a sequence of deterministic steps: ingest data, validate it, create features (promos, stockouts, deliveries), train or refresh baseline models, generate forecasts, convert forecasts to reorder policies (min-max, reorder point, (s,S)), and publish outputs to a table or API that downstream systems can consume.

Orchestration is how this sequence runs reliably. In practice, you schedule daily or weekly jobs using a workflow tool (Airflow, Dagster, Prefect, or a cloud-native scheduler). Make each step idempotent (safe to rerun) and timestamped. Common mistake: overwriting yesterday’s outputs without a version. Planners need to compare “what we recommended” vs “what happened,” so store snapshots.

Data contracts are your insurance policy. Define required columns, allowed ranges, and grain. For example: sales at store–SKU–day, on-hand inventory at store–SKU–day, deliveries at store–SKU–day, promo flags with start/end dates, and item/store status. Validate basic rules before modeling: no negative sales, no future delivery dates, on-hand not exploding from 0 to 10,000 without a delivery record. When a contract fails, fail the pipeline loudly and notify an owner, rather than producing nonsense forecasts.

• Minimal pipeline outputs: baseline forecast (mean), prediction interval (e.g., P50/P90), reorder recommendation (order qty, target stock, safety stock), and “reason codes” (promo uplift, stockout-censored, new item).
• Run cadence: daily for fast movers and fresh; weekly for center store; always align with ordering cutoffs and lead-time calendars.
• Engineering judgment: prefer simpler models that run reliably and degrade gracefully over complex models that break during holidays or item transitions.

Packaging your work this way also clarifies ownership boundaries: upstream data teams own raw feeds, you own transformations and business rules, and replenishment owns execution decisions—unless your organization explicitly automates ordering end-to-end.

Section 6.2: Human-in-the-loop: approvals, overrides, and audit trails

Retail ordering is a socio-technical system. Even with strong accuracy, you need a controlled way for people to approve, override, and document decisions—especially during promos, supply constraints, or store disruptions. Human-in-the-loop does not mean “let everyone edit anything.” It means defining which decisions are automatable, which require review, and which require explicit sign-off.

Start with an approvals workflow: (1) pipeline generates recommended orders, (2) exceptions are flagged for review, (3) planners approve or adjust, (4) final orders are exported to the ordering system. Exceptions should be rule-based and sparse: unusually high order quantity vs typical, forecast uncertainty spike, new item with weak history, known store event, supplier allocation, or recent stockout patterns that risk feedback loops.

Overrides must be traceable. Build an audit trail table with who changed what, when, and why. Capture structured reason codes (e.g., “supplier cap,” “store remodel,” “promo display added,” “local event,” “weather”) plus free-text notes. Common mistake: allowing overrides without reasons; this destroys learning because you can’t distinguish model error from business constraints.

• Guardrails: set max/min order caps per SKU, enforce case-pack rounding, and respect truck capacity or budget constraints.
• Separation of concerns: keep the model output immutable; store the override as a separate layer. This preserves the ability to backtest the model honestly.
• Feedback handling: if a SKU was out of stock, do not treat low sales as low demand without adjusting for censored demand; otherwise your system “learns” to under-order.

In interviews, being able to describe this control loop is a differentiator. It shows you understand not only forecasting, but how forecasts become decisions under real operational constraints.

Section 6.3: Monitoring: accuracy, bias, service, and business KPI linkage

Monitoring is where demand planning becomes operationally credible. Your monitoring should answer four questions: Is the data healthy? Is forecast accuracy stable? Is the system biased (systematically over/under)? And are we improving business outcomes like service level, waste, and working capital?

Accuracy metrics must be retail-relevant and segmented. WAPE is usually more interpretable than MAPE at store–SKU level because zeros and low volumes are common. Track WAPE by department, velocity tier, and replenishment method. Bias matters because it compounds into inventory: measure mean error (or percent bias) and monitor it by store cluster and SKU family. A small average bias can hide big directional issues in certain regions.

Link model metrics to inventory outcomes. A forecast can look “accurate” while harming service if it misses peaks. Build dashboards that show: in-stock rate/service level, lost sales proxies (e.g., demand when on-hand was zero), backroom/overstock indicators, waste or markdowns (for perishables), and inventory turns. Then relate them to forecast error and to reorder policy settings like safety stock and lead time assumptions.

• Drift monitoring: detect changes in demand patterns (new competitor, price change, assortment shift) and in data generation (POS system updates, new stock counting process).
• Stockout feedback loop monitoring: track the share of days censored by stockouts; if it rises, the model may start under-forecasting unless corrected.
• Model staleness: monitor time since last retrain and performance decay; schedule retraining based on drift signals, not only a fixed calendar.

Common mistake: only monitoring WAPE and declaring success. Executives care about availability and capital. Your monitoring should tell a planning narrative: “Accuracy held steady, bias improved, service increased by X points, and inventory stayed flat because safety stock was tuned.” That narrative earns trust and adoption.

Section 6.4: Change management in stores: adoption and exception management

Store teams adopt systems that reduce surprises and respect local reality. If your recommendations routinely ignore shelf capacity, case-pack constraints, or delivery windows, store managers will stop engaging. Change management starts by designing the process around store operations, not asking stores to adapt to your spreadsheet.

Define “who does what” on order day. For example: the system publishes recommendations by 10am; department leads review exceptions; the store manager approves; orders transmit by cutoff. Keep the review workload small by focusing on exceptions. Exceptions should be explainable: “order increased because promo starts next week,” “order reduced because on-hand is high and sell-through slowed,” “high uncertainty due to recent stockouts.” Explanations don’t need to be perfect; they need to be consistent and legible.

Build an exception management playbook. When the dashboard flags an issue, the response should be clear: if on-hand is unreliable, initiate cycle count; if delivery data is late, hold orders or use last known receipt; if a SKU is repeatedly stocked out, escalate to supplier or adjust service target and safety stock. Common mistake: routing every issue to the data science team. Most exceptions should be triaged operationally with a defined escalation path.

• Adoption metrics: override rate, exception queue size, time-to-approve, and “recommendation acceptance rate” by store.
• Training approach: teach store teams the top 5 reasons recommendations change; avoid model jargon, use operational language (promo, delivery, stock count, shelf capacity).
• Governance: set a weekly cadence to review chronic exceptions and adjust business rules or reorder parameters.

Your goal is operational calm: fewer fire drills, fewer last-minute expedites, and predictable shelf availability. When you can show that, resistance drops quickly.

Section 6.5: Portfolio artifacts: repo structure, README, and results framing

Your portfolio case study should look like something that could be shipped. Hiring managers don’t need proprietary data; they need evidence you can structure work, make tradeoffs, and communicate outcomes. Build a small but complete project: store–SKU demand forecasting, stockout correction, and reorder simulation with service targets.

Use a repo structure that mirrors production thinking. Example: /data (sample or synthetic), /src (feature engineering, modeling, reorder policy, simulation), /pipelines (orchestration entry points), /notebooks (exploration only), /tests (key data contract checks), and /docs (dashboard mockups, decision notes). Include a reproducible environment file and a single command to run end-to-end.

Your README is the executive-ready narrative. Start with the business problem (“reduce stockouts without inflating inventory”), define the operating constraints (lead times, case packs, promo calendars), describe the method (baseline seasonal/trend model, stockout handling, reorder policy), and present results in retail terms: WAPE and bias plus service level and inventory impact from simulation. Common mistake: showcasing only model metrics. Add a before/after inventory simulation and explain how safety stock was chosen.

• Dashboard outline (one page): accuracy (WAPE, bias), service (in-stock rate, lost sales proxy), inventory (days of supply, overstock), and exception queue (top SKUs/stores with reason codes).
• Interview walkthrough: 5 minutes on problem/context, 5 on data issues and contracts, 5 on modeling and reorder policy, 5 on monitoring and change management, 5 on results and lessons learned.

This framing proves you can operate at the intersection of analytics, systems, and retail execution—exactly what “AI demand planning” roles require.

Section 6.6: Role mapping: demand planner, replenishment analyst, DS/ML adjacent paths

Career transitions work fastest when you map your existing strengths to the job’s operating cadence. Retail managers already understand promotions, stockouts, deliveries, and the cost of being wrong. Your new layer is analytical rigor and system thinking. This section helps you target roles and plan your first 30/60/90 days.

Demand Planner: typically owns forecast creation and consensus meetings. Your edge is store-level operational signal translation: promo execution quality, shelf capacity constraints, and stockout correction. Emphasize your ability to explain forecast moves, reduce bias, and align stakeholders.

Replenishment Analyst / Inventory Planner: typically owns order parameters and service targets. Your edge is reorder policy design and simulation: lead time variability, safety stock, and (s,S) tuning by velocity tier. Emphasize measurable service improvements and fewer expedites.

DS/ML-adjacent paths: forecasting data scientist, ML engineer for supply chain, analytics engineer. Your edge is “last-mile realism”: you understand how data gets messy in stores and how feedback loops form. Emphasize pipelines, monitoring, and human-in-the-loop controls.

• 30 days: learn data sources and ordering cadence; validate data contracts; recreate baseline WAPE/bias; identify top stockout-censored SKUs and chronic exceptions.
• 60 days: ship a repeatable pipeline for one category/region; implement monitoring dashboard; run inventory simulation to propose updated safety stock/service targets.
• 90 days: expand to additional categories; formalize approvals/overrides and audit trails; present an executive narrative tying accuracy to service and inventory outcomes.

When you can describe this plan clearly—and back it with a portfolio that demonstrates pipeline thinking—you present as someone ready to run a planning system, not just analyze one.