What to Look for When Choosing a New EV Charging Platform

Quick Answer 

When choosing a new EV charging platform, the criteria that matter most are architecture (whether the platform is API-first and built for integration), hardware compatibility (whether it supports any OCPP-compliant charger or locks you to specific vendors), reliability (a specific, verifiable uptime figure and a clear incident response process), support quality (direct access to engineers, not a generic helpdesk), and commercial model (whether pricing aligns the vendor's incentives with your network's performance). Feature lists are easy to produce and hard to verify. The evaluation criteria in this article are designed to surface what is actually true about a platform and not what a vendor's sales deck says about it. 

Choosing a new EV charging platform is a decision with a long tail. The platform you select will shape how your network operates, how your team spends its time, and how easily your business can grow and integrate new capabilities over the next several years. Getting the evaluation right matters more than getting it done quickly. 

The challenge is that most vendor comparisons focus on features, and features are the easiest thing to inflate. A feature matrix tells you what a platform claims to support. It does not tell you how reliably those features work at scale, how the vendor behaves when something goes wrong, or whether the platform's architecture will support the integrations your business needs two years from now. 

This article sets out a framework for evaluating EV charging platforms that goes beyond the feature list. For context on what a full platform migration involves once you have made your choice, our guide on migrating your EV charging operations covers the process end to end. 

What a CPMS evaluation framework should actually cover 

A thorough CPMS evaluation has six dimensions. Each one is worth assessing independently, because a platform that scores well on five and poorly on one can still create serious operational problems. 

Architecture: how the platform is built 

The architecture of a platform determines almost everything else about it. A platform built on open APIs and designed for integration from the ground up behaves fundamentally differently from one that was built as a standalone tool and had integration capabilities bolted on later. 

The practical question to ask is: how does this platform connect to the other systems my business runs on? For an energy company, that means billing infrastructure and energy management systems. For a parking operator, it means the app and payment systems that drive the customer experience. For a fuel retailer, it means the loyalty and point-of-sale systems that tie charging into a broader visit. 

An API-first platform gives you the ability to connect those systems through documented, stable APIs rather than through workarounds or bespoke development projects for every new connection. Ask prospective vendors how many ready-built integrations they support, how their API is documented, and how custom integrations are handled when a ready-built option does not exist. 

The answer to that last question is particularly revealing. A vendor that handles custom integrations through its own engineering team, rather than referring you to a third-party systems integrator, has a very different level of ownership over the outcome. 

Hardware compatibility: what the platform will and will not manage 

A platform that is genuinely hardware-agnostic will manage any OCPP-compliant charge point, regardless of manufacturer. A platform that claims hardware-agnosticism but has a preferred hardware partner list, or that works best with its own branded chargers, is telling you something about where the lock-in lives. 

Ask which OCPP versions the platform supports. Ask for a list of tested hardware partners and, specifically, whether chargers outside that list are supported. Ask how the vendor handles edge cases where a charger manufacturer's OCPP implementation has quirks or non-standard extensions. 

Hardware lock-in has a compounding cost. If your platform limits which chargers you can deploy, it limits your ability to source competitively, adopt newer hardware, or expand into sites where different charger models are already installed. The freedom to choose hardware independently of your software is worth protecting. 

Reliability: what the numbers actually mean 

Every vendor will tell you their platform is reliable. The evaluation is in the specifics. 

Ask for a precise uptime figure and ask how it is calculated. 99.9% uptime means roughly eight and a half hours of downtime per year. 99.999% means less than six minutes. The difference between those two figures is significant for a public charging network where downtime directly affects session revenue and driver experience. 

Ask how incidents are communicated. When the platform has an issue, how quickly are customers informed, through what channel, and with what level of detail? A vendor with a transparent incident communication process has thought about reliability as an operational discipline and not just a metric. 

Ask about historical incident data. Uptime figures are averages. What matters operationally is the frequency and duration of incidents, and whether the pattern is improving or deteriorating over time. 

Support: who you are actually speaking to 

Support quality is consistently underweighted in platform evaluations and consistently overweighted in the experience of running a live network. When something goes wrong at 11pm on a Friday, the quality of the person responding to your ticket matters enormously. 

The key question is structural: when you raise a support request, does it reach an engineer who built the platform or a support agent working from documentation? The distinction affects resolution speed in ways that are difficult to overstate. 

Ask vendors to walk you through how a critical incident is handled. Who is the first point of contact? What is the escalation path? How are resolutions communicated? A vendor with a clear, engineer-led incident process will answer these questions specifically. One that routes support through a generic helpdesk will give you a more general answer. 

Also ask about onboarding and post-migration support. The period immediately after go-live is when support quality matters most, and it is worth understanding exactly what level of access you will have during that window. 

Data ownership: what happens to your data 

This dimension is easy to overlook in an evaluation and costly to ignore in a contract. Your charging network generates session data, driver behaviour data, charge point performance data, and billing records. That data belongs to your business, and your ability to access, export, and use it should be unambiguous. 

Ask prospective vendors how data ownership is defined in their standard contract. Ask how data is exported, in what format, and whether there are any costs or restrictions associated with export. Ask what happens to your data if you end the contract. 

Some legacy platforms make data portability difficult by design. A vendor that is confident in the value of their platform has no reason to make your data hard to leave with. 

Commercial model: whose interests the pricing serves 

Pricing structure is not just a budget question, and the model a vendor chooses directly affects whose interests are served when your network underperforms. 

A pricing model tied to successful charging sessions means the vendor's income is directly connected to whether your network performs. When sessions fail, the vendor loses revenue alongside you. A flat per-charger fee, regardless of session volume or success rate, creates no such alignment. The vendor gets paid whether your chargers are working or not. 

At small scale, the difference between these models is modest. At several hundred or several thousand charge points, it becomes significant, both in absolute cost and in the behaviour it produces from your vendor. 

Ask vendors to explain their pricing model clearly and ask specifically what happens commercially when session success rates drop. The answer will tell you more about the vendor's incentive structure than any feature list will. 

Questions that separate good answers from accurate ones 

Feature demonstrations and reference calls are useful, but the most useful information in a platform evaluation often comes from questions that cannot be answered with a prepared response. 

Ask the vendor to describe a migration that went wrong and how they handled it. Ask them to show you a real incident report from the past six months. Ask them how many of their current customers have migrated from a competitor, and whether you can speak to one of them about the process. 

These questions do not have scripted answers. The quality and specificity of the response is itself part of the evaluation. 

Conclusion 

A thorough platform evaluation takes time, but the time is worth spending. The cost of choosing a platform that underperforms on architecture, reliability, or support compounds across every month your team absorbs the overhead, every integration that cannot be built, and every session that fails without a clear path to resolution. 

Evaluate on evidence, not on claims. The platforms that hold up under this kind of scrutiny are the ones worth building your network on. 

eMabler is a charging management platform for EV charging operators across Europe. 

If you are comparing EV charging platforms and want to put eMabler through this kind of evaluation, we are happy to talk.