Comparing Taxi Dispatch Software for EV Fleet Operations: Side-by-Side

The most uncomfortable truth about EV taxi fleets: almost all dispatch software was built for petrol or diesel cars or, to an extent, for CNG cars, and that had EV features bolted on later. In taxi dispatch software, the scheduling logic assumes a driver can refuel in four minutes anywhere, but that is not the case for EVs; they can't, and when a dispatch engine supposedly assigns a 28-kilometre airport run to a vehicle sitting at 14% state of charge, that's not just lose one ride but the loss of the vehicle for the next ninety minutes.

This comparison is for operators at the evaluation stage. You've decided EVs are the fleet. You're now choosing the software layer that decides which car gets which job. The parameters below are the ones that actually separate platforms, and the differences are larger than any feature grid that any vendor showcases in a demo.

What Actually Changes When Your Fleet Goes Electric

Before comparing products, it's worth understanding the pragmatic operational shifts because they're what the software has to absorb eventually.

Refuelling Becomes a Scheduled Event, Not an Errand:

A diesel or petrol driver can refuel their vehicle when convenient. An EV driver can't do that; he charges when the dispatch system permits it, at a charger that is available, on a route that doesn't strand them. Charging is now an operational job that the dispatch system assigns.

Vehicle Capacity is Time-Variable:

A petrol taxi is either on shift or off. An EV is on shift at 100%, at 60%, at 22% - and each of those is a functionally different vehicle with different accepted job types.

Range is Not a Number, It's a Distribution:

Manufacturer range is a lab figure. Real range shifts with ambient temperature, HVAC load, passenger weight, traffic profile, and battery age. A dispatch system that treats "280 km range" as a constant will strand vehicles in January.

The Charger is a Shared, Contended Resource:

Two vehicles, one DC fast charger, both at 15%. Somebody has to arbitrate. In most fleets today, somebody is a human on WhatsApp.

Total Cost of Ownership Moves From Fuel Spend to Energy Arbitrage:

Charging at 2 AM off-peak versus 6 PM peak can differ by 3-5x per kWh in many markets. Dispatch software that ignores tariff windows is silently burning margin.

Any platform that doesn't have an explicit answer to all five is not an EV dispatch system. It's a dispatch system that runs on EVs.

The Six Parameters That Separate EV Dispatch Platforms

Here is an actual comparison framework for an EV dispatch software. Each parameter here is scored on what the software must actually do, and not just on bogus claims.

1. Battery Telemetry Integration

What separates tiers:

How to Test It in a Demo: 

Ask the vendor to show a live SoC for a vehicle currently on the road, and ask what the polling interval is. Then ask what happens when the OEM API rate-limits them. Real answers exist. Vague answers mean the integration is a driver-app checkbox.

Mixed-fleet reality: 

Most EV taxi fleets are not single-marque. A platform with a Tesla integration and nothing else is a platform with no integration, because your BYD e6s and Kia Niros will fall back to manual entry, and manual entry poisons the dispatch logic for the whole fleet.

2. Charge-Aware Dispatch Logic

This is the single highest-leverage differentiator, and where most platforms are thinnest (larger claims than actual work)

The naive model: Dispatch assigns the nearest available vehicle. SoC is checked as a hard filter - below X%, the vehicle is marked as unavailable. This is what "EV support" means at most vendors.

Why it fails: A hard threshold treats a 5-km job and a 60-km job identically. It takes a vehicle offline entirely at 30% when it could profitably run six short city hops. It also creates a stampede: every vehicle hits the threshold, every vehicle seeks a charger, at the same hour.

The Competent Model - Job-to-SoC Matching:

The dispatch engine calculates, for each candidate vehicle and each job:

• Energy required for pickup leg (distance + traffic + gradient)
• Energy required for the fare leg
• Energy required to reach the nearest available charger from the drop-off point
• A reserve buffer, dynamically sized by temperature and battery age

If current_SoC > (pickup + fare + repositioning + buffer), the vehicle is eligible. Otherwise, it won't be considered compatible with that job, not for all jobs.

The Advanced Model - Charge Scheduling as Dispatch:

The engine treats "go charge at Charger 2, arrive 14:20, charge to 80%, resume at 16:05" as a job it assigns, competing against fare jobs on an economic basis. It knows the charger is free at 17:20 because it holds a reservation graph. It knows the tariff at 17:20. It knows that vehicle 17's next likely job zone is near Charger 2.

How To Test It: 

Give the vendor this use case. "It's 18:40. Airport demand is spiking. I have four vehicles between 22% and 31% SoC. My two DC chargers are both occupied with 20 minutes remaining. What does your system do?"

