How to choose managed charging software for a fleet

Most ranked lists in this category are sold by position or assembled from vendor marketing pages, and the giveaway is that the criteria change to suit whichever product is first. A list that ranks on features nobody can verify is not research.

So the useful thing we can give you is the questionnaire. Send the same five questions to every vendor on your shortlist, put the answers in a column each, and the ranking assembles itself out of facts about your yard rather than somebody else's advertising budget.

The Open Charge Point Protocol is what lets a charger from one vendor talk to a management platform from another. It is the difference between owning chargers and renting a relationship. But it is a family of versions with optional parts, and two products can both truthfully claim OCPP support and still fail to do the one thing you need.

The part you care about most is smart charging, because that is the profile that carries charging limits and schedules to the charger. Ask explicitly whether it is implemented on both the charger and the platform, and whether charging profiles can be stored locally on the charge point so they survive a network outage.

The Open Charge Alliance runs a certification program and publishes what has passed it. Ask for the certificate rather than the claim; the difference between the two is the entire content of many procurement disputes.

This is the criterion that costs the most money when it is wrong and gets asked about the least. A platform that fails open lets the site draw its full connected load overnight, and on a tariff with a ratchet clause that single event is billed for the following eleven months. A platform that fails closed leaves a yard uncharged at dispatch.

Get the answer in writing and then test it. Pull the WAN connection with every port active and watch the meter for two metering intervals. Ask also how long a locally stored profile persists, what happens when it expires, whether sessions still authorise offline, and whether the session records are buffered and uploaded when the link returns or simply lost.

The direction matters because it decides which system is the schedule of record. If the charging platform is going to prioritise by departure time, it needs departure times, and those live in your fleet management or telematics system. If instead your fleet system is the place people look, it needs charging status, and that has to come the other way.

Ask for the API documentation before you sign, not after. Ask whether the integration to your specific telematics provider already exists as a supported connector or whether it is a professional-services engagement, and ask what it costs, because the answer is frequently in a different document from the subscription price.

This is worth real money in some territories and nothing at all in others, so check with your utility before you weight it. What is worth checking everywhere is the reverse constraint: some utility make-ready and managed-charging incentives require networked chargers from an approved equipment list, and buying off that list can disqualify a project from money that was otherwise available.

Read the program terms before the purchase order, not after installation. Pre-approval conditions are common and retroactive approval is not.

Session data is the operating history of an asset you own. Per-session kilowatt-hours, timestamps, vehicle and driver identifiers, meter values, faults: that is how you audit the tariff, prove utilisation for an incentive, allocate cost between departments and make the case for the next phase. A platform that will only surface it through a dashboard is holding your operating history hostage to a subscription.

The related question is whether the chargers can be repointed to a different management system. Over OCPP this is technically a configuration change. Whether the vendor will make it, whether the firmware is theirs to lock, and whether the contract permits it are all separate answers, and the moment to settle all three is before the first order.

A pilot answers the questions a demonstration cannot: whether the telematics integration stays connected, whether the offline behaviour is what the datasheet says, whether the export contains what you need, and whether support answers at 05:00.

It also gives you the interval data to check that the site cap held. That single comparison — cap set against peak recorded — is the whole test of whether the system did its job.