From Having Data to Using It
Most fleet operators collect more data than they use. Telematics devices send GPS updates every 30 seconds. Chargers record session start, session end, and energy used. Drivers report completed trips in a chat app or dispatch console. Yet these sources rarely connect automatically. A coordinator sees a vehicle at 41 percent SoC, knows three trips are waiting, and decides based on experience and instinct.
That is not data-led operations. It is experience beside disconnected information. The difference matters because EVs face a constraint ICE vehicles do not: running out of range mid-shift can cost more than the trip earned.
Which Decisions Benefit Most from Data
Not every fleet decision requires a model. Driver complaints and afternoon coordinator assignments still call for judgment. But three EV fleet decisions contain more information than instinct can reliably handle:
- Charging timing. PLN time-of-use tariffs create predictable cost windows. Charging between 22:00 and 06:00 costs significantly less than charging during peak hours. Every vehicle that plugs in at 18:00 because a driver finished early is a direct cost that a simple rule could have prevented.
- Trip assignment by battery state. Sending a vehicle on a 35-km Soekarno-Hatta airport run when it is at 28 percent SoC and has no confirmed depot slot afterward is a dispatch error. It looks fine until the driver is stranded at a charger during morning peak.
- Readiness at morning peak. Jakarta ride-hailing demand spikes sharply at 07:00. If a fleet coordinator does not know at 06:30 which vehicles finished charging and which are still on AC power, the first hour of peak is reactive rather than planned.
Data cannot remove uncertainty from these decisions. It can, however, reduce preventable mistakes.
The Minimum Viable Data Stack
You can begin making better decisions without a dedicated analytics platform. Based on early pilot work with a small Jakarta fleet, the most useful inputs are:
- Battery SoC at end of each trip, with timestamp and vehicle ID
- Charging session records: plug-in time, plug-out time, energy delivered in kWh, charger identifier
- Trip completion records: requested pickup time, actual departure time, zone, estimated distance
- Charger availability status: which ports are in use, which are faulted, which are free
Most operators hold the first three inputs somewhere across two or three disconnected systems. Data-led operations begin when those inputs become one timeline for each vehicle, even if the first version is a weekly spreadsheet review.
A Practical SoC Threshold Rule
In an early-access pilot involving fewer than 15 vehicles in South Jakarta, the first measurable improvement came from a rule, not an algorithm: do not dispatch a vehicle on a trip longer than 20 km when SoC is below 40 percent, unless a specific charger with a confirmed open slot is on the return route.
Before the rule, trip refusals and mid-shift charging detours happened regularly. The coordinator understood that low-battery vehicles should generally avoid long trips. Under time pressure, though, that knowledge was unreliable without a defined threshold and confirmed backup charger.
The rule needed no sophisticated model. It connected three data points already available in telematics and charger logs and made them visible at dispatch. Charging detour incidents fell across the pilot group during the period tracked.
Where Models Add Value Beyond Rules
Rules suit relatively fixed decisions. Jakarta ride-hailing demand is not fixed. Thursday evening pickups around Kuningan office towers differ from Saturday evening demand near Kemang restaurants. A vehicle sent to the right zone at the right time using a learned demand pattern can complete more trips per shift than one sent to the nearest request.
A demand-aware model adds context rather than replacing rules. Charging schedule optimization works similarly. A fixed overnight rule may suit a normal Tuesday, while the Tuesday before a public holiday may need a schedule that considers higher pre-holiday demand, changed trip durations, availability needs, and tariff windows.
The Harder Part
Data quality declines faster than expected. An intermittently failing telematics device creates SoC gaps. A charger firmware update that changes session-log formatting can break the parser. A driver who fails to plug in correctly may create a failed session that appears complete.
That does not make the data approach un worthwhile. Evidence from our early-access cohort strongly supports it. But software does not fix poor data quality by itself. It can flag anomalies, while a person still needs to investigate them.
Start with data discipline before optimization. Consistent end-of-trip SoC reports, verified plug-in procedures, and dependable charger connections are prerequisites, not extras. Optimization built on noisy inputs simply optimizes noise.
Begin the Transition
Start by finding the costliest recurring error in current operations and asking which data could prevent it. For most small Jakarta EV fleets, that error is dispatching without knowing the vehicle's actual battery state. Recording SoC at dispatch creates visible results sooner than a broader initiative.
At RideBlitz, we built the data collection layer before the scheduling model. Fleets that reversed that order got unreliable outputs from a more capable optimizer because their inputs were inconsistent. A model is only as trustworthy as the data feeding it.