Listen for whether the answer involves the software making a decision or the software showing a dashboard to a human who makes the decision. Both are valid products, but not the same product; also, they are not the same price.

3. Range Estimation Under Real Conditions

What most systems do: remaining_range = SoC% × rated_range

Why this is dangerous: In cold weather with cabin heating, real-world consumption on a taxi duty cycle can exceed rated figures by a wide margin. Fleets in cold climates routinely report winter range materially below the summer figure for the same vehicle. A linear model will dispatch a vehicle onto a job it cannot finish, and it will do this most often on the coldest, busiest, most expensive nights of the year.

What to look for:

• Consumption learning per vehicle. Does the platform build a per-VIN kWh/km model from actual trip history, or does it use a fleet-wide constant?
• Temperature compensation. Does it ingest a weather feed and adjust the buffer?
• Battery degradation tracking. A three-year-old taxi battery with high DC-fast-charge cycling does not have its nameplate capacity. Does the system know that, or is it still using the spec sheet?
• HVAC and load awareness. Higher-tier platforms adjust for passenger count and cabin conditioning.
• Terrain/gradient. Matters enormously in hill-heavy service areas. Ignored by most.

Ask the vendor:

"Show me the kWh-per-kilometre curve for one specific vehicle in your fleet, over the last ninety days, segmented by ambient temperature." If they can produce it, the model is real. If they show you a manufacturer's spec, it isn't.

4. Charging Infrastructure Orchestration

Depot charging vs. public charging are different problems, and platforms tend to solve one well.

Depot-centric platforms assume your vehicles return to a facility you control. They excel at:

• Load balancing across the site's electrical capacity (critical - a 12-bay depot rarely has grid capacity to fast-charge 12 vehicles simultaneously)
• Queue scheduling overnight against time-of-use tariffs.
• Demand-charge management (avoiding the peak-kW spike that dominates commercial electricity bills)

Public-charging-centric platforms assume distributed operations. They excel at:

• Live charger availability via network APIs
• Charger reservation and hold
• Cost-per-kWh routing across competing networks
• Reliability scoring - routing away from chargers with high recent failure rates

Questions that expose the gap:

• Does the system reserve a charger, or tell the driver a charger was free when they were dispatched? (Real-world outcome: driver arrives, bay is taken, ninety minutes lost.)
• Does it model depot electrical capacity as a constraint? What happens when eight vehicles return simultaneously?
• Does it handle charger failure, the dead unit, the ICE'd bay, the connector that won't handshake? Is there a driver-reported feedback loop that updates the routing graph?
• Does it support OCPP 1.6/2.0.1 for direct charger control, or only read-only network status?

Demand-charge management deserves its own emphasis. In many commercial tariffs, a single 15-minute peak sets the demand charge for the entire billing month. A depot that lets six vehicles start fast-charging at 18:00 can pay for that mistake for thirty days. Software that staggers charge starts and throttles charge rates against a site kW ceiling saves money invisibly and continuously.

5. Driver Experience and Range Anxiety

An operational point that gets undervalued: the driver is the failure mode.

A driver who doesn't trust the dispatch system's range calculation will:

• Refuse long jobs at moderate SoC
• Charge earlier and longer than necessary
• Sit at chargers "topping up" during peak demand
• Under-report SoC to avoid airport runs

Each behaviour destroys utilisation. Your expensive charge-aware dispatch engine is only as good as the driver's willingness to accept its output.

What to evaluate in the driver app:

• Does it show the reasoning? "You have 34%; this job needs 19%, including your route to the charger at Sector 18" builds trust. A bare "ACCEPT?" prompt does not.
• Is the charging stop pre-planned and visible? Drivers accept long jobs when they can see the charger is booked at the far end.
• Is charging time compensated or credited? Not a software feature, but the software must support whatever policy you adopt: idle-time crediting, charging-shift pay, utilisation-adjusted commission. Platforms with no configurable pay logic force you into a spreadsheet.
• Language, offline behaviour, and low-bandwidth handling. Dispatch apps that assume 4G in a basement parking structure fail exactly where charging happens.

6. Reporting, Compliance, and Unit Economics

EV fleets have a reporting surface that petrol fleets don't.

Cost-per-kilometre, done properly, requires the platform to know: kWh consumed per trip, tariff at time of charge, charging losses (AC/DC efficiency differs meaningfully), battery degradation amortisation, and idle-charging opportunity cost. Most platforms report kWh and stop.

