CRM for EV Charging Operators

What has to be linked

The functional test of a charging CRM is whether a support agent, given a caller, can see everything relevant without opening a second system.

• Customer to sessions, so a billing question can be answered rather than escalated
• Customer to sites, since a site host's interest is a place rather than a transaction
• Session to charger and to what the charger was doing at the time
• Ticket to session and to charger, so history is one story rather than three
• Contract to tariff to actual usage, which is where revenue share arguments are settled
• Invoice to the sessions behind it, at line level

Without these links a support conversation becomes a sequence of holds while somebody looks things up, and the customer experiences that as incompetence.

Support history that includes the equipment

This is the specific thing a generic CRM cannot do, because it has no concept of the charger.

A driver who has complained three times about the same bay is a different conversation from one who has complained about three different sites. The first is a fault the operator has failed to fix; the second may be a vehicle. A CRM that records only the complaints cannot tell those apart, and the agent has to reconstruct it every time.

Contracts against actual usage

• Site host revenue share, calculated from sessions rather than agreed and forgotten
• Minimum volumes in fleet contracts, tracked against actual so a shortfall is visible before renewal
• Tariff terms per customer, applied automatically rather than by remembering
• Contract dates that surface as work rather than as a spreadsheet the account manager maintains
• Rate changes with an effective date, and historical sessions billed at the rate in force at the time

The last one causes more disputes than it should. A tariff change applied retrospectively is a credit note and an awkward call.

Churn signals in charging data

Charging generates behavioural data that predicts churn far earlier than any commercial signal does, and almost nobody uses it.

1. 1

   Frequency falling

   A regular driver charging less often is either driving less or charging elsewhere, and it is worth knowing which.

2. 2

   Session length shortening

   Topping up rather than filling, which often means somewhere else has become their main site.

3. 3

   Site host utilisation falling

   The renewal conversation is coming and the host will have noticed before you do.

4. 4

   Failed sessions concentrated on one customer

   The clearest predictor of all. A driver having a bad experience repeatedly is a driver about to leave.

5. 5

   Support contacts rising then stopping

   They stopped complaining because they stopped coming, not because it was fixed.

Integrate or replace

Most operators of any size already have a CRM, and the sales team will not move.

The workable pattern is that the existing CRM keeps the commercial relationship, the charging platform keeps the operational reality, and the two are linked so a customer record resolves to their sites, sessions and tickets. Attempting to hold session-level charging data in a generic CRM produces a slow CRM and an incomplete picture. Attempting to run sales from a charging platform produces a sales team that carries on using the CRM.

Acquisition and churn sit on their own page

Everything above is the record: one customer, one history, every session and ticket attached to it. What you do with that record to win a site host and to stop a driver disappearing is a different discipline, and it has its own page.

The short version is that a first session is the only introduction you get, and whether it becomes a second one is a software question rather than a hardware one. See the CRM for drivers and hosts below.