AI-Driven Inventory Monitoring and Reorder Automation

The problem

A product company with 200 SKUs was managing inventory using gut instinct and weekly manual counts. Stockouts of popular items were common. Slow-moving inventory was tying up working capital.

Context

Consumer goods companies at the 200-SKU scale sit in a difficult middle zone for inventory management. They are too large to manage stock intuitively, but too small or too niche to be well-served by enterprise inventory platforms that require months of implementation and dedicated IT support. The typical pattern is a spreadsheet-based reorder system that started as a reasonable approach and became increasingly fragile as the SKU count and sales volume grew. Weekly manual counts introduce lag. Static reorder points set months ago do not account for seasonality or demand shifts. And the operations team is usually the same people handling logistics, supplier relationships, and warehouse operations - there is rarely dedicated inventory planning capacity.

In this case, the company had 200 SKUs across four product categories, with their top 20 items accounting for roughly 80% of revenue. Those top 20 SKUs had the worst stockout history precisely because demand spikes hit them hardest. They had tried a third-party inventory management tool the previous year, but it lacked a viable integration with their Lightspeed POS system and required manual data exports to sync. After two months of trying to make it work, they abandoned it and returned to spreadsheets. The combination of high-velocity SKUs, variable supplier lead times, and no real-time sales data connection was costing them in both directions: lost revenue from stockouts and working capital tied up in slow-moving lines.

What we built

Technical approach

The core of the system is a Python inventory intelligence layer that connects to Lightspeed via their REST API, pulling sales transaction data in near-real time. This was the integration the previous third-party tool had failed to provide, and it was the prerequisite for everything else - without live sales data, demand forecasting is guesswork. The machine learning model calculates demand velocity per SKU using a rolling weighted average that gives more weight to recent sales while preserving enough history to detect seasonal patterns.

Reorder point calculation factors in current stock level, average daily demand velocity, supplier lead time, and a safety stock buffer calibrated per SKU based on demand variability. SKUs with consistent demand get a tighter safety stock; SKUs with volatile demand get a larger buffer. Supplier lead times are sourced from actual delivery history rather than stated lead times - we built a delivery tracking component that updates lead time estimates each time an order is received, based on the gap between order date and actual delivery date. For suppliers with API-connected portals, purchase orders are submitted automatically on threshold breach. For suppliers who do not have portal APIs, the system generates a formatted email draft for the operations manager to review and send. This hybrid approach meant the automation covered the full supplier base from day one rather than only the technically accessible ones.

The automation timeline

Challenges and how we solved them

The most important engineering challenge was supplier lead time data. The company had lead times recorded in their spreadsheet for each supplier, but these were the stated lead times provided when the supplier relationships were first established - in some cases two or three years prior. Actual delivery performance had diverged significantly. One key supplier had a stated lead time of five days but was consistently delivering in eight to nine days. Using the stated lead time would have continued producing stockouts even with automated reordering. The delivery history tracker solved this by building an empirical lead time estimate from actual receipts.

The second challenge was handling promotions and seasonal events. The demand velocity model needed to distinguish between a genuine sustained increase in demand and a temporary spike driven by a promotion or seasonal event. Treating a promotional spike as a new baseline would cause overordering once the promotion ended. We added a promotion flag field that the operations team could mark when running a promotion, which signals the model to isolate that period from the baseline velocity calculation. It is a simple manual step, but it prevents the model from being corrupted by transient demand patterns.

Results

Stockouts on key SKUs dropped by 68% in the first quarter. Carrying costs reduced by 22%. The operations team now spends time on supplier relationships rather than stock counting.

The change in how the operations team works has been as significant as the inventory metrics themselves. The two people who previously spent most of their Monday mornings doing manual stock counts and chasing purchase orders now spend that time on supplier relationship development and category planning. In the first two quarters post-launch, the company renegotiated two supplier contracts with better pricing and payment terms - work that had been deprioritized because there had never been time for it. The system also revealed that four slow-moving SKUs were consuming disproportionate working capital without generating meaningful revenue, giving the team the data they needed to make a discontinuation decision they had been deferring for months.

Key learning

Inventory automation is only as good as its lead time data. Most companies use stated lead times from their supplier agreements; we use actual delivery history. The difference is significant for high-velocity SKUs where a few extra days of lead time can mean the difference between a reorder arriving before or after a stockout. If you are considering inventory automation and your lead time data is more than six months old or has never been validated against actual delivery records, that is the first thing to fix. The forecasting model is the visible part. The data quality underneath it is what determines whether the model actually works.