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
Bring the support workflow your operations team wants to improve. We'll identify the conversation, system access, confirmation, data, and human decisions that shape a useful demonstration.
CPO enquiries onlyNo fixed response time promiseNo website lead database
Working contact route
Send the Workflow Directly to Our Team
Automated website form delivery is not active yet. Email is the current contact path, and your message is not written to a marketing lead database.
Emailamr@evcalls.comPlease do not include passwords, API keys, payment card details, or live caller records in the first message.
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.
From there, the right owners can join. Our CPMS integration review guides the technical boundary, while our security and data process keeps unverified controls and sensitive information out of the early sales conversation.
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 identify the missing owners
We separate business rules, CPMS questions, data decisions, financial exceptions, safety paths, and human escalation.
We define a useful demonstration
We choose a scenario that can show the conversation and the approved next step without pretending an unverified integration is live.
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.
A clear business boundary
EVCalls Works With the Organisation Responsible for the Charging Service
We work with CPOs, fleets, utilities, municipalities, site operators, charging service providers, and their technical or support partners. The organisation bringing the workflow must be able to define or obtain approval for its customer process, connected systems, and escalation rules.
EVCalls isn't the public support desk for charging networks we don't serve. If you're an individual driver who needs help now, use the phone number on the charger, in the operator's app, or in your fleet instructions. That route reaches the company with access to your account, session, station, and payment policy.
EVCalls is not
- A public charger locator
- An emergency service
- A payment processor or refund authority
- The operator of an unconnected charging network
- A direct connection to charging stations
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.