# How to Integrate Smart Charging Into Fleet Operations
Most fleet electrification projects fail quietly. The chargers work. The vehicles arrive. But the operation still runs on spreadsheets, phone calls, and a facilities manager who checks the electrical panel with a flashlight at 6 a.m. The problem is not the hardware. It is that dispatch, telematics, charging, and energy management are four separate systems that never learned to talk to each other.
This article is the integration playbook. It explains how the four systems connect, what data actually flows between them, and how to roll out smart charging without disrupting daily operations. If you are running a depot with more than ten electric vehicles, this is the difference between charging that reacts to problems and charging that prevents them.
Why smart charging integration fails: the silo problem
Fleet operators usually buy systems in this order: vehicles first, chargers second, software last. By the time someone asks about integration, the telematics platform is locked in, the chargers are on a proprietary network, and the utility bill is a surprise every month.
The failure pattern looks like this:
- Dispatch knows which vehicles need to leave at 7 a.m., but the charging schedule was set last night based on guesswork.
- Telematics reports a vehicle at 40% SOC, but the charger cannot see that data, so it charges at full power anyway.
- The energy management system (EMS) sees a demand spike coming, but the chargers do not throttle because they are on a different network segment.
- The utility bill arrives with a demand charge that wipes out the fuel savings for the month.
Each system works in isolation. The operator becomes the integration layer, manually copying data between dashboards. That does not scale past five vehicles.
The four systems that must connect
Smart charging integration requires four systems to exchange data in real time. Here is what each one contributes and what it needs from the others.
1. Dispatch and [telematics](/blog/fleet-charging-telematics-integration/)
Dispatch knows the schedule: which vehicle leaves when, which route it takes, how many miles it will cover. Telematics knows the state: current SOC, battery health, location, idle time.
What dispatch/telematics must send to charging:
- Vehicle ID and plug assignment
- Required departure time
- Target SOC at departure (not always 100%)
- Current SOC and battery temperature
- Priority flag (urgent vs. flexible)
What charging must send back:
- Actual energy delivered
- Charging start and end times
- Any faults or interruptions
- Real-time charging power
2. Charging hardware
The charger is the execution layer. It takes commands from the EMS and delivers power to the vehicle. For integration, the charger must support OCPP 1.6J or later. OCPP 1.6J is the practical minimum because it supports smart charging profiles, remote start/stop, and status notifications. Without it, the EMS is blind.
FBK POWER's DC fast chargers ship with OCPP 1.6J as standard. That is not a feature we advertise; it is the baseline that makes integration possible.
3. Energy management system (EMS)
The EMS is the brain. It takes the schedule from dispatch, the constraints from the utility, and the real-time state from the chargers, then calculates when each vehicle should charge and at what power.
The EMS must handle:
- Load balancing across multiple chargers
- Demand charge avoidance (peak shaving)
- Time-of-use (TOU) rate optimization
- Grid constraint compliance (transformer limits, service panel capacity)
- Priority queuing when demand exceeds capacity
For a deeper look at how EMS works with chargers, see our elastic load balancing article and, see our EMS buyer's guide.
4. Utility and billing
The utility is not a software system, but it is a data source. You need:
- Rate schedule (TOU periods, demand charge thresholds)
- Service capacity (kW available at the panel)
- Any demand response programs or incentives
Billing data closes the loop. If the EMS claims it saved money, the utility bill should prove it.
Integration architecture: how data actually flows
Here is the data flow in text form. No diagrams, just the sequence.
- Dispatch exports tomorrow's schedule to the EMS: Vehicle A departs 06:00, needs 80% SOC. Vehicle B departs 08:30, needs 60%.
- Telematics pushes current SOC every 15 minutes: Vehicle A is at 45%, Vehicle B is at 70%.
- EMS calculates required energy: Vehicle A needs 35 kWh, Vehicle B needs 10 kWh.
- EMS checks utility constraints: site limit is 250 kW, TOU peak starts at 07:00, demand charge threshold is 200 kW.
- EMS builds a charging schedule: Vehicle A charges 02:00-05:00 at 60 kW. Vehicle B charges 05:00-06:00 at 40 kW.
- EMS sends OCPP smart charging profiles to each charger.
- Chargers execute the profiles, report status back to EMS.
- EMS monitors actual vs. planned, adjusts in real time if a vehicle returns late or a charger faults.
- At month end, EMS compares predicted energy cost to utility bill.
The critical handoff is step 6. If the charger cannot accept a smart charging profile via OCPP, the EMS is just a reporting tool.
Phased rollout plan
Do not integrate everything at once. Here is the sequence that works.
Phase 1: Pilot (months 1-3)
- Pick 2-4 chargers and 5-10 vehicles.
- Connect chargers to the EMS via OCPP.
- Import dispatch schedule manually (CSV export is fine).
- Run the EMS in advisory mode: it recommends, humans approve.
- Collect data on actual charging behavior vs. plan.
Goal: prove the data flow works. Do not automate yet.
Phase 2: Scale (months 4-6)
- Expand to all chargers and vehicles.
- Automate the dispatch-to-EMS feed via API or scheduled export.
- Enable closed-loop control: EMS sends profiles directly to chargers.
- Add telematics integration for real-time SOC.
- Train drivers and dispatchers on the new workflow.
Goal: remove the human from the loop for routine scheduling.
Phase 3: Optimize (months 7-12)
- Tune TOU and demand charge strategies based on actual utility bills.
- Add predictive charging (e.g., pre-conditioning batteries in cold weather).
- Integrate with maintenance systems to flag charger faults before they strand vehicles.
- Review ROI and adjust targets.
Goal: turn the system from a scheduler into an optimizer.
Data requirements checklist
Before you start, confirm you can get these data feeds. Missing any one of them breaks the chain.
| Data element | Source | Format | Frequency |
|---|---|---|---|
| Vehicle departure schedule | Dispatch software | API or CSV | Daily |
| Vehicle SOC | Telematics | API (OBD or CAN bus) | 15 min or better |
| Charger status | Charger | OCPP 1.6J | Real time |
| Site power limit | Electrical panel | Static config | One time |
| Utility rate schedule | Utility tariff sheet | Manual entry | Annual or on change |
| Energy delivered | Charger | OCPP meter values | Per session |
If your telematics platform cannot expose SOC via API, you will need a workaround. Some fleets use a manual SOC entry at plug-in; others install aftermarket CAN loggers. Neither is ideal. Plan for this in vendor selection.
Common failure modes
These are the mistakes we see in the field.
1. Treating SOC as optional
Some operators charge every vehicle to 100% every night because they do not trust the SOC data. This wastes energy, degrades batteries faster, and inflates demand charges. If the telematics SOC is unreliable, fix the telematics first.
2. Ignoring the utility rate structure
An EMS that does not know the TOU schedule is just a timer. One logistics depot we worked with was charging at 18:00 because that is when vehicles returned. Their utility's peak rate started at 17:00. Shifting charging to 22:00 saved $1,800 per month on a 20-vehicle fleet.
3. Overloading the service panel
Smart charging cannot create capacity that does not exist. If your panel supports 200 kW and you install 400 kW of chargers, the EMS will throttle, but vehicles will still charge slower than promised. Size the service upgrade before you scale the charger count.
4. Skipping the pilot
Closed-loop automation without a pilot is how you get a fleet of stranded vehicles at 6 a.m. Run advisory mode for at least one full utility billing cycle.
5. Assuming all chargers speak OCPP equally
OCPP 1.6J is a minimum, but implementation varies. Some chargers support smart charging profiles only in certain firmware versions. Others drop the connection under load. Test the specific charger model with your EMS before you buy 50 of them.
ROI math: what integration actually saves
Here is a simplified model for a 20-vehicle delivery fleet. Numbers are illustrative; your utility rates will differ.
| Cost item | Without integration | With integration | Annual savings |
|---|---|---|---|
| Energy (off-peak) | $18,000 | $18,000 | $0 |
| Demand charges | $14,400 | $7,200 | $7,200 |
| Battery degradation (est.) | $3,000 | $1,800 | $1,200 |
| Manual labor (scheduler) | $12,000 | $2,000 | $10,000 |
| Total | $47,400 | $29,000 | $18,400 |
The demand charge reduction assumes the EMS flattens the peak from 250 kW to 150 kW. The labor line assumes one FTE spends half their time on manual scheduling. These are conservative estimates.
There is a second-order effect that is harder to quantify: vehicle availability. When charging is scheduled around departure times instead of guessed at, fewer vehicles leave the depot undercharged. One regional delivery operator we spoke with estimated they avoided two to three missed delivery windows per month after integrating dispatch with charging. Each missed window cost roughly $400 in penalties and rescheduling. That is $9,600 to $14,400 per year in avoided operational disruption, on top of the direct energy savings.
Integration also changes the conversation with the utility. When you can show a demand profile that stays below 150 kW, you are in a better position to negotiate rate structures or demand response incentives. Some utilities offer reduced demand charges for customers who commit to peak shaving. That negotiation is only possible when you have the data to prove your profile.
For a real-world reference, the Sinopec deployment we support runs 100+ sites and 400+ ports with 99.2% uptime. That uptime figure is not from the chargers alone; it is from managed operations that catch faults before they strand vehicles. Integration is what makes that level of reliability possible at scale.
Bottom line
Smart charging integration is not a software feature. It is an operational redesign. The four systems (dispatch, charging hardware, EMS, utility) must exchange data in a closed loop. OCPP 1.6J is the protocol that makes the charger legible to the EMS. The phased rollout (pilot, scale, optimize) prevents disruption. The ROI comes from demand charge avoidance, labor reduction, and battery life extension.
If you are evaluating EMS platforms, start with the data requirements checklist above. If your chargers cannot speak OCPP, or your telematics cannot expose SOC, fix those gaps before you buy software. For a detailed look at EMS selection criteria, read our EMS buyer's guide.
One logistics depot shifted charging from 18:00 to 22:00 and cut $1,800 a month off a 20-vehicle bill. That is the whole argument.
Need Expert EV Charging Advice?
Our team of engineers and sales specialists is ready to help you find the right solution.