Cutting alert noise by ~80% for EV charging operators

Context

EVEC (EV Engineering Cockpit) is Shell's internal platform for monitoring its EV charging network: live charge-station status plus alerts raised from charger error codes. Market Operations teams work from it daily to keep chargers running and dispatch field engineers. I owned product for the operations experience.

The problem

A single large market could have ~300 open alerts at once. The page showed 100+ at a time with one organizing principle: newest first. Offline chargers, payment faults, broken connectors, failed sessions — one undifferentiated stream, with duplicates because a single hardware fault often fires several error codes. Triaging it manually meant:

• —Critical faults buried under low-priority noise
• —No way to tell what was handled and what was untouched
• —Duplicate alerts inflating the queue
• —Slow responses — finding the right alert meant combing through a hundred

Discovery

Operators kept telling me the same thing: the page was too messy to navigate. The real pain was twofold — hard to find the alerts that mattered, hard to trackthe state of anything. The reframe: an operator should open one page and know what's broken, what matters most, and what's in motion. That became the concept — grouping plus prioritization.

The design

Two mechanisms, working together:

• —Group by location — alerts roll up by site, charge station, and connector. Duplicate alerts for the same fault collapse into one group, latest first when expanded.
• —Prioritize by operational severity — offline chargers rank highest (someone has to physically go and check), hardware faults next, then network and payment issues.

Each station surfaces a primary and secondary alert plus a type summary (“2 offline · 3 faulted · 3 network”) — scanning the page means scanning stations, not raw alerts.

What I considered and rejected

Prioritization alone — re-sort the feed, ship in weeks. Rejected: it solved the wrong half. Operators would still comb hundreds of alerts with no way to track state site by site. Grouping was the tracking mechanism. The accepted tradeoff: collapsed groups hide detail, so every group leads with its highest-severity alert.

Shipping it

Two rounds of wireframe iteration with Market Ops before any code. The hard build questions — where grouping logic lives, how groups stay consistent as alerts stream in — took about four months to work through with engineering, alongside competing roadmap priorities.

Outcome

Pages of 100+ alerts settled at ~25 on average — observed across markets after launch, not a lab number. Operators work site by site on one page, priority alerts are findable at a glance, and the design is now the default in every Shell EV market globally.

What I'd do differently

Define success metrics before launch, not after. I observed the reduction but moved teams before running the structured study the feature deserved — triage time and missed-critical rates, not just alert counts. First thing I'd set up next time.

My role

Everything except the code: the operator discovery, the problem framing, the grouping and priority logic, the wireframes and spec, the iteration rounds with Market Ops, and delivery with the engineering team.