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.

    Discuss After Hours Coverage

    Plan your overnight coverage

    Tell us when your desk closes and which calls reach your on call team. We'll work through the coverage with you.

    We'll use these details to arrange your demo and respond to your request. See our Privacy Policy.

    Discuss After Hours Coverage

    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.

    This gives your overnight coverage a defined job without pretending every problem can be resolved before morning. The goal is a known next step for the driver and a useful record for the team that takes over.

    Not 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.

    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.

    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.

    01

    When coverage begins and ends

    Set the exact hours, time zone, weekends, holidays, overflow triggers, and any customer or programme exceptions.

    02

    Which calls may continue

    Give every approved call reason its own questions, guidance, connected permissions, confirmation, and stopping point.

    03

    Who receives each exception

    Name the Level 2, refund, field service, account, emergency, and programme owners for each part of the schedule.

    04

    What happens when nobody answers

    Define the next destination, caller explanation, retry rule, and record when the first human route is unavailable.

    05

    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

    An Overnight Pilot Has to Prove the Boundaries Under Pressure

    Start with one call reason and the hours you want covered. We'll work through who answers an exception, what happens if they are unavailable, and what your morning team receives.

    Discuss After Hours Coverage

    The 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

    Put One Part of Your Overnight Support to the Test

    We offer a focused pilot built around the hours and calls you want covered. Start with a selected group of sites and one common call reason. Together, we'll agree what the service handles and who takes over when a person is needed.

    You'll have a defined scope to review before testing starts. We agree the commercial terms and schedule after reviewing your workflow and CPMS access. The pilot review gives your team a clear decision: adjust the flow, test it again, or discuss wider coverage.

    The calls and hours
    Choose the site group, call reason, coverage window, and language options for the first test.
    The support route
    Name the primary and backup human contacts. Agree the emergency route, refund route, and what happens when a transfer fails.
    The connected steps
    Review the CPMS information and requests the flow needs. Test access and result checks before using the connected path.
    The review with your team
    Review correct routing, confirmed outcomes, unresolved calls, and handoff quality against criteria agreed before the pilot.

    Bring your current support hours, a common call, and your CPMS name. We'll work through the scope with you.

    Discuss After Hours Coverage

    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.

    Bring Us the Call That Keeps Your On Call Team Awake

    We'll map what can continue, what needs a human, what counts as urgent, and what the morning team must receive.