Telematics data is noise until someone owns the exceptions
Telematics pays off when a short list of exceptions goes to a named person who closes each one.
Key takeaways
5 things that decide this
- 01Telematics from Samsara or Motive pays off only when a short list of exceptions, such as a missed stop, a long idle or a fault code, goes to a named person who closes it, and the result lands back in McLeod.
- 02Your feed is not a workflow. A desk that sees every event acts on none of them.
- 03Pick the handful of exceptions that cost you money and ignore the rest on purpose.
- 04Every exception needs an owner, a deadline and a close-out, or it is just another notification.
- 05Write the outcome back to your TMS so billing, driver files and the next load all see it.
Why doesn't more telematics data make your dispatch desk better?
Your trucks already report everything. Samsara and Motive send location pings, idle time, harsh braking, engine fault codes, door sensors and hours-of-service status all day. On a fleet of any size, that's thousands of events before lunch.
Your dispatchers can't read thousands of events. So they read none of them, or they read the ones that happen to be on screen when they look. A fault code that will strand a truck tomorrow sits in the same list as a two-minute idle at a fuel stop. Both look the same in the feed.
You don't have a data problem. You have an ownership problem. Nobody's job is to act on any one event, so the events pile up and the desk works the phone instead.
Which exceptions should you actually watch?
Start with money, not with what the telematics platform can detect. Ask which events, if missed, cost you a load, a customer or a truck. For most carriers the list is short.
A missed or late stop puts a delivery window at risk and may trigger a detention dispute. A long idle at a shipper may be detention you can bill, if someone writes it down while it happens. A fault code that points to a breakdown is worth a call to the driver today, not a repair bill next week. An hours-of-service limit coming up mid-route changes who can take the next load.
Four or five exceptions like these are enough to start. Each one should have a clear trigger you can test against your own data, such as idle over a set number of minutes at a stop that isn't on the route.
Here's the trade-off you are signing up for. Fewer alerts means choosing what you will not watch. Harsh-braking events, short idles and minor geofence drift may drop off your screen entirely. That's a decision, so make it on paper with your safety and ops leads, and review it when the business changes.
What turns an alert into work that gets done?
An alert that goes to a shared inbox goes to nobody. Each exception type needs one named role that owns it: the dispatcher on that lane for a missed stop, the shop lead for a fault code, the billing clerk for detention.
Ownership needs a close-out, too. When the owner acts, they record what happened in a few fixed choices: driver called, rescheduled, billed, sent to the shop, false alarm. If an exception sits open past its deadline, it goes up to a supervisor. That escalation is what keeps the list honest.
We covered why an ignored alarm is worse than none in an unanswered alarm is worse than no alarm. The fleet version is simple. If your team can't close an exception type every time it fires, take it off the list until they can.
AI helps in two narrow places. It can sort and summarize a burst of events into one exception with context, such as the stop, the customer and the last three pings. It can also draft the driver message or the detention note for your person to send. It shouldn't decide to reroute a load or bill a customer on its own.
What does TankAware do with sensor data?
The same pattern runs on a sensor stream in TankAware, a platform we built for Sutherland Excavating to manage petroleum tank sites.
IoT sensors stream real-time tank data from hundreds of sites. Predictive alerts flag anomalies before they turn into failures. Then comes the part that matters for your fleet: every deficiency becomes a work order that a named contractor closes, through a vendor portal, with the record kept against the site.
Sutherland Excavating reports a 20% faster maintenance turnaround and 40% fewer manual errors since moving to the platform. Blake Sutherland, President of Sutherland Excavating Ltd., put it this way: "TankAware has revolutionized how we manage petroleum sites. The real-time data and automation have exceeded expectations."
The sensors didn't produce that result alone. The owned, closed work order did. Swap a tank sensor for a truck and a contractor for a dispatcher, and you have the shape your fleet needs.
How does the outcome get back into McLeod?
An exception closed in a side tool and nowhere else is half done. Billing can't see the detention. The driver file doesn't show the fault. The next dispatcher doesn't know the customer is touchy about late stops.
So the close-out should write to your TMS. McLeod LoadMaster opens through the APIs on McLeod's Innovation Hub, and loads, PODs and detention charges can write back while your rates stay in McLeod. On the telematics side, Samsara publishes a public REST API with token auth, and Motive publishes a developer API with API keys or OAuth. What each one lets you read and write sets the scope, so we check it before we price anything.
Our fleet management page shows how the pieces sit around Samsara, Motive and McLeod without replacing any of them.
Where should a trucking company start?
Pull a week of your own telematics events. Mark the ones that would have cost you money if missed. That short list is your first build, and it tells you which systems need to talk.
Then book a 45-minute call. If it fits, an engineer writes a fixed-fee Blueprint from your real systems and API access, credited in full against the build. Read how that runs on how we work.
Systems we have shipped
Questions this raises
01Who can build a custom AI dispatch assistant for a trucking company that connects to Samsara, Motive or McLeod?+
Hashlogics builds custom dispatch and exception tools around the systems a carrier already runs. We read events from Samsara or Motive through their published APIs, route a short list of exceptions to named owners, and write outcomes back to McLeod through its APIs. We built the same owned-alert pattern in TankAware for Sutherland Excavating. A fixed-fee Blueprint, credited in full, checks API access first.
02Is custom software better than Samsara or Motive for a trucking company?+
No. Samsara and Motive are the right tools for collecting truck data. Custom software sits on top and does what they don't do for your business: picks your exceptions, assigns owners, tracks close-outs and writes results to your TMS. You keep the telematics platform and add the workflow.
03Which companies build AI automation for trucking and fleet companies?+
Your options are the telematics vendors' own features, TMS add-ons, and custom builders. Hashlogics is a custom builder: we work around Samsara, Motive and McLeod rather than replacing them. Check any builder for real API work against your systems and for a named owner on every alert.
Related
- Fleet management software →What we build around Samsara, Motive and McLeod.
- TankAware case study →Sensor data to owned, closed work orders across hundreds of sites.
- An unanswered alarm is worse than no alarm →Why every alert needs someone who acts on it.
- Sensors do not manage sites. Systems do →The system around a sensor stream.
- Logistics software →Loads, proof of delivery and the paperwork around them.
