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 out of stock. The model accounts for sales history, seasonality, and current inventory levels, and when the stockout probability exceeds the 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 with the current stock level and calculates the probability of a stockout before 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 in order to gradually adjust thresholds and improve the model over time.
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 inventory 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 from 'the item is out of stock' to 'the item will run out 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 suitable 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 produces a noticeable effect after just 2-3 order cycles.

The technical solution is a pipeline built on custom code (most commonly Python) that connects to the data warehouse, calculates 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 pulls sales for the relevant period, current stock levels, and the SKU reference.
2. Feature engineering. Rolling sales averages per SKU, weekly and annual seasonality, trend, and turnover rate are calculated. The supplier's lead time — from the moment of ordering to goods arriving at the warehouse — is taken into account.
3. Forecast model. Expected consumption is calculated for each SKU over the horizon to 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, the probability of an out-of-stock 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 generating 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. The buyer's decisions (ordered / deferred / ignored) are logged and used for threshold calibration and 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 back-validation on historical data.
3. Pipeline and scheduler setup, extracting parameters (thresholds, horizon, lead time) into 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 reality, threshold calibration, 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 advance 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 at least 6 months of sales history (preferably 12+ for annual seasonality).
• Current stock levels by SKU, synchronized with the warehouse or ERP at least once per day.
• SKU directory 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 procurement process owner — makes decisions on alerts and provides feedback to the model.
• A tech lead or analyst for pipeline setup and warehouse operations.
• An agreed alert format and response SLA (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.

Timeline

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

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

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.