Demand prediction for a battery-swap network starts with a question that sounds obvious but turns out to be harder than it appears: where will riders need a charged pack, and when? The "where" part is constrained by the station locations you have. The "when" part is where the prediction problem lives. Get the timing wrong and you end up with charged packs sitting at stations where demand has already passed, and empty stations in corridors where demand is peaking right now.
The approach we have developed in our Pune pilot integrates three categories of signal: GPS-trace-derived corridor patterns, order volume signals from fleet partners, and time-of-day seasonality. None of these alone gives reliable prediction. In combination, they produce a demand curve per station per time window that is useful enough to make staging decisions 20-30 minutes in advance, which is the window that matters for pre-positioning.
GPS Traces: What Rider Movement Tells You
The most direct input to our demand model is rider movement data from BatteryPool app users. When a registered rider has location sharing active, we can observe their GPS trace throughout their shift. This tells us which routes they are running, how far they are from the nearest station at different points in their shift, and their approximate velocity, which indicates whether they are actively delivering or waiting for an order.
Over several months of Pune pilot data, patterns in these traces are remarkably consistent on normal workdays. Riders operating in the Baner corridor during lunch delivery windows follow predictable paths through a relatively small set of road segments. We can identify when a cluster of riders is approaching a demand zone 15-20 minutes before they would typically need a swap, based on where they are in their route and their current battery state as inferred from swap frequency.
The limitation is coverage: GPS trace data only exists for riders who are registered BatteryPool users and have location sharing enabled. New riders, riders from fleets that have not integrated with our API, and riders who disable location sharing are invisible until they actually appear at a station. We compensate for this by weighting historical station swap event data more heavily for corridors where our direct GPS coverage is thin.
Order Volume Signals: The Upstream Indicator
Rider locations tell us where demand is happening now. Order volume signals from fleet partners tell us where demand is about to happen. When a fleet operator's dispatch system shows a surge in orders being assigned for a particular delivery zone 30-45 minutes from now, that is advance notice that the riders assigned those orders will be in that zone, moving toward the station that serves it.
Not all fleet partners share this data. Our Fleet Pro tier includes a REST API integration that enables order volume data sharing if the fleet operator has configured it. For partners who have enabled this, the demand model gains 20-40 minutes of forward visibility that the GPS-trace approach alone cannot provide. For partners who have not, we rely on historical patterns and real-time position data.
The combination matters most during demand surges. A typical lunch peak in a delivery corridor is predictable enough from historical data that GPS-only prediction captures it adequately. An unusual surge, triggered by a flash sale on a delivery platform or a major event driving order volume in a specific area, is not reliably captured by historical patterns. Order volume signals from fleet partners are the layer that gives us early warning for these events.
Time-of-Day Seasonality: The Baseline Prior
In the absence of GPS trace data or order volume signals, the demand model falls back on time-of-day and day-of-week priors derived from accumulated swap event history. Swap demand in Pune delivery corridors shows strong weekly patterns: weekday lunch peaks (11:30am-1:30pm), moderate morning peaks (8:30-10:00am), dinner peaks (7:00-9:00pm), and relative lows in mid-afternoon and overnight.
Weekend patterns differ from weekday patterns in ways that reflect delivery platform order timing. Weekend mornings see lower demand than weekdays; weekend evenings see slightly higher dinner-delivery demand. These patterns are stable enough across months to be useful as a baseline prior, which the real-time signals then update as the day progresses.
The seasonality prior also captures day-specific effects we have observed: the day before a major holiday sees a demand spike as people order ahead; the day of the holiday itself is lower than a normal weekday. These effects are irregular enough that they are not reliably predictable without additional signals, but knowing their general shape helps the model avoid being caught flat-footed on predictable anomaly days.
How the Model Fails and What We Do About It
The demand model fails in predictable ways that are worth being transparent about. New rider corridors that lack historical swap event data have lower prediction accuracy until 4-8 weeks of swap history accumulate. The model starts from a prior based on geographic similarity to existing corridors, but this is a rough approximation. Fleet operators whose routes run through newer coverage areas should expect some variability in station availability during the ramp-up period.
The model also fails during multi-factor simultaneous anomalies: heavy rain on a day that is already a platform promotion day, for instance, creates competing effects on rider behavior that the model cannot cleanly decompose. Worse, these events interact differently in different corridors. We have not solved this fully; our current approach is to widen the staging buffer during high-uncertainty periods, keeping more inventory at more stations than the point estimate would suggest is needed.
What This Looks Like for a Fleet Operator
From a fleet operator's perspective, the demand prediction machinery is mostly invisible. The visible outcome is that your riders arrive at a station and find a charged pack ready rather than arriving to find the station empty. On days when the model works well, this happens reliably. On days when it does not, riders may occasionally find a station that has run ahead of our restocking cycle.
The Fleet Pro tier's real-time analytics dashboard surfaces some of the underlying model state: predicted demand by station for the next two hours, current inventory levels, and any alerts on stations that are approaching low-inventory thresholds. For fleet managers who want visibility into network state before dispatching riders to a corridor, this is the tool that lets them make informed routing decisions rather than discovering availability gaps at the station itself.