EV depot charging planner · Schneider Electric
Charging 60 buses overnight on a grid connection built for 20.
A web planner for overnight charging of electric buses and vans at depots. Every vehicle is ready by its departure time, without going over the site's grid limit.
- Role
- Digital Product Lead
- Company
- Schneider Electric
- Timeline
- 2021 to 2022
- Team
- 1 designer, 1 PM, 5 engineers, 1 optimisation engineer
- Platforms
- Web app, Email and SMS alerts
1The grid limit is always on screen
2Risk shown the evening before, with the reason
3Each row ends at the vehicle's departure time
6.2% → 0.8%
Vehicles not ready at departure
−31%
Peak grid load at pilot depots
€41k
Peak fees avoided per depot per year
12 → 2 min
Morning check by the depot manager
The problem
Fleet operators were electrifying faster than their grid connections could grow. Depot managers planned overnight charging in spreadsheets, and every morning a few vehicles weren't charged enough to run their route.
What I did
This was my first project as Digital Product Lead. I shaped the product strategy, designed a schedule built around departure times and the grid limit, and designed the alerts and rescheduling for when a charger fails at 1 a.m.
What changed
At three pilot depots, vehicles that weren't ready at departure dropped from 6.2% to 0.8%, peak load fell by 31%, and the morning check went from twelve minutes to two.
01 · Context
The real limit was the grid connection.
In 2021, public transport companies and delivery fleets across Europe were switching to electric vehicles fast. A depot that used to park 60 diesel buses now needed to charge 60 batteries overnight, often on a grid connection sized for a much smaller load. Upgrading the connection could take two years.
So the real job wasn't charging. It was deciding which vehicle charges when, on which charger and at what power, so every one is ready for its morning route and the depot never goes over its limit.
02 · Problem
Spreadsheets, guesswork and buses stuck at the depot.
Depot managers planned with a spreadsheet and experience. When the evening was busy, they staggered charging by hand. When a charger failed overnight, nobody knew until the morning, when a bus with 40% battery couldn't start a 120 km route.
The question we worked on
How might we make sure every vehicle is ready by its departure, without anyone having to stay up all night watching the chargers?
03 · Research
Nights at the depot.
I visited four depots, including two overnight shifts, interviewed nine depot managers and dispatchers, and worked with our optimisation engineer to understand what the scheduling algorithm could and couldn't promise.
Departure time is the only deadline that matters
Depot managers don't think in chargers. They think in routes leaving at 05:50. The plan had to be organised around departures.
“I don't care when it charges. I care that bus 36 leaves at ten to six.”
The grid limit was invisible
Nobody at the depot could see how close they were to the limit. They found out from the monthly peak-fee invoice.
“We only learn we went over when finance calls.”
Trust needs a reason
Managers overrode the algorithm whenever they didn't understand it. When a plan showed why a bus charged later, they left it alone.
“If it tells me why, fine. If not, I'll do it myself.”
04 · Process
Showing an algorithm's plan to a person.
List of chargers with status
How charger software usually looks. It hid the two things that mattered: departures and the grid limit.
Map of the depot
Useful for finding a vehicle on site. Useless for understanding the night.
Timeline per vehicle with the grid limit on top
One row per vehicle, departures as flags, and the depot's load drawn against its limit above it.
05 · Design decisions
Departures and the grid limit, always visible.
The grid limit is always on screen
Above the schedule, a load chart shows the depot's planned power use for the night against its limit. When the plan is close to the limit, the line turns amber. Managers could finally see the constraint the algorithm was working with.
Every vehicle row ends in its departure
Each vehicle has a row with its charging sessions and a flag at its departure time. If the plan can't reach the needed charge by then, the row is marked at risk with the reason, the evening before, while there's still time to act.
When a charger fails at 1 a.m., the plan fixes itself
If a charger stops, the planner proposes a new schedule within a minute and texts the on-call person only if a departure is at risk. For the common case, the alert says the problem and the fix in one message, and one tap approves it.
Alerts only when a departure is at risk
Early versions alerted on every charger event. In the first pilot week, one depot manager got 47 messages in a night and turned them off. We changed the rule: only alert a person when something will affect a departure and the system can't solve it alone.
No message
Charger restarted, plan unchanged.
Summary in the morning
Bus 4127 moved to C-09, still ready on time.
SMS with one-tap approve
Reschedule delays two vehicles by 10 minutes.
Phone call
Bus 36 can't reach 85% by 05:50 on any charger.
06 · Outcome
Every bus out on time, on the same grid connection.
“I check one screen with my coffee and I know the morning will be fine.”
“We postponed the grid upgrade by at least two years.”
07 · Reflection
What I learned.
My first project as a lead taught me that the job of the interface is to make an algorithm's reasoning visible. Managers didn't need to understand optimisation. They needed to see the limit, the departures and the reason a bus charges later.
I'd design alerts with the night shift from day one. The 47-message night was avoidable.
Tools on this project
Figma, Principle, D3 prototypes, Jira, Confluence
Names of the people quoted have been changed to protect their privacy.
FieldPro for iOS →