Emissions reporting is increasingly contractual, not optional. Corporate accounts, airport concessions, and municipal licences increasingly require grams-CO₂-per-passenger-kilometre with grid-mix accounting. A platform that reports "zero emissions" because the tailpipe is absent will not survive a corporate ESG audit. Look for grid carbon-intensity ingestion, at least at a regional-average level.

Utilization metrics that matter for EVs:

• Revenue hours vs. charging hours vs. idle hours (three categories, not two)
• Charge-session efficiency (kWh delivered / bay-hours occupied)
• Dead-heading kilometres to charge
• SoC distribution at shift start, as a fleet histogram

That last one is the single most diagnostic chart in an EV taxi fleet. If your fleet starts the evening peak with a fat left tail, your overnight scheduling is broken, and no amount of clever dispatch will recover it.

Side-by-Side: The Comparison Matrix

Rather than name vendors - pricing, features, and regional availability shift constantly, and a named grid published today is wrong within two quarters. Use this to score any platform you evaluate.

How To Use This: 

Score each platform 1/2/3 on the basis of all eight rows. Then weight by your constraint. If you have abundant depot charging and a short average trip distance, Row 4 barely matters, and Row 2 barely matters; you can buy Tier 1 and be fine. If you have scarce public charging and airport contracts, Rows 2, 3, and 4 are the entire decision, and Tier 1 will cost you more in stranded vehicles per quarter than Tier 3 costs in licence fees per year.

Queries to Ask Every Vendor You Will Have a Demo With

Bring these to the demo. They are ordered by how quickly they reveal the truth.

1. Show me the live state of charge for a moving vehicle, right now, and tell me the polling interval.
2. Which OEM telematics APIs do you have direct integrations with? Which are dongle-based? Which are manual?
3. Walk me through your energy calculation for a single dispatch decision. What inputs, what buffer, who tuned it?
4. Do you learn per-vehicle consumption, or use a constant? Show me the curve.
5. Can you reserve a charging bay, or only report availability?
6. Model my depot: eight vehicles return at 22:00; my grid connection is 150 kW. What does your system do?
7. What happens when a charger is offline, and your network API doesn't know yet?
8. Show me the cost per kilometre for one vehicle, last quarter, with charging losses included.
9. What does the driver see when they're asked to accept a job that will end below 15%?
10. Which of your reference customers runs a mixed-marque fleet at my scale? Can I speak to them or see their live product?

Question 10 is the one that matters most. A vendor with a strong EV product will have an operator who is happy to talk, or they are happy to showcase what they built for them.

Where Fleets Most Commonly Get This Wrong

Buying on feature-list parity:

Every vendor's website can say "EV ready." The phrase is unregulated. Feature lists compress a 3-tier capability spectrum into a single checkmark.

Underweighting Charging Orchestration:

Operators obsess over dispatch algorithms and then discover their real bottleneck was two DC chargers and no reservation system. Fix the constraint you actually have.

Assuming The Pilot Generalizes:

A ten-vehicle pilot with a dedicated depot and slack charging capacity will not surface any of the failure modes that appear at forty vehicles with contended chargers. Pilot the constraint, not the happy path.

Ignoring The Driver Layer:

The most sophisticated energy model in the market is worthless if drivers route around it. Trust is a system requirement.

Treating Winter As An Edge Case:

Cold-weather range collapse is not an edge case. It is one to five months of the year, and it coincides with peak demand. A platform whose range model was tuned in a temperate quarter will fail you precisely when the money is on the table.

Migration Cost Invisibility:

Dispatch is load-bearing infrastructure. Ask about historical data migration, driver retraining time, and whether the API surface will let you leave. A platform that can't export your trip and energy history in a usable form is a platform you will never leave, which is a fact about your leverage, not their quality.

Making the Decision

Reduce it to three straight questions.

First: what is my binding constraint? 

Charging capacity, vehicle count, trip length distribution, or ambient temperature. One of these dominates. Score the platforms on that row and largely ignore the rest.

Second: Is dispatch making decisions or displaying data? 

This is the fundamental architectural fork. Decision-making systems cost more, demand cleaner telemetry, and take longer to trust. Display systems are cheaper and keep a human in the loop. Below roughly twenty vehicles with a competent dispatcher, the display may genuinely be the right buy. Above that, human arbitration of charging conflicts stops scaling, and it fails first at peak demand, when the cost of failure is highest.

Third: what does the model do in the worst hour of the year? 

Cold, dark, peak demand, chargers occupied, fleet-wide SoC low. Every platform looks identical on a Tuesday afternoon in May. Ask the vendor to walk through that hour. The answer, more than any feature grid, is the comparison.