Why default trip rules misread some fleets

A trip is a decision the software makes

A GPS tracker does not send trips. It sends coordinates, speeds, timestamps and device states, one point after another. The trip only exists once software applies rules to that stream: when movement counts as started, how long a stop must last before it ends one trip and begins another, and which small position shifts are only GPS drift and should be ignored.

Telematics defaults are usually written for a road fleet that drives between places and stops for a meaningful length of time. A stop threshold of a few minutes, a minimum movement speed, a minimum trip distance. These are sensible assumptions for vans and trucks. For plenty of operations they are simply wrong, and nobody notices until someone argues with a report.

Where the defaults break

• On a construction site, a loader relocating 50 to 80 meters between work areas at walking pace looks like noise to a standard filter. Discard those moves and the history quietly understates what the machine did all day.
• A courier's last-mile run may include dozens of stops of two to six minutes. If the stop threshold sits just under one of those dwell times, a single business route becomes several trips in the software, and utilisation and driver figures fragment along with it. Where connectivity drops out mid-route, missing data can fragment a trip just as effectively as a long stop, so gap handling matters as much as the stop threshold.
• Vehicles working in a yard or on a site never leave a small radius, so they never accumulate the distance or speed that default trip logic expects, and a full shift of real work barely registers.

The pattern is always the same: the fleet's own definition of a trip and the software's definition have drifted apart.

Change the smallest number of assumptions

When a fleet's trips look wrong, resist the urge to rebuild everything. Find the one or two rules causing the mismatch, perhaps the stop duration that splits courier runs or the movement threshold that erases slow equipment, and change only those. A small change is easier to validate, and far easier to explain six months later when someone asks why this account's trips behave differently.

Every threshold you relax admits more noise. Lower the movement limit far enough to catch a crawling loader and ordinary GPS drift starts to look like real trips too. So validate before you trust. Compare the new trip history against movements you know happened: spend a day with a driver or an operator, check that what RAAD recorded matches what actually took place, and cross-check totals such as distance against figures you know independently. An afternoon of validation beats any amount of theorising about a correct threshold.

From coordinates to answers

Even a correctly detected trip is still just a start point and an end point until it means something. A pair of coordinates is precise, but the dispatcher's real question is whether the truck went from the warehouse to the customer site.

This is what geofences are for. In RAAD's Track module, geofences turn named places into usable data, so trip and stop history can be read against the depot, the warehouse, the customer site or the fuel stop, and scheduled reports can carry that context instead of bare coordinates. The trip stops being geometry and starts describing the operation.

Trip rules carry the weight

Trip boundaries are load-bearing. When stop and movement detection is wrong, the error travels upward:

• Fuel checks in RAAD's Power module compare every fill against what the tank actually took, and fuel lost while a vehicle should have been standing still opens a case. Both depend on knowing when the vehicle really was stopped.
• Eco-driving scores are computed over trips. Split one route into six and each fragment inherits distorted acceleration and idling figures.
• Working hours, utilisation and maintenance planning inherit the same error, because they are all built on the same trips.

Fitting the trip definition to the operation is the foundation the rest of the analytics stands on.

Rules as a reusable asset

For the partners who resell RAAD under their own brand, a validated set of rules keeps paying off. The definition you proved out for one construction customer becomes the starting point for the next one, applied account by account, with each tenant's data kept separate under RAAD's multi-tenant structure.

AI belongs in this workflow the same way it belongs everywhere else in RAAD: it speeds the work, but knowledge of the operation still has to come from people. AI Insights reads every alert, holds back what does not need a person, and brings the rest with a reason and a proposed fix, and nothing touches a vehicle until someone approves it. The same discipline applies to trip rules. Software cannot know that a six-minute stop is a delivery unless someone tells it what a delivery looks like. Provide the operational context, keep a human on the approval, and let the machine do the sorting.

The test that matters

For any fleet, the test is simple: does the trip history match what the operation itself would call a trip? If a route, a shift or a machine's working day looks wrong in RAAD, the rules and reality have drifted apart. Fit the rules to the reality, validate against known movements, and the reports, fuel accounting and driver scores built on top inherit the correction.