Stockout prediction with lost sales recovery

Grow2.ai deploys a stockout-prediction pipeline that reads data from the data warehouse and predicts when each SKU will go into deficit. The model accounts for sales history, seasonality, and current stock levels, and when the stockout probability exceeds a threshold — sends an alert to the working channels of the procurement team.

What the automation does

1. Collects data from the data warehouse: order history, current stock levels by SKU, supply parameters (lead time, MOQ).
2. Calculates a consumption forecast for each SKU over the horizon up to the next delivery date.
3. Compares the projected consumption against stock on hand and calculates the probability of a stockout before the next replenishment arrives.
4. Sends a structured alert to the communications channel: category, SKU, stock level, projected out-of-stock date, recommended order volume.
5. Logs the alert event and the team's decision to gradually adjust thresholds and improve the model.
6. In parallel, identifies SKUs with excess stock where purchasing should be reduced.

What the automation does NOT do

• Does not place orders with suppliers automatically — the final purchasing decision remains with the buyer.
• Does not replace ERP or WMS as the source of truth for stock levels; the pipeline reads data but does not write to warehouse management systems.
• Does not guarantee 100% accuracy: rare events (viral sales, supplier disruptions, sudden demand shifts) require manual adjustment.

The primary goal is to shift the purchasing decision moment from 'the product is out of stock' to 'the product will be out of stock in N days'. In the cited e-commerce case, this reduced the number of stockouts from 47 to 8 per quarter (-83%), helped recover £18,000 in lost sales, and cut excess inventory by £43,000.

The solution is suited for e-commerce and retail with a catalog of hundreds of active SKUs and at least 6 months of sales history. The cleaner the data in the data warehouse, the more accurate the forecast; a basic setup with daily granularity delivers a noticeable effect after just 2-3 order cycles.

The technical solution is a pipeline on custom-code (most commonly Python) that connects to the data warehouse, computes a forecast for each SKU, and sends alerts to a communications channel. Deployment takes several weeks with data ready.

Main flow

1. Daily extract.A scheduler (cron, Airflow, or a workflow engine) runs the pipeline in the morning before the procurement team's shift begins. The script queries the data warehouse and exports sales for the relevant period, current stock levels, and the SKU reference.
2. Feature engineering. Rolling sales averages by SKU, weekly and annual seasonality, trend, and inventory turnover rate are calculated. Supplier lead time — from order placement to goods arrival at the warehouse — is taken into account.
3. Forecast model. Expected consumption for each SKU is calculated over the horizon until the next possible delivery. The baseline version uses statistical methods (exponential smoothing, Prophet); the advanced version uses gradient boosting with external factors (promotions, holidays).
4. Stockout score. Based on the forecast and current stock level, the probability of an out-of-stock event before the next delivery arrives and the recommended order volume are calculated.
5. Filter and prioritization. SKUs with a high stockout probability and significant margin or turnover are selected for the alert. The rest are logged without notifications to avoid noise.
6. Notification. The alert is sent to the communications channel with a list of SKUs, reasons, a recommendation, and a deadline for action.
7. Feedback loop. Buyer decisions (ordered / deferred / ignored) are logged and used to calibrate thresholds and for model recalibration.

Solution components

Implementation steps

1. Data audit in the data warehouse: completeness of sales history, stock synchronization, SKU reference.
2. Development of a baseline model on a sample of SKUs (A-category by turnover) with retrospective validation on historical data.
3. Configuring the pipeline and scheduler, moving parameters (thresholds, horizon, lead time) to a config.
4. Integration with the communications channel and agreement on the alert format with the procurement team.
5. A 2–3 week pilot: comparing forecasts with actuals, calibrating thresholds, and collecting feedback from buyers.
6. Scaling to the full catalog and establishing a feedback loop for continuous improvement.

The model does not replace planning — it gives the team early visibility into shortage risk and data for decision-making. Forecast accuracy depends on the quality of input data: with dirty stock levels or a short history, the effect will be lower.

To launch stockout prediction, Grow2.ai requires prepared data and team readiness to work with forecasts rather than post-factum reports.

Data and access

• Data warehouse or BI layer with a sales history of at least 6 months (preferably 12+ for annual seasonality).
• Current stock levels by SKU, synchronized with the warehouse or ERP at least once per day.
• SKU reference with categories, suppliers, and lead time.
• Procurement parameters: minimum order quantities, delivery lead times, safety stock by category.
• Communications channel (Slack, email, or Telegram) for sending alerts with API access.

Team readiness

• A process owner from the procurement side — makes decisions on alerts and provides feedback to the model.
• A tech lead or analyst for pipeline setup and work with the warehouse.
• An agreed alert format and SLA for response (for example: alert received in the morning — decision by end of day).
• A policy for handling false positive / false negative cases: who updates thresholds and how.

Timelines

For a simple case with clean data, implementation takes 2-4 weeks:

1. Week 1: data audit, baseline model, retro-validation.
2. Week 2: pipeline, scheduler, integration with communications.
3. Week 3-4: pilot, threshold calibration, scaling to the catalog.

If the sales history is fragmented, stock levels are out of sync, or tens of thousands of SKUs with a long tail need to be covered — timelines grow to 6-10 weeks, and the solution moves into the medium category.