The Problem
Capacity planning was running on gut feel and spreadsheets
Before the control tower, demand planning at Amazon's quick commerce operation was a manually intensive, market-by-market exercise. Each market had its own approach — some using statistical models, some using historical averages, some running purely on operations manager intuition.
The compounding problem: quick commerce is uniquely hard to forecast. Unlike standard e-commerce where demand curves are relatively smooth, same-day delivery demand spikes sharply around meal times, weather events, local holidays, and even sports matches. A model calibrated on weekly averages is systematically wrong at hourly granularity.
The consequence of under-forecasting: capacity constraints during peak windows, SLA misses, driver shortages. The consequence of over-forecasting: idle capacity, inflated cost base. Both were happening, in different markets, on the same day.
The Model
4-week horizon, hourly granularity — the signals that matter
The forecasting architecture I built combines four signal classes, weighted differently for each market based on the dominant demand drivers:
Signal 01
Historical demand patterns
Hourly order volumes from the past 52 weeks, seasonality-adjusted and decomposed by day-of-week and time-of-day
Signal 02
External event calendar
Local public holidays, sports events, weather forecasts, and promotional calendars — major demand amplifiers in GCC markets
Signal 03
Real-time capacity state
Live FC throughput, fleet availability, and driver supply — fed back into the forecast to flag when predicted demand exceeds current capacity ceiling
Signal 04
Category-level demand mix
Not just total orders — but the mix of grocery, electronics, and essentials, because different categories have different pick times and weight different bottlenecks
Architecture decision
I pushed for a unified model across all 4 markets rather than separate market-specific models. The counterargument — market differences would reduce unified model accuracy — was valid. But separate models also mean separate data science resource requirements, separate retraining cycles, and four sets of model drift to monitor. A single platform with market-level feature weighting proved the right balance: 17% accuracy improvement, without the operational overhead of four independent systems.
The Control Tower
From forecast to action — the real-time alert layer
A forecast sitting in a spreadsheet helps no one. The control tower product is the operational layer that turns forecasts into actions:
- Capacity gap alerts: When predicted demand is tracking to exceed FC throughput capacity in the next 2–4 hours, the control tower surfaces an alert to operations — with enough lead time to pull levers (driver surge, order throttling, or manual capacity release)
- Market-level dashboard: Single pane of glass across India, UAE, KSA, and Japan — ops leads can see the full picture in one view, not four separate reports
- Automated S&OP inputs: Weekly forecast outputs automatically populate the capacity planning templates used in S&OP cycles — eliminating the manual extraction that was consuming 6,000+ manager hours annually
- Anomaly flags: When incoming orders deviate significantly from the hourly forecast (up or down), the system surfaces this to ops before it becomes a customer-facing problem
Results
The numbers
- 17% forecast accuracy improvement — measured against the previous market-average-based approach across all 4 markets
- 6,000+ manager hours saved annually — from automated forecast-to-S&OP pipeline replacing manual extraction and reformatting
- Single platform across India, UAE, KSA, Japan — with market-configurable feature weighting and local alert thresholds
- Real-time capacity alert system — giving operations 2–4 hours of lead time to respond to emerging demand/capacity gaps before they hit customers
ML ForecastingS&OPControl TowerReal-time AlertsCapacity PlanningMulti-marketData Products
Related Work
Other projects from this era