Continue in the approved flow
App discovery, first charge guidance, wallet top up instructions, and other defined steps can continue when the call has the required context.
For CPOs covering nights, weekends, and holidays
After Hours EV Charging Support Gives Your On Call Team Room to Rest
We handle routine driver calls and reach your assigned team when a person needs to act.
Plan My After Hours PilotPlan your after hours pilot
Tell us your coverage hours, a recurring call, and your CPMS name. We'll map a focused pilot with you.
The call doesn't disappear when the office closes
Your Phone Shouldn't Be the First Stop for Every App Question
We provide after hours EV charging support so you can separate routine guidance from calls that need your judgement. A driver looking for the app needs a different response from someone reporting a damaged connector. We build those paths around your instructions and the people available overnight.
We map what can continue without a human, what needs approved CPMS context, what should wake the on call owner, and what goes straight to the urgent route. You decide those boundaries. EVCalls follows them and keeps the caller informed when the next decision belongs to somebody else.
Your charge point management system, or CPMS, supplies the charging information used during the call. We check the result of each connected step and pass unresolved work to your assigned team. You can review that whole path in a focused pilot before discussing wider coverage.
A focused pilot for your overnight calls
Test One Recurring Call Before You Hand Over the Night
Which calls keep reaching your on call phone? Bring us one, such as a driver who can't start a session after your desk closes. We'll build the pilot around your instructions, connected systems, and the people who handle exceptions.
You don't need a finished technical brief to start. We'll work through the scope with you, then agree the commercial terms and schedule after reviewing your workflow and CPMS access.
Step 1
Choose the calls that interrupt your night
Start with one recurring call reason, selected sites, and the hours you want covered. We'll agree the language options and what a completed call should look like.
Step 2
Walk through the call before it goes live
We map the questions, check the CPMS access needed, and test the answers with your team. You review when we continue, when we transfer, and who receives an unanswered transfer.
Step 3
Review what happened, then decide
Compare completed calls, human transfers, unresolved cases, and morning handoffs against the criteria we agreed. Together, we'll identify what to adjust before you decide on wider coverage.
Know what you're testing before calls arrive
We'll agree the sites, hours, call reasons and languages in scope. Your team names the person who takes each exception and the backup if they don't answer. We also agree when to pause the pilot and how calls return to your existing support route.
Before launch, we review the call script, permitted system access and handoff details with you. We test the routine call, an unclear system result and a missed transfer. You'll know what needs to pass before we take live calls.
Get a quote around the work your nights need
Bring an estimate of call volume and when calls bunch together. We'll review the coverage hours, language needs, CPMS access and human handoffs with you. Those choices shape the setup and ongoing service we quote.
We'll also discuss any ticketing connection and the support you need during the pilot. You review the scope, commercial terms and schedule before agreeing to start. The first conversation is for working those details out, not choosing a fixed package.
For our first conversation: bring your current support hours, one recurring call, and your CPMS name if you know it. We'll ask who takes over when a call needs a person.
Plan My After Hours PilotNot every ring should wake the same person
Four Ownership Lanes Keep Routine, Technical, Human, and Urgent Calls Apart
You choose who handles each call. We also agree the backup route when the first person is unavailable.
Use reviewed CPMS context
The workflow can read approved information or submit a permitted request through the CPMS, then check the response before describing the result.
Wake the on call owner
Refunds, exceptions, unconfirmed outcomes, priority programme rules, and Level 2 decisions move to the person assigned for that schedule.
Use the urgent route
Smoke, fire, exposed electrical parts, visible damage, collision, medical risk, or another defined danger bypasses routine troubleshooting.
Coverage is a chain, not a switch
Five Decisions Turn Nights and Weekends Into an Operating Schedule
If one decision is missing, the call can still reach a dead end even though somebody answered it.
When coverage begins and ends
Set the exact hours, time zone, weekends, holidays, overflow triggers, and any customer or programme exceptions.
Which calls may continue
Give every approved call reason its own questions, guidance, connected permissions, confirmation, and stopping point.
Who receives each exception
Name the Level 2, refund, field service, account, emergency, and programme owners for each part of the schedule.
What happens when nobody answers
Define the next destination, caller explanation, retry rule, and record when the first human route is unavailable.
What the morning team receives
Separate completed calls from pending decisions, failed transfers, service needs, and urgent events with the approved context attached.
Connected evidence has limits
The CPMS Can Inform the Overnight Call Without Giving EVCalls Direct Charger Control
EVCalls can use an available CPMS API or webhook after the interface, permissions, fields, requests, responses, and unavailable path are reviewed. It doesn't connect directly to charging stations and doesn't execute OCPP commands.
When a workflow includes an authorised request, such as a connector release, EVCalls submits that request through the CPO's CPMS. The CPMS remains responsible for charger communication. We check the result. The caller hears that an action worked only after the agreed system response confirms it.
Our CPMS integration process tests the normal result, rejection, delay, timeout, and unavailable system path before a connected step joins overnight coverage.
The voice agent stops instead of filling the gap with a guess
- Required caller, charger, account, or session context is missing
- The connected system is unavailable or returns an unclear result
- A financial or policy exception needs an authorised person
- A physical problem needs field service ownership
- Safety language activates the urgent route
A second path needs the same rules
Failover Should Preserve the Call Logic, Not Only Keep a Service Online
We offer 24/7 service and plan a backup server for each setup. We test the call flow on that path too. It needs the same greeting, rules, and human contacts as the main service.
If your CPMS is not responding, some guidance can still continue. Other calls need live data. We agree how to handle both cases, including what the caller hears and who takes over.
We test both failures. Keeping the voice service running and guiding a caller without system data are different jobs. Our security and data review documents where call information goes across the primary and failover design.
Two unavailable paths to test separately
Voice service path
Confirm the failover service receives calls with the approved workflow and routes.
Connected system path
Confirm each call reason continues, stops, or escalates correctly without CPMS context.
Give the morning team a clear starting point
Every Overnight Call Ends With a Status and a Named Owner
Separate finished calls from work still waiting. We agree which details go into each handoff: the station, the problem, the steps tried, and the result. A pending refund needs a decision. A failed transfer needs an owner. Your morning team should be able to see the difference.
You decide which events need an immediate notice and which belong in the morning review. We agree how the receiving team gets those details, including a CRM or ticketing connection when it's part of your service. The handoff test checks that the right person can continue the work.
The next team should know
- Which call reason and charging context were identified
- Which approved guidance and requests were completed
- Which result was confirmed, rejected, delayed, or unavailable
- Which human routes were attempted and whether they answered
- Which decision, field action, or customer follow up remains
- Who owns the next action and when its review begins
Test the bad night, not only the clean demo
Decide What a Better Night Looks Like Before the Pilot Starts
We'll agree the review period and success criteria with you before launch. Start with your current call counts, reasons for waking your team and cases left for the morning. If you don't have a baseline, we'll agree how to collect one before making comparisons.
Compare the same call reasons, sites and coverage hours. Keep the sample size and any outages visible so a quiet night doesn't look like a service improvement. At the review, we'll decide with you whether to adjust the flow, extend the test or expand coverage.
Plan My After Hours PilotThe review should include
- A routine call reaches its approved end without waking the on call team
- A Level 2 exception reaches the correct person with useful context
- A safety phrase bypasses normal troubleshooting and enters the urgent route
- An unavailable CPMS changes the call according to the agreed fallback
- A submitted connected request is not treated as a confirmed result
- A failed human transfer follows its second destination and caller message
- The morning record separates completed work from decisions still waiting
Review the Outcome, Not Just Whether the Call Was Answered
- Routine calls
- Count calls that reached the agreed end, then compare them with all calls eligible for that workflow. Keep dropped and unresolved calls separate.
- Calls reaching your team
- Count routine interruptions and required escalations separately. Fewer transfers alone doesn't show whether callers received the right help.
- Handoffs that reached a person
- Check who answered, whether the needed context arrived, and what happened when the first contact was unavailable.
- Work left for the morning
- Review open cases with a named owner and next action. Check whether the receiving team has enough detail to continue.
How Much Time Does Your Team Spend on Support Calls?
Routine charging questions take time away from your operations team. Enter your current call volume to estimate the staff time and cost involved.
Your current support workload
Enter all three values to see your estimate.
This estimates today's staff-time cost, not EVCalls pricing or guaranteed savings.
Hours = calls × minutes ÷ 60. Cost = hours × hourly staff cost. These inputs stay in your browser and aren't sent to analytics or with your enquiry.
Let’s identify which calls EVCalls could handle and where your team should stay involved.
Questions CPO teams ask before handing over the night
Frequently Asked Questions
The driver should reach a defined support path, not a generic recording or an improvised answer. The flow should identify the caller, site, charger, connector, account, and session details required for that call reason. It can then give the CPO's approved app, wallet, account, or charging guidance and use reviewed CPMS context when the workflow allows it. If the issue needs a refund decision, Level 2 judgement, field service, or emergency response, the call moves to the owner assigned for that period. When nobody answers the receiving route, the fallback message and next destination should already be part of the tested workflow.
The CPO should decide that by call reason, risk, customer commitment, and the decision still required. A safety report, trapped or stranded caller under an approved policy, failed urgent transfer, or issue affecting a defined priority programme may need immediate human ownership. A routine app question, known wallet step, or issue that cannot progress until another team opens may follow an approved response and morning handoff instead. The voice agent should not invent urgency or decide that every frustrated caller needs the same route. During design, each call type receives a threshold, destination, context package, unanswered route, and instruction for what the caller hears next.
It can submit an authorised release request through the CPO's CPMS when that exact interface and workflow have been approved and tested. EVCalls does not connect directly to the charging station and does not execute an OCPP command itself. The flow first applies the operator's identity, session, safety, and physical inspection questions. It then sends the permitted request through the CPMS API or webhook and checks the agreed response. A submitted request is not described as a released cable unless the available confirmation supports that result. Visible damage, smoke, exposed parts, collision, an unconfirmed response, or another stop condition moves the call to the CPO's defined human or urgent route.
It should separate guidance from financial authority. The voice flow can explain the CPO's approved wallet steps, identify the relevant account or session, and collect the limited context the receiving team needs. It should not collect payment card information, approve a refund, promise a credit, or guess how a financial exception will be decided. The operator defines which questions can be answered during the call, which cases transfer immediately, and which cases receive an approved explanation before a daytime team reviews them. The same design also covers a failed transfer, so the caller is not told that a refund is in progress when no authorised person has accepted the decision.
The call follows the unavailable system path agreed before launch. Some call reasons may continue with approved guidance that does not depend on live CPMS information. Others must stop because station, account, or session context is required to choose the next step safely. The CPO defines what the caller hears, whether the call transfers, what details are passed, and who receives the service notice. EVCalls plans 24/7 availability with a failover path to another server, but failover does not replace workflow testing. The pilot should include loss of the CPMS, loss of the primary service, a delayed response, and a receiving route that does not answer.
The daytime team should receive a concise record that explains what happened and what still needs an owner. That record can include the approved caller details, call reason, site and charger references, session or account context, guidance completed, connected requests submitted, responses received, transfer attempts, and the unresolved decision. The exact fields depend on the CPO's workflow and data rules. A routine call that reached its defined end should be distinguishable from a failed transfer, pending refund review, field service need, or safety escalation. The handoff should help the team continue the case without making the driver repeat the full conversation or treating an unconfirmed action as complete.