At 6:20 in the morning, a dispatcher should be able to answer a practical question: which vehicle needs attention before the first delivery leaves? A screen full of green charging icons may not answer it. A van can be plugged in, communicating and drawing power while still being unsuitable for its assigned work.
For a Vancouver or Surrey fleet considering custom software, the valuable project is often the connection between charging operations and dispatch. Start with departure readiness: the evidence that a particular vehicle, assigned to a particular job, has enough usable charge and a workable recovery option. Treat that as an operational decision with uncertainty, rather than a colour derived from charger status.
The technology is moving. Your dispatch rules still matter.
BC Hydro's electric fleet resources bring together planning, infrastructure and electricity-rate information for fleet operators. That creates a useful regional context for software planning: electrification changes the relationship between the depot, energy supply and the working day. A software project should use the fleet's actual plan and equipment constraints, not assume every depot qualifies for the same arrangements.
The Open Charge Alliance's OCPP overview describes communication between charging stations and charging management systems, including smart-charging capabilities and newer protocol versions. A protocol provides messages and supported behaviours. It does not supply your promises to customers, reserve-vehicle policy or definition of an acceptable route.
Ask vendors to demonstrate the specific charger models, firmware and features in the proposed scope. A claim of OCPP support is not evidence that every optional feature works together in your configuration.
Model the next departure, not just the last reading
Consider an illustrative depot with several electric vans and two morning departure waves. One van returns late and is reassigned to a longer route. Another is connected to a charger that has stopped reporting. The useful dashboard must distinguish those problems because their remedies differ.
For each planned departure, connect the vehicle identifier, route assignment, expected departure, required readiness threshold, latest vehicle observation and relevant charger session. Store when each observation happened and when the application received it. A recent network message containing an old vehicle measurement should not become fresh evidence.
Keep a reason next to every readiness result. “Needs review: assignment changed after charging target was calculated” is more useful than “amber.” Show which source owns the underlying fact so the dispatcher can correct an assignment without editing telemetry or inventing a battery reading.
Vehicle charge requirements should come from an agreed operational model and responsible fleet personnel. The integration can apply that model consistently; it should not conceal its assumptions or present a rough estimate as a guaranteed range.
Make intervention a complete workflow
An alert is useful only if the receiving person can act. Define several response paths before choosing notification software:
- ▸Reassign the route to an eligible reserve vehicle and update the original assignment.
- ▸Investigate a charger communication fault without assuming that charging has stopped.
- ▸Escalate a predicted shortfall to the person authorised to change departure plans.
- ▸Record a manual observation with its author and time, keeping it separate from measured telemetry.
- ▸Close the exception only after the chosen action has changed the readiness evidence.
Do not let one alert appear independently in three systems with three owners. Keep a single operational exception and attach messages, acknowledgements and assignment changes to it. The morning shift should see what the previous shift decided and whether the conditions behind that decision still hold.
Read first, control later
A first integration can be read-only. Pull vehicle assignments and charging information into a shared view, then compare the results with dispatch decisions over representative working days. This reveals identifier mismatches, clock problems and missing data before software is permitted to alter charging behaviour.
If a later phase introduces charging commands, separate the requested action from the acknowledged command and observed result. A successfully submitted request does not establish that the charger applied it. Define timeout handling, command ownership and a safe manual fallback with the charging supplier and electrical specialists.
The software scope should also respect site-level power constraints managed by appropriate equipment and qualified professionals. A business dashboard is not a replacement for electrical protection or the charging system's own safety controls.
What a buyer should put in the pilot brief
Choose one depot, an identifiable vehicle group and a limited set of dispatch decisions. Provide anonymised examples of assignments, charger events and the exceptions employees currently resolve by telephone. Ask for a mapping of vehicle identities across every connected system before asking for a polished dashboard.
Define acceptance around situations people recognise. Reassign a vehicle after the first readiness calculation. Interrupt one telemetry feed. Deliver observations out of order. Disconnect a charger while leaving its last known status visible. Change a departure time. Confirm the application explains the uncertainty and routes each exception to an owner.
Request an operational handover: credential ownership, source-system limits, monitoring, manual procedures and a recorded demonstration of recovery after an outage. Those deliverables make the integration maintainable when the original project team is no longer watching it.
Measure the decision that improved
Start with a baseline from real dispatch records. Track how early a readiness issue becomes visible, how long it remains unowned and how often staff must check a second system to interpret it. Review false alarms as carefully as missed issues. An alert that routinely arrives too late, or lacks enough context, will quickly be ignored.
Compare the pilot with the current process before expanding to more depots. Additional telemetry is worthwhile when it changes a decision; otherwise it can increase cost and noise. This keeps investment tied to operations instead of the number of charts delivered.
Our guides to software discovery deliverables and integration statements of work help turn the pilot into a reviewable project. TuniCyberLabs provides custom software development for connected business workflows. Discuss your fleet charging integration with the systems you use, one difficult departure scenario and the decision your team needs to make sooner.