Project · Transport & logistics
Fleet visibility and exception control
Unifying four telematics platforms and a manual dispatch spreadsheet into one operational view for a 480-vehicle logistics fleet.
The operating problem.
A logistics operator had grown through acquisition. Each acquired business brought its own telematics provider, dispatch process and customer base. The fleet operated across four states, with roughly 480 vehicles and a mix of permanent drivers and subcontractors.
Dispatch maintained a spreadsheet that reconciled vehicle availability, driver assignments and customer commitments. Customer service relied on phone calls to depots to find out where a vehicle was. The data existed, but it was distributed across systems that did not share a common vehicle identity.
The business case was not a new transport management system. It was an operational view that could be trusted, plus a reliable exception process for the moments when the plan stopped matching reality.
The challenge.
The visible problem was fragmented technology. The underlying problem was a process that depended on individual compensation.
- Four telematics platforms used different vehicle identifiers, event models and update frequencies.
- Dispatch had no single view of vehicle availability, maintenance status and driver assignment.
- Customer service discovered late deliveries after the customer had already called.
- Subcontractor status was exchanged by email and phone, with no structured record.
What we found
The same vehicle could appear under three identifiers: the fleet number, the registration plate and the telematics unit ID. Reconciliation was manual and error-prone, which meant the dispatch spreadsheet was often out of date before the shift started.
Event latency varied from seconds to several minutes across providers. A single “real-time” view would have been misleading without showing data freshness and confidence.
Most operational pain came from a small number of exception types: unplanned stops, late departures, missing proof of delivery and vehicles approaching service intervals. These were the events worth automating first.
How the work was structured.
Each stage produced a decision or an artefact that the next stage could rely on.
Build a canonical fleet model
Define a single vehicle, driver, job and location model that could represent all four providers and the subcontractor fleet.
Ingest and normalise events
Build an event pipeline with source-specific adapters, schema validation, deduplication and a visible freshness indicator.
Create the operational view
A dispatch screen combining availability, location, job status and exceptions, with filters for depot, state and customer.
Introduce exception workflows
Rule-based alerts for late departure, unplanned stop, missing proof of delivery and service due, with an owner and escalation path.
Add partner access
A scoped subcontractor view for job status and document upload, replacing email-based updates.
Difficult problems and how we resolved them.
The delivery was not a straight line. These are the issues that required a design decision rather than a task.
Vehicle identity was inconsistent across every source.
We created a master vehicle registry with an explicit mapping table. The registry became the reference for all event normalisation. When a new provider was added, only its mapping needed to be configured; the operational model stayed stable.
Providers delivered events at different speeds and sometimes out of order.
The pipeline used event time rather than arrival time, with a watermark for late events and an idempotency key per source event. The interface showed “last updated” per vehicle so dispatchers could judge confidence rather than assume everything was live.
Exception alerts initially created noise.
The first rule set produced too many alerts because it treated every deviation as an exception. We worked with dispatchers to separate material exceptions from normal operational variation, added a short delay before alerting and introduced a daily review of false positives.
Subcontractors did not want another system.
The partner view was kept narrow: jobs, status, document upload and a single contact path. It replaced a phone call and an email, not a core subcontractor system. Adoption was voluntary in the pilot and became a condition of new contracts after the benefit was demonstrated.
The result in operational terms.
Measures were agreed with the client before delivery and compared against a baseline. The figures below are client-reported.
The operational view reduced empty running by improving visibility of vehicle availability and return loads. Dispatchers could see which vehicles were near a collection point and adjust allocation before the next shift.
Exception resolution improved because the alert included the vehicle, job, customer, last known location and the action owner. Customer service could answer a status question without calling the depot.
What we would do differently.
Every engagement produces lessons. A project page that only reports success is not useful to the next client.
- A canonical data model is more valuable than a perfect real-time feed; consistency beats false precision.
- Alert tuning is part of the product, not a configuration task to be completed at go-live.
- Partner adoption depends on removing effort for them, not adding a new reporting obligation.
These lessons have been incorporated into how we scope and run similar engagements. They are part of the reason the approach pages are specific about decision points and exit criteria.
The disciplines behind the result.
Projects rarely use one capability in isolation. The links below show where the work sits.
A canonical model is a governance asset.
The most valuable artefact in the fleet project was not the map. It was the canonical vehicle, driver and job model that allowed four telematics providers, a scheduling system and a subcontractor fleet to be understood in the same terms.
That model required business ownership, not just data engineering. Someone had to decide which identifier was authoritative, what “available” meant and how a late event should be represented. Those decisions made the operational view trustworthy and made future provider changes a mapping exercise rather than a new integration project.
Any organisation combining acquired businesses or multiple operational sources should treat the canonical model as a governance asset. It outlasts the dashboard and determines how quickly the next source can be added.
Have a similar constraint?
Tell us what is not working. We will help you define a first step that produces evidence, not just activity.