One inspectable path from call to next action

    See How the EV Charging Support Workflow
    Moves From Call to Next Action

    Your systems stay in control. We handle the conversation, use the access you approve, check the available result, and bring in your team when the workflow reaches its limit.

    • Built for EV charging support
    • Operator-approved workflows
    • Human escalation for exceptions
    • No direct charger control

    Scripted EVCalls Example

    Nothing plays automatically
    Session Won't Start

    Play a scripted call flow

    This visual example has no audio and does not represent a live customer call.

    Begin with identification, not automation

    The Call Doesn't Begin With a Command

    An EV charging support workflow begins by identifying what the driver is trying to do and which site, connector, account, or session is involved. The agent shouldn't touch a system until the required context is clear enough for the approved path.

    That matters because the same words can describe different problems. “It won't start” could mean the driver has the wrong app, an empty wallet, a failed authorization, a connector issue, a station state, or an unavailable backend. We use your questions to narrow the cause before deciding what comes next.

    If your CPMS provides the required API or webhook, EVCalls can use that interface within the permissions you approve. It doesn't connect directly to the charging station and doesn't execute OCPP commands. The CPMS remains the charger-facing system.

    The complete call path

    Six Decisions Take the Call From Ring to Handoff

    Each step has an owner, an input, and a condition that decides whether the workflow can continue.

    Step 1

    The driver reaches your support line

    EVCalls answers with the network identity, language, and opening questions approved for your operation. English and Arabic are available today.

    Step 2

    We identify what the driver can see

    The agent gathers the call reason and the identifiers needed to distinguish the site, charger, connector, account, and session.

    Step 3

    We check only the information you permit

    When the workflow needs system context, EVCalls uses the API or webhook made available by your CPMS and the permissions approved for that call reason.

    Step 4

    We follow the approved decision path

    The agent gives the agreed instructions, asks the next question, or requests an allowed CPMS action. It does not improvise a new operational rule during the call.

    Step 5

    We look for a confirmation signal

    A submitted request is not the same as a successful result. The workflow checks the response or another signal agreed with the operator before describing the outcome.

    Step 6

    We close the loop or bring in a person

    A confirmed next step is explained to the driver. An uncertain, unsafe, financial, emergency, or unresolved call moves to the operator's human route with the agreed context.

    The systems don't share one job

    Keep the Conversation, CPMS, Charger, and Human Roles Separate

    Clear ownership prevents a voice agent from claiming control or certainty it doesn't have.

    EVCalls handles the conversation

    We ask the approved questions, explain the permitted steps, and keep the driver informed about what is happening next.

    Your CPMS controls charger communication

    The CPMS exposes the interface, applies permissions, communicates with the charging station, and returns the information available to the workflow.

    The charging station returns its own result

    A charger may accept, reject, delay, or fail to confirm a requested action. The workflow must account for that response instead of assuming success.

    Your team owns exceptions and decisions

    Your Level 2, emergency, or financial team takes responsibility when the issue leaves the approved automated path.

    A request was sent. Did the connected system confirm what happened?

    Confirmation before confidence

    The Driver Shouldn't Hear “Done” Until the Result Is Known

    When a workflow requests an action through the CPMS, the request itself proves only that EVCalls sent it. The CPMS may return a completed result, a rejection, a timeout, or an uncertain response. We define which signal counts as confirmation before the call flow is approved.

    If the available response confirms the result, the agent explains the next step and asks the driver to verify what they can see. If the result is missing or unclear, the agent says that it can't be confirmed and follows the fallback. This is where useful support becomes safer than confident guessing.

    Where the automated path ends

    Four Conditions Move the Call Out of Normal Troubleshooting

    Your rules decide the destination. The workflow makes the boundary visible and repeatable.

    Emergency or safety concern

    Stop normal troubleshooting and transfer according to the operator's emergency route.

    Refund or financial exception

    Explain approved wallet steps, but leave refunds and financial decisions to an authorized person.

    System unavailable or uncertain

    Continue only with system-independent steps and never describe an unconfirmed status as fact.

    Physical damage or site access

    Do not diagnose damaged equipment by phone or coach a driver through a physical hazard.

    The human handoff

    Your Level 2 Team Should Know Why the Call Arrived

    EVCalls can transfer the caller with the context approved for the workflow. That can include the caller's name and phone number, the call reason, the station or session details collected, and the steps already completed. The exact package depends on your transfer method and privacy requirements.

    We don't currently claim a universal CRM or ticketing integration. If you want the handoff to create or update a record, we scope the system, fields, permissions, and failure path as a separate integration requirement.

    The same care applies to caller data. Our privacy commitments describe the current handling approach, while the deployment design documents the exact data flow, retention, and access rules for your operation.

    Build one testable path

    Map the Workflow Before You Hear the Demo

    Bring one common call reason, the current agent questions, CPMS interface, allowed actions, confirmation signals, and escalation routes. We will turn those details into a call path you can inspect before any pilot begins.

    If Ontario is your first market, our Ontario support plan adds the province's highway, community, residential, fleet, language, and winter considerations.

    A complete workflow defines:

    • Required caller and site identifiers
    • Information EVCalls may access
    • Instructions and permitted requests
    • The signal that confirms an outcome
    • Human destinations for every exception

    Workflow questions

    The Details to Settle Before Testing

    These answers separate the conversation from the systems and decisions behind it.

    What does an operator need to provide before EVCalls can build a support workflow?

    The operator needs to provide the way the call is handled today. That includes the questions an agent asks, the information needed to identify the site and session, the CPMS interface involved, and any instructions the driver may safely follow. We also need to know which actions an agent may request, how a successful result is confirmed, and which calls must move to a human. Emergency contacts, refund routes, Level 2 destinations, supported languages, and the context required during transfer are part of the same review. Starting with the real decision tree keeps the workflow tied to the operator's policies instead of assumptions about how every network works.

    How does EVCalls identify the correct charging station during a call?

    EVCalls uses the identifiers and questions approved by the operator. Depending on the network, that may include a site name, address, station label, charger number, connector number, or information from the driver's account or session. The exact method depends on what the operator displays at the site and what its CPMS makes available. The workflow should not continue to a system action until it has enough information to identify the intended equipment and session. If the caller cannot provide the required details, or the connected system returns an uncertain match, the call follows the operator's fallback instead of guessing which charger the driver means.

    How can EVCalls request a charger-related action without connecting directly to the charger?

    EVCalls sends the request through the operator's charge point management system, not to the charging station itself. The CPMS exposes an API or webhook, applies its own permissions, communicates with the charger, and returns the available result. During setup, the operator decides which actions belong in the support workflow and under what conditions they may be requested. EVCalls does not claim compatibility until the required interface and permissions have been reviewed and tested. It also does not treat a submitted request as proof of success. The workflow needs a response or another agreed confirmation signal before telling the driver that the action worked.

    What happens if the CPMS is unavailable or does not confirm the result?

    The call follows a fallback defined before launch. EVCalls can continue with approved questions and driver instructions that do not depend on the unavailable system, but it should not invent station status or claim that an action succeeded. The workflow can explain that the result cannot be confirmed, collect the context needed by the next team, and transfer the caller to the operator's Level 2 route. The operator decides whether different call reasons use different fallbacks. A first-charge question may still have useful steps, while an uncertain cable-release request or safety concern may need an immediate handoff. These paths are tested during the pilot rather than decided during a live call.

    What information can move with a call when a human takes over?

    The handoff can include the context agreed with the operator, such as the caller's name and phone number, the stated reason for the call, the site or charger identifiers collected, and the steps already completed. The purpose is to prevent the driver from starting the conversation again and to help the Level 2 person see why the transfer happened. The exact information package depends on the operator's systems, privacy requirements, and transfer method. EVCalls does not currently claim a universal CRM or ticketing integration. If a customer needs one, that connection and its field mapping become part of the technical scope and testing plan.

    How are emergencies, safety concerns, and refunds handled?

    They move to the human route defined by the operator. EVCalls can recognize the issue category, stop the normal troubleshooting path, collect only the information approved for that situation, and transfer the caller to the correct destination. It does not make refund decisions, process payment-card information, or coach a driver through damaged or unsafe physical equipment. The operator supplies the emergency and financial escalation rules, including what the caller should hear while the transfer is happening and what context the receiving person needs. Those routes are tested as first-class scenarios because a workflow is not ready if it handles the common calls but fails at the moments where a person must take responsibility.

    Bring One Call Reason and We'll Map Every Decision

    You will see what EVCalls asks, what your CPMS controls, how the result is checked, and where your team takes responsibility.

    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
    English and Arabic call support
    CPMS access reviewed before integration
    A focused pilot with agreed test conditions

    Email Your CPO Workflow

    Automated form delivery isn't active yet. Send one call reason and the way your team handles it today directly to EVCalls.

    Don't include passwords, API keys, payment card details, or live caller records. See our Privacy Policy.