AI carsharing: where the balance of demand and cars breaks down
Fleet imbalance in carsharing is visible in two pictures at once: on the outskirts and in low-tariff zones, cars sit idle for hours, while in business districts and at transport hubs during the morning peak there is no available car within the dispatch radius.
This is not a seasonal anomaly, but a consequence of the fleet distribution being set statically, while demand shifts constantly.
Peak demand has direction. In the morning the flow goes from residential areas to office centers, in the evening back, and this vector changes with day of week and weather.
According to urban mobility research, demand shift between zones within an hour can exceed the daily supply of cars at the hottest point — a manual relocation driver schedule is built a day ahead and physically cannot keep up: by the time a car has reached the deficit zone, the peak is already over.
Manual rebalancing has its own cost. Rebalancing deadhead mileage is kilometers, fuel, and paid shift hours, and the car itself is unavailable for booking during the transfer: it is listed in the system, but the client cannot take it. The share of idle vehicles grows, fleet utilization falls, and some requests are lost irrevocably.
We break down how short-horizon demand forecasting by zone and AI-driven rebalancing planning close this gap — from data preparation to daily operation.
AI carsharing: fleet utilization and deadhead mileage after implementation
Demand forecast is built by zones and half-hour intervals: the model learns from order history, city calendar, weather, and events and is retrained on a rolling window.
Accuracy is calculated for each zone separately, not averaged across the fleet — an error in a deficit district turns into a cancellation, not extra minutes of waiting.
Distribution of cars between zones is handled by the OR-Tools optimizer: the formulation accounts for probabilistic demand over a horizon of up to an hour, travel time, driver availability, and the cost of a missed order.
A transfer is launched only when the expected increase in completed orders outweighs the deadhead mileage; otherwise the car stays in place.
After implementation, the metrics by which the fleet is evaluated shift. Vehicle utilization — the share of time when a car is fulfilling an order or driving to a client — rises from 40–50% to 60–65%.
Idle time in deficit zones is reduced by about half, the share of cancellations due to "no car nearby" falls by 30–40%, and the fleet utilization coefficient grows without purchasing new cars.
Rebalancing deadhead mileage falls by a quarter to a third with the same number of relocations: the optimizer trades long transfers for short ones and rejects movements that do not pay off in demand.
A side effect is more even wear and less frequent unscheduled maintenance, because empty mileage becomes lower.
The stability of the numbers is checked before rollout: a retro run on historical slices, a shadow mode where the forecast is calculated but transfers are not performed, then phased launch by zone with rollback to previous rules within the day.
Demand forecasting options: comparison of approaches
The choice of approach is determined by forecast horizon, volume of accumulated history, and cost of error. Simple rebalancing rules are thresholds on the number of available cars in a zone per hourly slot: if not enough, we bring them from a neighboring zone.
They work from day one and without data, but do not know about rain, a concert, or a one-time surge in demand near a business center.
History-based forecasting — demand profiles by zones and hours, moving average, seasonal coefficients: it captures the weekly rhythm and holidays, but breaks on anomalies and in new zones where there is no history.
Training on telematics data adds external features — weather, city events, road congestion — and calculates a forecast for each zone separately, but requires monitoring forecast deviation from fact.
| Approach | When it fits | What is missing |
|---|---|---|
| Threshold rules | One or two zones, stable demand, launch from scratch | External factors and one-time surges |
| History-based statistics | Regular weekly cycle, data accumulated over several seasons | Reaction to anomalous days, works only where there is history |
| Telematics-based training | Dozens of zones, heterogeneous demand, external features available | Data on rare events, forecast quality control needed |
| Hybrid: model plus rules | Need both accuracy and predictability of rebalancing | More setup: rules constrain the model during peak hours |
Before implementation, we run each option on a held-out segment of history and look at in what share of zones the forecast missed actual demand — this determines the choice.
Implementation stages: from data audit to handover to operation
Audit of telematics data almost always changes the work plan: logs contain gaps in tracks, different time zones for fleet vehicles, "stuck" occupancy and trip statuses, and trips closed by tariff rather than by fact.
Until these artifacts are sorted out, the model learns on noise — the error in the report is small, but in the city cars are missing exactly where demand has grown. Therefore the steps are arranged so that each next one relies on the verified result of the previous one.
- Telematics data audit — we check track completeness, status correctness, time zones, and trip-to-tariff linkage; the output is a list of zones and periods where data is suitable for training.
- Feature preparation — we aggregate demand into 15–30 minute windows and by zone, add calendar, weather, events, and load history so the model sees the cause of growth, not just the fact itself.
- Model setup — we train demand forecast for a horizon from an hour to a day, separately for weekdays, weekends, and anomalous days, with robustness checks for missing data.
- Rebalancing calibration — we turn the forecast into decisions: how many cars and where to relocate, with constraints on mileage, zones, and delivery time, so the prompts are actionable.
- Model validation on history — we run decisions on past periods and compare with how the fleet actually operated: forecast error, share of unserved demand, empty mileage.
- Handover to operation — we fix the retraining schedule, forecast quality monitoring, and screens understandable to the dispatcher; then the customer's team changes thresholds and zones themselves.
Configurations, rebalancing rules, and regulations
We hand over not only the forecasting service but the entire operational loop around it — so that the duty shift can act without us. Each artifact has an owner: the analyst edits weights, the dispatcher launches a transfer, the engineer changes thresholds.
- Data flow diagrams: vehicle telematics and booking history to training marts — with quality control points and arrival delays.
- Forecast service configuration: horizon, recalculation step, minimum history for a new zone, confidence threshold below which the forecast is not put into operation.
- Zone priority rules: airports, business districts, residential areas, train stations — coefficients and the schedule by which priority changes during the day.
- Rebalancing regulations: who launches a transfer, what constraints on mileage and charge level are taken into account, how cancellation of a manual assignment is recorded.
- Duty and escalation regulations: signal levels, response time, procedure for switching to manual distribution when the forecast diverges from fact.
- Model documentation: features, quality metrics, applicability boundaries, change log with author and reason for parameter edits.
- Shift memos: short scenarios for morning, peak, and night, analysis of typical incidents, procedure for actions if the forecasting service fails.
Artifacts sit next to the configuration and are updated by the same change — there is nowhere for a discrepancy between documentation and the running service to come from.
Case: fleet deadhead mileage and idle time before and after
A fleet of several hundred cars was rebalanced along fixed routes, relying on the previous day's report.
By the evening peak, cars ran out in residential areas and idled near the business center, while the deficit in the zone was closed an hour or an hour and a half later, when demand had already fallen. The extra transfer added mileage and often ended without an order.
We implemented hourly demand forecasting by zone for 2–4 hours ahead: the model on LightGBM accounts for history by day of week, weather, city events, and road closures.
Based on it, the distribution of cars between zones was calculated as a problem of minimizing total deadhead mileage while covering forecast demand — with a hard limit on transfer length.
Metrics before and after
| Fleet operation metric | Before | After |
|---|---|---|
| Share of completed orders at peak | 78 % | 94 % |
| Deadhead mileage per transfer | 11.4 km | 7.6 km |
| Response time to zone deficit | 55 min | 18 min |
| Trips per car per day | 5.1 | 6.4 |
We keep the rebalancing result under daily control: deviation of fact from forecast by each zone, share of transfers without a subsequent order, response time to a demand surge.
If forecast error exceeds the threshold, the schedule returns as a fallback mode, and the model is retrained on a fresh data window.
What to do if telematics already exists but there is not enough data for the model?
Yes, a start is possible: the demand model does not require years of history. Records with timestamps, occupancy status, trip start and end markers, and charge level are enough — that is sufficient to reconstruct the daily demand profile by zone.
The difficulty of incomplete telematics is not in volume but in heterogeneity: different polling intervals, gaps in tracks, lost status change events.
Therefore the first step is data quality analysis: share of gaps for each field, share of outliers, how many cars are silent longer than usual. What does not pass the threshold is fixed at the source or excluded from calculation.
The minimum feature set at the start: zone, hour of day, day of week, day type, weather, availability of cars within radius. Rare events — airport returns, one-time events — are not pulled from history but set by rules and the calendar while there is no data for their statistics.
Without its own history, the model is trained on a neighboring fleet or city with a similar profile, then fine-tuned locally on its own stream — transfer is reliable on stable patterns of morning, evening, and weekends and weaker on local anomalies, which are covered by rules.
Expansion proceeds in stages: forecasting by zones and hours, then rebalancing taking into account routes and delivery time, then personalization of offers.
This way rebalancing is launched without waiting for full telematics coverage: coverage grows together with model accuracy rather than blocking the start.
Technical doubts: accuracy, integrations, support
Before starting, customers ask the same questions: what accuracy to expect, how the solution will integrate with the booking system, and who is responsible for the model six months after launch. We answer substantively, without generalities.
What forecast accuracy is considered sufficient?
The benchmark is benefit for rebalancing, not a beautiful number: fewer hours of car deficit in demand zones and without inflated surplus in calm areas. The baseline and threshold are calculated on historical data before launch, separately for each horizon — hour, day, week. Accuracy at one hour and at one day differs by factors, so it is not described by a single number.
How does the forecast integrate with the booking system?
The model does not replace the booking system and does not write to it directly: it reads depersonalized rental events — starts, returns, cancellations — and provides rebalancing recommendations through a software interface.
The dispatcher sees them in their workstation; the usual booking scenarios do not change. If the forecast is unavailable, the system continues to operate as before.
Who supports the model after launch?
Support is included in the work: we monitor forecast quality across all horizons and catch drift when tariffs, fleet composition, or city infrastructure change.
When metrics go beyond the threshold, we update the model and return it to service — a separate contract for each failure is not needed.
How often is retraining needed?
According to data, not the calendar: regularly — on a fresh slice of history; unscheduled — when new zones appear, the fleet changes, or pricing rules change.
Feature assembly, training, and validation on a held-out period run automatically; a person only approves the release of a new version.
Let's discuss the task: forecast requirements and work plan
So that the estimate of the scope of work is based on facts, not assumptions, we need a snapshot of your current fleet situation. Nothing exotic is required — as a rule, the team that operates carsharing already has all of this; it is enough to export and send it.
- Depersonalized trip data for several months: start and end time, start and end zones, tariff type; personal data is not needed, identifiers are enough.
- List of zones and their delineation rules — how demand districts are currently defined and where the boundary between them runs.
- Current rebalancing rules: by what thresholds cars are relocated manually, who makes the decision, and how often.
- Fleet and logistics constraints — how many cars are available and how many relocations per day can realistically be performed by drivers.
- Priorities: what is more important — demand coverage during peak hours, reducing idle time, or keeping cars in high-interest zones.
- Data access scheme: where exports live, in what format it is convenient to provide them, and whether there are restrictions on processing outside your environment.
In response, we will return a demand forecasting problem statement with horizon and target metric, an estimate of the scope of work by stages, an implementation plan with checkpoints, and a list of what will be required from your side.
If there is little or incomplete data, we will say so immediately and suggest how to assemble the minimum set for the first version.
Describe the task — we will get back with an estimate and plan.
