What
Start small, and start on purpose. Pick two vehicles for each major vehicle type and duty cycle in your mix. So if you run light vans, rigid trucks, and long-haul units, that is six test vehicles, not one. Do not just grab the newest truck in the yard, because a clean late-model unit tells you very little about the rest of your fleet. The goal is to find out whether the vehicle telematics you already own can genuinely deliver vehicle health diagnostics, or whether they only report position and ignition state. That single question decides whether you are tuning rules or replacing hardware.Next, get a known fault to appear. You want a real fault code, not a simulated one, so the whole path gets tested end to end. Pull an existing stored code if one is there, or ask a technician to trigger something benign and safe that will set a code and clear cleanly. Write down exactly what appeared on the vehicle side, including the code itself, the time it was set, and any parameters that should travel with it, such as engine temperature, coolant pressure, or odometer reading. That context matters. A fault code that arrives stripped of its surrounding detail is far less useful than one that arrives whole, because your team cannot tell whether it is a one-off glitch or the start of a pattern.Now confirm the unit can genuinely read the vehicle bus. This is a hardware and protocol question, not a checkbox in a settings menu. A device that reports location beautifully may have no ability at all to pull engine data, aftertreatment status, or battery voltage off the bus. Ask the provider directly which diagnostic signals are surfaced by default, which sit behind a paid tier, and which the unit simply cannot read. If a vendor cannot answer that plainly, treat it as an answer in itself.Then match what the vehicle produced against what landed in your fleet management software. Same code? Same timestamp, or close? Did the supporting parameters come through, or did you get a bare number with no story behind it? This comparison is your first pass or fail test. If the code shows up intact and on time, the depth is there and you are likely looking at a workflow problem, not a hardware one.Timing is the second test. Measure how long the fault took to reach the platform, and do it in the corridors where you actually drive, not in a demo yard with strong signal. Run the same test in your worst-coverage area, because that is where late or missing data will hurt you. Repeat it across two or three regions. If codes arrive quickly in one area and vanish entirely in another, that points to a connectivity gap rather than a hardware limit, and those are two very different problems with two very different price tags. Do not accept a best-case latency figure. Ask for a measured range, and test it yourself.One more thing worth doing while the units are installed: leave one on an idle vehicle for a week and watch battery voltage. Standby draw is hard to predict from a spec sheet, and a unit that quietly drains a parked truck is a cost you will discover the hard way.Now the fork in the road. If fault codes arrive intact but nobody acts on them, fix your alert routing and your work-order triggers first. That is the cheapest path, and it also proves whether the data itself is good before you spend anything. If codes arrive late only in particular corridors, revisit your connectivity plan before adding more alerts, since piling alerts onto stale data just creates noise. But if the units cannot read the vehicle bus at all, stop tuning. That is a replacement decision, and it should be phased by region rather than swapped out all at once. Before any of that, settle ownership questions too: who holds the diagnostic history, how long it is kept, what formats you can export, and what happens to that data if you change providers. The blog behind this guide notes that no recent platform or market updates were available from the supplied sources, so treat this as a vendor-neutral set of criteria you can apply to anyone. Get the outcome right first, meaning a fault reaching the right person fast enough to act, and let the hardware follow.