From Alert to Fix: How a Charger Fault Moves Through One Platform
A step-by-step look at how viveEV detects, diagnoses, and resolves a fault.
When a charger fails, the fault has a journey to make. Someone has to notice it. Someone has to understand it. Someone has to decide what to do, and then do it. Every stop on that journey takes time, and the charger earns nothing until the journey ends.
Most think about the last stop, the repair. But the first stops often decide how long the whole trip takes. We covered how a single charger fault was detected from the first alert to the fix, to show what each stage does and where time can be saved.
Stage 1: The alert
Typical case: A charger stops working. In many networks, nobody knows yet. The fault waits until someone happens to notice or report it.
viveEV platform: Ember, software installed inside of the charger monitors around the clock, every day of the year, and detects when a charger stops or malfunctions. We don't wait for a customer call. The charger raises the alert itself.
The first stage is simple, but it sets the pace for everything after it. A fault that is noticed in minutes can be solved in minutes. A fault that is noticed in days has already cost days.
Stage 2: The diagnosis
Typical Case: A driver’s report tells you something is wrong, but not what. A technician is sent to the site to find out the cause, then discovers they need a part they didn't bring, or that the problem didn't need a visit at all. The result is a wasted trip, and sometimes a second one.
viveEV platform: Remote diagnostics through CDS pinpoint the cause before anyone is dispatched. By the end of this stage, the team knows what caused the fault and whether it can be fixed remotely or requires an on-site repair.
Stage 3: The decision and the fix
Typical Case: Without a clear cause, the choice between a remote fix and a site visit is a guess, and guesses are expensive.
viveEV platform: With the cause known, there are two roads.
Road one: the fix is in the software. Nexus, our operations software, resolves the issue remotely, and the charger returns to service without anyone leaving the office.
Road two: a part must be replaced. A technician goes on site only when parts must be replaced, and goes knowing what the problem exactly is.
One Integrated Platform, Four Proof Points
Ember watches the chargers. CDS finds the cause. Nexus handles the fix. Because the three work as one integrated platform, a fault doesn't stop and wait between stages. Together they give CPOs:
70% of faults resolved remotely, so most faults never need a site visit
20 minutes average on-site repair time, because technicians arrive knowing the problem
2 minutes service recovery time per charger, so chargers get back to earning quickly
24/7 monitoring, 365 days a year, including nights, weekends, and holidays
Each number comes from a different part of the journey, but they all point to the same thing: a fault that is noticed early, understood quickly, and fixed in the simplest way possible.
Why the "One Integrated Platform" matters
A fault that moves through separate tools has to be handed over at each stage: from the person who sees the alert, to the person who diagnoses, to the person who dispatches, to the person who fixes. Each handoff is a chance for delay, missing information, and repeated work. Running these stages on one platform is meant to shorten that journey. The fault doesn't have to be re-explained at every stop, and the people involved work from the same picture of what is happening.
That is a bigger idea than any single feature. A monitoring tool is useful. A diagnostic tool is useful. But the time a fault saves depends on how well the stages connect.