One common call reason
Describe the moment that creates repeat calls, long handling time, after hours pressure, or an incomplete handoff.
For CPO and EV charging business enquiries
Contact EVCalls to Map One CPO Support Call From Hello to Handoff
Tell us which driver calls need better coverage. We'll discuss a demo for your network.
Built for CPO teamsMultilingual call supportA focused pilot
Tell us about your operation
Start With One High-Impact CPO Call
Use the enquiry form to share your network size, the call reason creating the most pressure, and the outcome your team wants to improve.
- After-hours driver support
- App, wallet, session, or connector workflows
- CPMS-connected actions and confirmation
- Level 2, refund, and emergency escalation
Get Started
Plan a Working Demo
Bring one common call reason and the way your team handles it today. We'll use those details to prepare a practical demonstration.
Built around one real support workflow
Multilingual call support scoped to your network
CPMS access reviewed before integration
A focused pilot with agreed test conditions
The first email can be simple
You Don't Need a Finished Specification to Start the Right Conversation
Contact EVCalls with one call reason and the way your team handles it now. A failed session, app onboarding question, wallet step, stuck connector, refund request, safety report, or after hours escalation each gives us a practical place to begin.
We don't need confidential system access or caller records to understand the shape of the problem. A plain description, redacted script, or decision tree can show where the agent asks a question, checks available information, follows an approved instruction, requests a permitted CPMS action, confirms a result, or transfers the call.
We'll bring the right people into the discussion as needed. Our CPMS integration review covers your connected systems, while our security and data review works through how caller information should be handled. You don't need to prepare a technical brief before getting in touch.
Four details move the review forward
Bring What Your Team Already Knows About the Call
You can leave the unknowns open. Naming them is part of the work.
Your current decision path
Share the questions, instructions, refund boundary, emergency route, and point where Level 2 support takes over.
The available system path
Name the CPMS, API, or webhook documentation you have, even if the exact permissions still need technical review.
A result your team can judge
Define what the driver should know or what your operation should receive when the workflow reaches its next step.
What happens next
The Conversation Moves From the Call Problem to a Testable Scope
We don't assign a launch date before the workflow, integration, escalation, language, and review requirements are understood.
We read the operating problem
We start with what happens during the call and why the current path is difficult for drivers or your support team.
We discuss your current setup
Tell us which CPMS you use and who handles the calls today. We'll work through the system and handoff questions together.
We prepare a relevant demonstration
We'll choose a scenario that shows how the driver conversation and human handoff could work for your network.
We scope the pilot when the facts are ready
We agree on the workflow, technical dependencies, test conditions, responsibilities, and evidence needed before discussing rollout.
Bring the right owners when they are needed
One Enquiry Can Open Four Different Reviews
Not every stakeholder needs to join the first conversation, but every unresolved decision needs an owner before a pilot relies on it.
Operations and customer experience
Call reasons, coverage, current scripts, support ownership, human destinations, and the experience your CPO wants to deliver.
CPMS and technical integration
Available interfaces, fields, permissions, requests, responses, confirmation signals, and unavailable system paths.
Security, privacy, and procurement
Caller data, processing locations, access, retention, subprocessors, model improvement, contracts, and evidence requests.
Pilot and commercial scope
The workflow to test, languages, evaluation conditions, responsibilities, pricing inputs, and the decision after the pilot.
Built around your operation
Give Your Drivers a Clear Next Step and Your Team Better Coverage
Whether you manage a public network, a fleet, or charging across several properties, we'll start with the calls your team handles today. Tell us where support gets stretched and which decisions need to stay with your people.
You can begin with one call reason or an after hours window. We'll discuss the conversation, the connection to your CPMS, and how your team receives the calls that need a person.
What we'll discuss with you
- The calls taking your team's time
- The hours you want covered
- Your CPMS and current support tools
- Who receives a human handoff
- A pilot your team can evaluate
Before the first conversation
Practical Questions About Contacting EVCalls
These answers explain what to bring, who the service is for, and how the review begins without promising a timeline or result.
What should we include in our first message to EVCalls?
Include one support call your team handles today and enough context to understand why it is difficult. The most useful starting details are the call reason, the questions your agents ask, the app or account steps involved, the CPMS interface available, the requests an agent may make, and the signal that confirms the outcome. Add the human destination for refunds, emergencies, and unresolved technical issues. You do not need to prepare a polished specification. A current script, decision tree, sample workflow, or plain description is enough to begin identifying what is confirmed and what still needs to be reviewed by the right owner.
Do we need CPMS API documentation before contacting EVCalls?
No. You can begin with the support workflow and identify the technical material during the conversation. API or webhook documentation becomes important before EVCalls claims that a connected step is available, but it does not have to be attached to the first email. Your technical team will eventually need to confirm the relevant endpoints, authentication method, fields, permissions, responses, limits, and unavailable system behaviour. The business team should also define which requests are allowed and what must move to a human. Keeping those reviews connected prevents a technical interface from becoming an unapproved customer support action during a live driver call.
Can an individual EV driver contact EVCalls for charging help?
EVCalls is not a public driver helpline or a charging network operator. Individual drivers should use the support contact provided by the charging point operator, mobile app, station label, fleet programme, or site where they are trying to charge. EVCalls works with CPOs and related charging organisations to design and operate their branded support workflows. It does not have access to an unconnected network's driver account, payment process, station status, or refund policy. This boundary protects drivers from receiving instructions that are not approved by the operator responsible for the charging service. The responsible operator can also verify the specific account and session involved.
Can we discuss pricing in the first conversation?
Yes, but a useful commercial discussion needs a basic operating scope first. EVCalls does not publish a self service price list because the service is shaped by the CPO's call volume, support reasons, language needs, CPMS interface, permitted requests, human coverage, reporting requirements, security review, and pilot design. The first conversation can identify those cost drivers and determine what information is still missing. A price should follow the actual service boundary rather than a generic per minute comparison with a telephony platform. No fixed package, minimum network size, discount, or implementation fee is represented until it has been approved for that opportunity.
What happens after we contact EVCalls about a pilot?
The next step is to review the business flow before setting a pilot scope. EVCalls will need to understand the call reason, current handling process, available system path, approved instructions or requests, result confirmation, languages, data boundaries, and human escalation destinations. The teams can then separate what is ready to demonstrate from what requires technical, security, privacy, or commercial review. A pilot should have an agreed test condition and a clear way to judge the workflow. EVCalls does not promise a fixed response time, implementation date, or go live schedule because those depend on the information and integration work required for the specific CPO.