Automated Ticketing for Charging Operations

Where tickets come from

• Driver complaints, which arrive late and describe symptoms rather than faults
• Site host reports, which arrive later still and are usually about several things at once
• Charger telemetry, which arrives immediately and is usually not being used to raise anything
• Monitoring absence, which is the outage no driver reported because the site went dark
• Scheduled maintenance, which is the only category an operator plans

The third and fourth are where the opportunity sits. A network that only creates tickets from complaints is running blind between complaints.

Creating from telemetry

The charger already knows. It reports faults, state changes and meter values continuously, and in most operations that stream is used for dashboards rather than for action.

1. 1

   Define what is actionable

   Not every fault code deserves a ticket. A transient that self-clears is a log entry; the same transient six times in an hour is an incident.

2. 2

   Set thresholds on pattern, not on instance

   Frequency, trend and repetition carry more signal than any single event.

3. 3

   Include the context automatically

   Charger, site, recent history, the trace, the last firmware change. A ticket that arrives complete does not need triage to begin with.

4. 4

   Raise before the complaint

   Which is the entire point. A ticket already open when the customer calls changes the conversation completely.

Ten tickets, one outage

A site loses supply. Eight chargers stop reporting, three drivers complain, the site host emails, and a monitoring alert fires. That is thirteen tickets and one incident.

• Group by site and time window, which catches the majority
• Group by shared cause where it is known, such as everything on one circuit
• Group by symptom across a fleet, which is how a bad firmware release becomes visible as one thing rather than forty
• Keep the individual reports attached, because each complainant still needs an answer
• Resolve once, notify everybody

Grouping is where automated ticketing earns most of its value, and it is the part most systems do worst, because it requires understanding the site rather than the message.

Triage into the four causes

Charger, supply, installation, vehicle. This is the split that decides whether anybody travels, and a great deal of it can be established automatically.

Confidence has to be carried through rather than dropped. A high-confidence supply classification can route without review; a low-confidence one must not.

Routing the ticket to whoever can close it

Routing is assignment, and assignment is not resolution. Systems that report on routing accuracy tend to congratulate themselves for moving work rather than for finishing it, so measure the close.

• Route on cause and on confidence, not on keyword
• Route low-confidence items to a person to classify, rather than guessing and being wrong quietly
• Escalate on age as well as on severity, since the ticket no engineer picked up is the one that becomes a complaint
• Measure resolution, not assignment

Automatic closure, and how it goes wrong

Closing tickets automatically when the condition clears is reasonable and is also where these systems damage trust.

• A charger that recovers may have recovered, or may be about to fail again. Closing on recovery hides the pattern
• A customer complaint is not resolved because the equipment recovered. The customer still had the experience and still expects a reply
• Repeated open-and-close cycles on one unit must surface as one persistent problem rather than as thirty resolved tickets
• Automatic closure should be visible in the record as automatic, so it is never read later as an engineer having checked

A network reporting excellent resolution times because faults self-clear is measuring the wrong thing, and it will keep measuring it right up until a unit fails permanently.

What must stay human

• Anything involving safety, without exception
• Deciding whether to dispatch, where the cost is real and the confidence is not high
• Communicating with a customer who is upset
• Judging whether a repeating fault is a pattern or a coincidence
• Deciding that a unit should be replaced rather than repaired again

What is automated today, and what gets built

Each stage below runs without a person once it has been set up for your estate.

1. 1

   Creation from telemetry

   The unit reports the fault, the ticket opens with the unit, the site, the fault code, the last sessions and the recent error history attached. The operations team types nothing.

2. 2

   Grouping into one incident

   Ten events from one outage become one ticket with ten pieces of evidence rather than ten tickets the team cannot tell apart.

3. 3

   Triage with a confidence score

   Every ticket is classified into a cause and carries how confident that classification is. High confidence routes straight through, low confidence goes to a person to classify rather than being guessed at quietly.

4. 4

   Routing and escalation

   On cause and on confidence, escalating on age as well as on severity.

5. 5

   Closure

   When the condition clears and stays clear, with the recurrence rule below applied first.

Where an estate needs a rule the standard set does not cover, that gets built for it. The classification model, the grouping window and the escalation clocks are all configuration rather than assumptions baked into a product.

What this changes, stated honestly

We do not have a measured before-and-after figure from a deployment, and are not going to invent one.

What we can say is where the change comes from. In a reactive operation, a ticket exists because a driver complained. The tickets that exist are therefore a subset of the faults that happened, skewed towards the ones that annoyed a driver enough to call. Proactive tickets cut the manual work considerably: the typing goes, the duplicate handling goes, the classification goes, and the calls that would have come in about a fault already being worked on go with them.

The larger effect is not on the ticket count at all. It is that unreported faults become visible, which is usually an uncomfortable first month and a better second quarter.