Forecasting that keeps shelves full, not overstocked
A demand-forecasting system that turns sales history, seasonality, and promotions into store-level reorder recommendations buyers can trust.
What the engagement involved
- Industry
- E-commerce & Retail
- Duration
- 13 weeks
- Cooperation model
- Time & materials
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The question we were asked
Buyers over-ordered slow movers and ran out of hits. We built forecasting that recommends what each store should reorder and when.
A chain of twenty-five stores whose buyers reordered from last month's sell-through, one category at a time, in a weekly meeting. Capital was the trigger: an inventory audit put a meaningful share of stock in lines that hadn't moved in two seasons, while the fastest sellers were out of stock somewhere every week. Both were the same fault seen from two ends.
Data & AI
The decision, first
- 01
Stockouts reduced by 41% across high-velocity product categories.
Stockouts fell because the trigger moved from current stock to projected cover, which shifts the warning from the week of the problem to three weeks before it.
- 02
Carrying cost of excess inventory dropped by 28% within 90 days of launch.
The excess cleared because the same model run backwards flags lines that won't sell through by season end. Before, dead stock had never been identified, only discovered.
- 03
Forecast model accuracy reached 90% across seasonal demand shifts.
Accuracy is reported against the confidence band on purpose: a forecast that knows when it's unsure is what buyers were willing to act on.
What the numbers couldn't answer
Reorder decisions relied on last month's numbers, leaving popular items out of stock and capital tied up in dead inventory.
Reordering from last month's numbers means always ordering into the demand that has just passed. On seasonal lines that's precisely backwards, and the audit showed it: the dead stock was concentrated in items that had spiked once, been reordered on the spike, and arrived after it. Meanwhile lead times varied by supplier and were treated as a single average.
We built a pipeline unifying sales, seasonality, and promo calendars, trained per-store demand models, and gave buyers a reorder dashboard with confidence bands.
How we worked it through
Consolidated POS, promo, and seasonal signals into one feed
Consolidation exposed the real obstacle: promotion dates were recorded inconsistently across the chain, and cleaning them took longer than the modelling.
Trained per-store, per-SKU demand models
Models are fitted per store, not per chain, because the seasonal curves of a city-center branch and a retail park are genuinely different shapes.
Surfaced reorder recommendations with confidence ranges
Reorder quantities solve against each supplier's real lead-time spread and minimum order quantity, so a recommendation is something a buyer can raise unchanged.
Piloted in ten stores before chain-wide rollout
Ten stores ran for six weeks with buyers free to ignore every recommendation, and the gap between taken and ignored became the tuning signal.
Phase by phase
Phase 1: Data Pipeline & Feature Store
POS & Seasonality Signal Consolidation
Unified historical POS sales data, promotion calendars, and local holiday/weather signals into a normalized feature store.
- Data Lake Architecture
- Feature Store Pipeline
- Historical Data Audit
Phase 2: Predictive Demand Modeling
Per-Store SKU Demand Engine
Trained machine learning demand models per SKU and store location with probabilistic confidence intervals.
- Demand Model Suite
- Model Validation Report
- Accuracy Benchmarks
Phase 3: Buyer Dashboard & Workflow
Reorder Cockpit & Purchasing API
Designed a reorder dashboard that surfaces stockout risk warnings and recommended purchase orders, each approved by a buyer in one click.
- Buyer Dashboard UI
- Purchasing System API
- Alerting Engine
Phase 4: Store Pilot & Chain Deployment
Staged Rollout & Inventory Audit
Piloted in 10 store locations before rolling out chain-wide across all 25 retail stores, measuring stockout drops.
- Pilot Performance Report
- Chain Rollout Clearances
- Inventory Impact Analysis
The ten overnight feeds behind every forecast and when each last ran, the one store-SKU-week feature table they build, and the rollout from a ten-store pilot to all twenty-five stores by wave.
What it changed
−41%
Stockouts
−28%
Excess inventory
90%
Forecast accuracy
Stockouts and excess inventory compare the two quarters after rollout with the same two quarters the previous year, so seasonality is held constant. Forecast accuracy is measured at the store-SKU-week level against actuals, reported as the share of forecasts inside their own stated confidence band instead of as a point-estimate error.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Store-Level Reorder Recommender
Generates purchase order quantities per store from lead times and demand forecasts.
Two years of sales, the promotional calendar and the store-level seasonality curves were unified into one feature table per store per SKU per week. Reorder quantities are solved against each supplier's actual lead time and minimum order quantity, never a global rule, so the recommendation is something a buyer can raise as a PO without adjusting it. Confidence bands travel with every number.
- Per-store, per-SKU weekly feature table
- Solved against real supplier lead times and MOQs
- Confidence bands attached to every recommended quantity
Replenishment for one store: recommended quantities and their value, pre-ticked so a buyer approves the week in one pass, with one line opened to show the order solved from the top of its band, the supplier's lead-time spread, the case pack and the MOQ.
The risk queue across stores, ordered by days left before the line breaks: alerts fired on projected cover, each naming the SKU, the store, the date the trouble lands and the action that avoids it, with dead stock flagged at season end.
Stockout & Overstock Risk Alerts
Early warnings for imminent stockouts and building dead stock.
Alerts fire on projected cover instead of current stock, which moves the warning from the week of the stockout to three weeks before it. Dead stock is flagged by the same model running the other way: units whose forecast demand won't clear them before the season ends. Each alert names the SKU, the store, the date the trouble lands and the action that avoids it.
- Fires on projected cover, not on today's stock level
- Same model run in reverse to flag dead stock
- Every alert names the date and the action that avoids it
Promotion Impact Simulator
Eight spring promotions modeled with baseline, expected uplift and the extra units each needs ordered in; the uplift traced to comparable past promotions, and two scenarios compared side by side before one is committed.
Simulates inventory requirements for upcoming marketing campaigns and seasonal sales.
Buyers can stage a promotion (depth, duration, stores, SKUs) and see the inventory it would require before committing to it, with the uplift estimated from how comparable promotions actually performed instead of a flat multiplier. Scenarios are saved and comparable side by side, and the one that ships is recorded so the following year's forecast learns from what really happened.
- Uplift estimated from comparable past promotions
- Scenarios saved and comparable side by side
- The chosen scenario recorded and fed back into next year
How the engagement ran
- 01
A cross-functional team of 6 worked on a time & materials basis over 13 weeks, covering Data engineering, Forecast models, Buyer tooling. We ran two-week increments, each one shippable, reviewed live before it merged. Decisions were recorded as they were made, so the reasoning survived the people who made it.
Ten stores piloted for six weeks before anything went chain-wide, with buyers free to ignore every recommendation, and the gap between what they ignored and what they took became the tuning signal. Time and materials suited a project whose modeling scope genuinely couldn't be fixed until the data quality was known.
One SKU, one week
Why the order is 60, and why last month’s rule said zero
One spring line at one store, worked through: the forecast as a range, how earlier ranges held up against what sold, and the quantity solved from the top of the band against the supplier’s lead time and case pack. Switch tabs, or use the arrow keys once one is focused.
The forecast is a range, not a number. Store 014 is a retail-park branch, so it uses its own seasonal curve instead of the chain's, and the yard event on 04/27 widens that week's band upward. The buyer sees the band before any quantity.
From last night's register data to this morning's purchase order
Built in Python with FastAPI, Pandas and Scikit-Learn over PostgreSQL, with a React cockpit for buyers. The confidence band is computed at the model and carried unchanged to the screen where the order is approved.
- 01 · SourcePOS, promotions, seasonalityRegister sales, the promotion calendar and local holiday and weather signals arrive as one feed, with promotion dates cleaned chain-wide before any model sees them.
- 02 · Feature storeStore-SKU-week tableTwo years of sales normalized into one row per store, per SKU, per week, so every model reads the same history.
- 03 · EnginePer-store demand modelsFitted per store, not per chain, because a city-center branch and a retail park have different seasonal shapes. Every forecast carries a confidence band.
- 04 · Solve & alertReorder solver + risk engineQuantities solved against each supplier's real lead-time spread and MOQ; alerts fire on projected cover, and the same model run in reverse flags dead stock.
- 05 · DeliverBuyer cockpit + purchasing APIRecommendations arrive pre-ticked with their bands for one-click approval, and approved orders go to the purchasing system through its API.
Stated uncertainty, real lead times, human approval
Every quantity says how sure it is
Confidence bands travel with every recommended quantity, and accuracy is reported as the share of forecasts landing inside their own stated band, so an unsure forecast says so before capital is committed.
Solved against the real supplier
Each order is solved against that supplier's actual lead-time spread and minimum order quantity instead of a single average, so the recommendation can be raised as a PO without being adjusted.
The buyer keeps the decision
Ten stores ran for six weeks with buyers free to ignore every recommendation before anything went chain-wide, and the gap between what was taken and what was ignored became the tuning signal.
Are your buyers still reordering from last month’s numbers? Scope your build in 3 minutes.
Scope your buildNearby engagements
Data & AnalyticsA checkout that stopped losing sales to a 6-second load
Profiling found the real bottleneck behind a slow checkout (an N+1 query and an oversized bundle) and tuned both, with before-and-after metrics locked in as a baseline against future regressions.
E-commerce & Retail · 5 weeks
Web PlatformsA reader people finish, and a library that remembers where they stopped
A reading platform for a comics catalog: a browse surface people can actually navigate, a reader that gets out of the way, and a history that puts everyone back on the page they left.
E-commerce & Retail · 18 weeks
Web PlatformsOne number, a whole handset, and a database that keeps up with 125 brands
A metered IMEI lookup service that turns fifteen digits into a device, its specifications and its status. It's sold three ways to three audiences and backed by a device database that maintains itself.
Consumer Electronics · 22 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
