Three reports of the same fault, none acted on
A driver emails the address on the charger sticker to say bay 3 will not start. The site host's facilities manager rings the office about the same bay. The management platform has been showing an error on that connector for two days, but the alert goes to an inbox that is also full of daily summaries. Three signals, three places, and on Monday someone notices the charger has been out of use since Friday.
Faults arrive by too many routes
A public or workplace charger has several people watching it, none of whom see each other's reports. Drivers use whatever contact is on the unit or the app. Site hosts use their account manager. The back-office system raises alerts, often many of them, some meaningless. Engineers hear about faults by phone. Nothing ties a report to a specific charger, connector and site automatically.
- Driver reports come by email, app feedback, phone and social media.
- Platform alerts are numerous, so real ones are missed among the noise.
- Reports do not say which unit or connector, only 'the one by the entrance'.
- Remote resets are tried but not logged, so the engineer repeats them.
- Nobody measures how long a charger has been out of action.
Out-of-action chargers cost everyone
A charger that does not work loses the site host revenue and reputation, and loses drivers' trust in the whole site. If your contract includes response commitments, missed faults become disputes. Engineers make wasted visits because they were not told a remote reset had already been tried, or arrive without the part the error code pointed to.
One fault queue, built this way
- Every route in feeds one queue: a fault form behind a QR code on each charger, the support inbox, phone notes, and alerts from your charge point management system over OCPP data or its API.
- Each report is matched to a specific charger and connector, from the QR code, the charger ID or the site and bay described. Duplicates are grouped into one ticket.
- Alerts are filtered by rules you set, so only the error types you care about open tickets and noise is summarised instead.
- The ticket shows the charger's recent status, sessions and error history from the platform. Remote actions (reset, unlock, configuration change) are logged when your team performs them.
- If remote steps do not clear it, the ticket becomes a job for an engineer with the history, the error codes, likely parts from your notes on that model and site access details.
- Site hosts and the reporting driver get updates at the points you choose, and every ticket records when the charger went down and when it came back.
| Source | Where it lands now | Where it lands after |
|---|---|---|
| Driver report | Sticker email address | Fault form via QR, matched to connector |
| Site host call | Account manager's phone | Ticket, grouped with others |
| Platform alert | Busy inbox | Filtered, opens a ticket if it matters |
| Remote reset | Not recorded | Logged on the ticket |
| Engineer visit | Phone call with little detail | Job with history and likely parts |
A clear view of what is down
At any moment the team can see which chargers are out of action, since when, and what has been tried. Engineers arrive informed. Site hosts hear from you before they have to ask. Over time, the downtime record shows which sites, models and faults cause the most trouble, which informs the next maintenance plan and the next equipment choice.
Does this sound familiar?
- You find out about faults from site hosts before your own systems.
- Platform alerts are so frequent that people ignore them.
- Engineers repeat remote resets because nobody logged them.
- Driver reports do not say which connector.
- You cannot say how long a given charger was out of use last month.