How ARS Manages ₹100Cr+ Inventory with AI

Manual inventory management doesn't scale. When you're operating 90+ dark stores across 30+ cities with thousands of SKUs, the gap between 'good enough' and 'optimized' is worth crores. This is the story of ARS — the Autonomous Replenishment System we built to close that gap.

The Problem

A leading quick-commerce player was managing inventory manually across 90+ dark stores. Each store had 2,000+ SKUs. Demand varied by location, day of week, season, and local events. The existing process:

• ▸Store managers estimated demand based on gut feel
• ▸Reorder decisions were reactive — triggered by stockouts, not predictions
• ▸No cross-store coordination (one store overstocked while the next was out)
• ▸₹100Cr+ in inventory at risk of waste, stockouts, and suboptimal allocation

The Scale

What We Built

ML-Driven Demand Forecasting

The core engine: a demand forecasting model that predicts SKU-level demand for each store, each day, for the next 7-14 days. We trained on 18+ months of historical sales data, incorporating:

• ▸Day-of-week and seasonal patterns
• ▸Local event calendars (festivals, sports, weather)
• ▸Price elasticity signals
• ▸Promotional calendar effects
• ▸Competitor activity indicators

Automated Reorder Triggers

Based on demand forecasts, safety stock levels, and supplier lead times, the system automatically generates purchase orders. No human intervention for the 90% of routine reorders. Humans review exceptions — new SKUs, unusual demand spikes, supplier issues.

SKU-Level Optimization

Not all SKUs are equal. The system classifies SKUs by velocity, margin, and perishability — then optimizes inventory levels differently for each class. High-velocity staples get thin safety stock (quick replenishment). High-margin slow-movers get strategic allocation based on local demand patterns.

Multi-Store Coordination

The system sees all stores simultaneously. When one store is overstocked and another is trending toward stockout, it can trigger inter-store transfers before a customer is affected. This network-level optimization is impossible to do manually at 90+ stores.

Results

Technical Approach

The system architecture follows a standard ML production pipeline:

• ▸Data pipeline: Ingests POS data, inventory levels, and external signals daily
• ▸Feature engineering: 200+ features per SKU-store combination
• ▸Model: Gradient boosted trees (LightGBM) — chose for interpretability and fast inference at scale
• ▸Serving: Batch predictions generated nightly, cached for API serving
• ▸Monitoring: Drift detection on prediction accuracy, automatic retraining triggers

Lessons Learned

• ▸Start simple. Our first model used 20 features. The production model uses 200+. But the first version shipped faster and proved the concept.
• ▸Humans in the loop matter. Store managers know things the model doesn't — local construction, competitor openings, neighborhood events. We built an override mechanism that feeds back into the model.
• ▸Data quality is the bottleneck. The model is only as good as the POS data. We spent 30% of our time on data pipeline reliability.