Safety or emergency
The caller reports a condition named in the CPO's urgent path, so normal troubleshooting stops.
For CPO teams defining where automation must stop
EV Charging Call Escalation Should End With an Owner, Not Another Queue
Give the next person the reason, evidence, completed steps, and decision that still needs them.
CPO defined stop rulesLevel 2 and emergency routesMultilingual call supportFailed transfers are tested
The escalation contract
Five Questions Must Be Answered Before the Transfer Begins
01What caused the flow to stop?
02Who owns that exact decision?
03What context may follow the call?
04What should the caller hear now?
05Where does the call go if nobody answers?
Stopping is part of the service
A Handoff Isn't a Failure When the Workflow Reaches the Right Boundary
EV charging call escalation begins when the next decision belongs to a person, field team, financial owner, programme contact, or urgent route. The voice agent shouldn't keep troubleshooting only to avoid a transfer. It should stop at the boundary you approved.
We give each boundary a trigger, receiving owner, permitted context, caller message, operating schedule, and fallback. That structure keeps a routine Level 2 question separate from a refund request or a report of damaged equipment.
The goal isn't to escalate more calls. It is to make every necessary handoff understandable to the caller and useful to the person who accepts it.
One stop button can't govern every exception
Six Triggers Send Calls to Different Owners
Each trigger needs its own destination and failed route because the unresolved decisions are not interchangeable.
Refund or financial decision
Guidance can continue within policy, but an authorised person owns refunds, credits, and exceptions.
Missing or unconfirmed evidence
Required context is unavailable, a request is rejected, or the agreed result cannot be confirmed.
Account or programme exception
The caller's access, contract, customer programme, or policy falls outside the approved normal rule.
Physical or field work
The issue needs inspection, repair, site access, or another action owned beyond the call flow.
Defined human judgement
The CPO assigns a person to calls where context, customer impact, or technical ownership needs Level 2 review.
The next person needs the case, not a blank line
Six Pieces of Context Turn a Transfer Into a Handoff
The CPO selects the fields for each route. We don't attach information simply because a system makes it available.
Caller
Name and phone number only when the approved handoff requires them
Charging context
Programme, site, charger, connector, account, or session references needed by that route
Reason
What the caller reported and the condition that triggered the escalation
Completed steps
Guidance given, connected requests submitted, and the responses that were actually received
Open decision
The refund, policy, technical, field, safety, or customer decision the next owner must make
Transfer status
Which destination was attempted, whether it answered, and which fallback now owns the case
Evidence determines whether the flow continues
An Unclear CPMS Result Should Change the Owner, Not Become a Guess
EVCalls can read approved context or submit a permitted request through an available CPMS API or webhook. It doesn't connect directly to charging stations and doesn't execute OCPP commands.
The workflow separates a submitted request from a confirmed result. If the CPMS rejects the request, times out, is unavailable, or returns an unclear response, the CPO decides whether the call retries, continues with limited guidance, or moves to Level 2.
Our CPMS integration review maps that evidence and the unavailable path before a connected request can influence an escalation.
The handoff states what is known
Request was not submitted
Request was accepted for processing
Request was rejected
Result was confirmed
Result remained unavailable or unclear
A dialled number is not a completed transfer
The Caller Needs a Clear Next Step in Every Transfer State
The voice agent tells the caller why the issue needs another owner and what is happening next. It doesn't say a person has accepted the case until the receiving route confirms that outcome.
If the first destination doesn't answer, the call follows the CPO's second route. The fallback can change by schedule, customer programme, call reason, and risk. An urgent failure never drops silently into a routine queue.
Our overnight coverage design applies those same transfer states when the staffed desk is closed.
The receiving person answers
The approved context follows the call and the new owner takes the unresolved decision.
The first route does not answer
The workflow records the failed attempt, explains the next step, and follows the CPO's second destination.
The issue can wait for a named team
The caller hears the approved expectation and the record identifies who reviews it next.
The urgent route fails
The call follows the separate emergency fallback instead of dropping into routine technical support.
Keep the context useful and limited
The Receiving Team Should Get What It Needs, Not Everything the Call Touched
EVCalls records the caller's name and phone number only when they are needed for the approved Level 2 handoff. The workflow can also carry the call reason, permitted charging references, completed steps, connected responses, and unresolved decision.
The CPO defines which fields belong in each route, where they are stored, how long they remain, and who can access them. EVCalls isn't currently connected to a specific CRM, so any CRM or case system handoff needs its own API or webhook review before it becomes part of the deployment.
Our call data review follows that information from collection through transfer, storage, model improvement, and deletion decisions.
The receiving owner should see
- Why this call left the normal flow
- Which facts were identified and which remain unknown
- Which guidance and connected steps were completed
- Which result was confirmed and which was not
- What the caller has already been told
- What decision now belongs to the receiving team
Test the receiving side, too
The Pilot Isn't Ready Until Failed Handoffs Behave Correctly
A clean transfer proves only one state. The pilot also needs the unanswered, unavailable, and unconfirmed paths.
The escalation review should verify
- Every call reason has a defined trigger and receiving owner
- Routine calls do not escalate only because the caller sounds frustrated
- The handoff contains the approved context and no unnecessary personal information
- A submitted CPMS request is separated from a confirmed result
- The caller hears accurate language before, during, and after the transfer
- The first unanswered route moves to the correct second destination
- Safety and refund paths remain separate from routine Level 2 support
Questions that define the human boundary
Frequently Asked Questions
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
Multilingual call support scoped to your network
CPMS access reviewed before integration
A focused pilot with agreed test conditions