What
A feed record that argues with itself is more common than most dispatch teams expect. The timestamp says the fix arrived four minutes ago, the confidence value sits at the low end of its range, and the movement state says stopped. Three fields, three different stories. If an agent commits a vehicle on that record and the car is actually thirty minutes away, the booking fails before anyone notices, and location data delay has already done its damage to booking conversion. So which field wins? None of them alone. What matters is the order you read them in, and where that reading turns a commit into a hold.Start with the timestamp, but not as proof of freshness. The timestamp tells you when the device last spoke, not where the vehicle is now. A recent timestamp with low confidence usually means the device transmitted under poor conditions, so treat the pair as a warning rather than a green light. An old timestamp with high confidence is the easier case. The position was probably accurate when it was captured, and the vehicle has simply been quiet since. That is the record most likely to mislead a dispatcher, because high confidence feels reassuring long after the fix has gone stale.Movement state should be read last, and read skeptically. Some devices report ignition state rather than true movement, so a vehicle waiting in a queue at a loading bay can register as stopped or idle for fifteen minutes while it is physically in service and inching forward. A stopped flag on that record does not mean the vehicle is free. It means the ignition circuit is off or the device has not detected motion. When movement state conflicts with a recent, high-confidence fix, trust the position and verify the state before you reassign anything.The practical triage order is this. Check the timestamp to see how long the feed has been quiet. Check confidence to judge whether the last fix was reliable when captured. Check movement state only to decide whether the vehicle is likely occupied. If the timestamp is old and confidence is low, stop. Do not commit. Flag the vehicle for a position check and hold the slot until a fresh fix lands. If the timestamp is recent and confidence is decent, a stopped flag alone is not enough to pull the vehicle out of rotation. That is the boundary between tuning your thresholds and redesigning the pipeline, because intermittent coverage across a core service area will keep producing conflicted records no matter how you set reporting intervals.There is a second cost that dispatch rarely sees. When a booking is committed against the wrong field and the vehicle arrives late, the telematics feed lags the fuel performance monitoring layer. Idle time gets recorded against the wrong route, cost reports drift, and the fleet looks inefficient in places where it was simply misread. Delayed geofence alerts make this worse, because a vehicle that arrived on time registers as late and the booking system marks the slot as missed. Two records, both wrong, both feeding the same cost review. Booking conversion and fuel cost control are not separate problems here. They break together.The last step is logging. Every time an agent commits a vehicle against a record where the fields disagree, that override should be written into the booking system with the fix timestamp it was based on. That single habit gives dispatch and the fuel monitoring team one shared reference when a report looks strange later. It also turns a string of individual judgement calls into a pattern you can actually measure, so the next decision about whether to tune, reconfigure, redesign, or replace rests on evidence instead of memory.