Software systems
We look at the app, account flow, CPMS interface, permissions, responses, fallbacks, and records that sit behind the conversation.
About EVCalls, for CPO teams
We built EVCalls to connect a natural driver conversation with the operator rules, system boundaries, and human decisions that resolve a charging support call.
The reason we started
A driver describes one moment. Your support operation has to place that moment across the app, account, CPMS, station, vehicle, site, payment boundary, and escalation plan. Generic scripts miss those connections.
Our founding team brings software engineering, electrical engineering, and EV charging experience to that gap. We use that perspective to build a support flow your operations and technical teams can inspect together.
Why EVCalls exists
An EV charging support company should know that a failed start, wallet question, stuck connector, offline status, and safety report aren't interchangeable calls. Each one needs a different information path, permission boundary, confirmation step, and escalation decision.
We work from the CPO's actual business flow. That means identifying what the driver can safely do, what information an available CPMS interface can provide, which requests the operator permits, and where automation must stop. We don't connect directly to charging stations or execute OCPP commands.
The goal isn't to make every call autonomous. It is to give routine calls a consistent path and make the difficult calls easier for your human team to pick up. Our CPMS integration process documents that boundary before a pilot handles the workflow.
Two disciplines, one support problem
The call sounds simple only when the connected systems and operational decisions remain hidden.
We look at the app, account flow, CPMS interface, permissions, responses, fallbacks, and records that sit behind the conversation.
We separate what a support flow can observe from what belongs to the charger, site, vehicle, communications path, or field team.
We design the call around what the driver needs to hear and what your Level 2 team needs to receive when the workflow escalates.
The support layer has a defined role
Every deployment should show who owns the conversation, system response, financial decision, physical equipment, and human escalation.
Handles the conversation, follows the approved support path, and prepares a human handoff when required.
Owns the business rules, customer relationship, permissions, refund decisions, emergency policy, and Level 2 route.
Exposes only the information, requests, and responses available through the operator's approved API or webhook.
Remains part of the CPO's charging environment. EVCalls does not connect to it directly or execute OCPP commands.
How we make product decisions
A CPO should be able to trace each support action back to an approved rule, permission, result, or escalation path.
The CPO defines the app steps, account rules, permitted CPMS access, escalation routes, financial boundaries, and emergency path.
We don't describe CPMS access as direct charger control, and we don't turn a proposed control into a compliance claim.
The flow should confirm what happened, explain what the driver can do next, or move the call to the right human with useful context.
A focused pilot tests the real business flow before either team treats the workflow, timing, or outcome as established.
A focused Canadian start
Ontario is our first Canadian commercial focus. We are preparing CPO workflows for the province's mix of corridor, community, workplace, fleet, and multi unit residential charging without implying that one support script fits every network.
That focus also makes the unanswered questions concrete. Which languages are required? Where does each call detail go? Who receives an emergency or refund escalation? What does the CPMS expose? What changes during winter conditions? Our Ontario operator support approach puts those decisions in one place.
Start with one call type, one available system path, one escalation route, and one definition of a confirmed next step. That is enough to expose assumptions before the scope grows.
Evidence earns the next claim
EVCalls is offering a pilot so a CPO can test the service against its own requirements. The duration and launch path depend on the business flow, available CPMS interface, permissions, escalation design, languages, and technical review.
We don't publish a fixed go live time, price, automation rate, customer logo, or performance result before it exists and has approval. That proof standard also guides our security and data review, where proposed architecture stays separate from verified controls.
About EVCalls
These answers separate who we are today from the credentials, deployments, and outcomes that still need public evidence.
EVCalls is built for charging point operators and the teams responsible for driver support, network operations, customer experience, and service costs. It isn't a public helpline for individual drivers, and it doesn't operate a charging network of its own. A CPO brings its support number, business rules, escalation routes, and available system interfaces. The service is then shaped around that operating model. This focus matters because a useful answer depends on more than a general charging script. It depends on the operator's app, account process, CPMS information, permitted requests, refund boundary, safety path, and human support structure. Those details are different for every operator.
EVCalls was founded by software and electrical engineers with experience in the EV charging industry. That combination informs how the team looks at a support call. The conversation is one part of a larger system that may include a mobile app, customer account, payment workflow, charge point management system, communications link, charging station, vehicle, and human escalation team. EVCalls does not publish individual founder names, former employers, degrees, or career timelines until those details have been approved for public use. The current claim is deliberately limited to the engineering disciplines and EV charging experience confirmed by the business owner. It is a specific boundary, not a placeholder biography.
No. EVCalls is the support layer that speaks with drivers and follows the CPO's approved workflow. It does not connect directly to charging stations, own the operator's CPMS, or execute OCPP commands itself. When a workflow needs connected system information or an approved request, the available CPMS API or webhook defines what can happen. The operator controls permissions and escalation rules. The charging station and CPMS remain responsible for their own responses. This separation helps technical teams review the service accurately because it prevents a voice support capability from being described as charger control or universal protocol compatibility. Each integration is reviewed on its actual interface and permissions.
Ontario is the first Canadian market because EVCalls is focusing its commercial work instead of claiming a local presence everywhere. The province includes public corridor charging, municipal and community sites, workplaces, fleets, and multi unit residential charging, each with different support responsibilities. Ontario also brings practical operating questions about winter conditions, language planning, escalation coverage, and Canadian data handling. EVCalls does not claim an Ontario office, government relationship, or live deployment that has not been verified. The market focus means the team can prepare operator workflows around real provincial conditions while keeping each capability, location, and result tied to evidence.
The starting point is a focused pilot based on the CPO's real business flow. The teams first identify one support scenario, the available CPMS interface, permitted information and requests, escalation destinations, language needs, and the result that must be confirmed. The pilot can then show where the support flow works, where it needs adjustment, and which technical or operational questions remain open. EVCalls does not publish a fixed pilot duration, deployment date, price, automation rate, or customer result without evidence. The purpose of the pilot is to let both teams evaluate the workflow before making a broader commitment or a public performance claim.
Bring one common call reason and the way your team handles it today. We'll use those details to prepare a practical demonstration.
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.