For CPO operations and technical teams
OCPP Support That Keeps Your CPMS in Control
Give your support calls a clear path from the driver's report to an approved system response.
Discuss My CPMS WorkflowBring us a call your team has to investigate
Tell us your CPMS and the support steps you'd like to connect. We'll discuss access, decisions, and a focused pilot.
A Charger Protocol Isn't the Whole Support Workflow
OCPP support starts with a clear split of responsibilities. OCPP, the Open Charge Point Protocol, connects a charger with its management system. We connect EVCalls to your charging point management system, or CPMS, through approved APIs or webhooks. Your CPMS manages the charger connection.
That distinction shapes what a call can do. A driver reports a stuck cable or a failed start. We follow your questions, use the information your CPMS makes available, and request the next permitted step. The charger protocol version alone doesn't tell us whether that step is available through your platform.
Check the Evidence Before Repeating an Action
An accepted request isn't a confirmed result. The cable still needs to release or charging needs to begin. We build the call flow around the result your CPMS returns and the checks your team approves. If a result is missing, stale, or unclear, the flow needs a defined next step.
In an illustrative cable release workflow, we first agree how to identify the station and connector, check the session context, and apply your safety rules. An approved release request passes through the CPMS. We then confirm the available result and the caller's situation before closing the call. Include this scenario in your pilot so your team can review each decision.
Test What Happens When the System Can't Confirm the Result
Bring your CPMS documentation and the calls that are hard to resolve. We'll map the information each question needs, who approves each request, and when another attempt should stop. We'll also agree what your L2 team needs to receive when a person takes over.
Test the difficult calls too. Include a normal response, a rejected request, a timeout, and a caller whose report doesn't match the system. You can then review whether the call followed your rules. That gives your operations and technical teams a shared basis for deciding the next step.
Frequently Asked Questions
Does EVCalls connect directly to chargers using OCPP?
EVCalls connects through your CPMS APIs or webhooks; your CPMS manages the OCPP connection to the chargers. We agree which information and actions the call flow needs, then review how your platform exposes them. For example, a connector release request needs the correct station reference, the permissions you approve, and a way to check the response. We also define what happens when the platform rejects a request or doesn't return a clear result. Your technical team keeps control of access and charger management. The pilot tests that full path so a successful API response isn't mistaken for a confirmed driver outcome.
What should our technical team bring to the first discussion?
Bring your CPMS name, available API or webhook documentation, and one support call you want to improve. A failed start or stuck cable is useful when you can explain how your team handles it today. We'll ask which identifiers the caller can provide, what system information your team checks, and who approves the next action. We'll also discuss the route to a person when the information isn't enough. You don't need to share production credentials or caller records in the initial enquiry. The first goal is to agree a practical workflow and the access review needed before any connected test begins.
Discuss My CPMS Workflow
We'll use your CPMS integration review to agree the access and result checks before a connected pilot.
At EVCalls, we build support around your operating decisions. Our engineering background shapes how we review the system and the call together. Tell us about your network and we'll agree the questions to work through first.
Discuss My CPMS Workflow