THE DIRECT ANSWER
The decision to start with
Validate a geofence against the operational place you mean, the recorded positions you receive and the action your team will take. Test entry, exit and boundary cases on representative vehicles before relying on an arrival or departure event.
Who this is for: Dispatchers, depot managers and implementation teams evaluating location-based workflows.
Define what arrival means for your operation
A map boundary is a rule about recorded positions. It does not establish that unloading began, that a driver met a customer or that a delivery was accepted. Decide whether the event you need is entry to a yard, arrival at a gate or presence at a loading area. Write the intended business meaning beside the boundary name.
Walk through the normal approach and departure routes with the site team. Note the public road, queue, neighbouring premises and permitted parking. A boundary that includes an adjacent road may capture passing vehicles; a boundary that excludes a normal waiting area may miss a visit your dispatcher considers relevant. Keep the operational definition separate from the software rule.
Confirm how the proposed setup creates events
Ask whether the boundary is evaluated in the tracker, in the platform or in another integration. Confirm which position records it uses, what counts as a valid fix and whether entry and exit are separate events. Record supported shapes, delays, dwell rules and boundary tolerance only after demonstration; names and settings differ between implementations.
Check the source of the displayed event time and whether delayed records can create an event after the vehicle has already left. Agree on the time zone used in the review. Do not assume that a fresh notification proves a fresh position. If the required fields are unavailable, mark them unknown and agree how dispatch will corroborate the event.
Allow for positioning and reporting limitations
GPS.gov explains that positioning can degrade around buildings, bridges and trees. A narrow boundary at a covered gate therefore needs testing in the actual reception environment. A drawn map outline should not be treated as an exact physical measurement or a guarantee of where the vehicle was.
Manufacturers can apply their own checks before accepting coordinates. Geotab documents validity checks for its GO devices; those rules are an example, not SafarTrak thresholds. Ask your provider about the actual tracker and configuration. Reporting cadence, power-saving behaviour and connectivity also need checking: a short visit can occur between recorded positions. Avoid selecting a universal radius or timeout without evidence.
Use a repeatable acceptance test
Create a small test sheet before the pilot. Include a normal arrival, normal departure, a vehicle passing outside the site, permitted waiting near the boundary and a safe parked period near the edge. Repeat meaningful cases on the device and vehicle groups you intend to deploy. The test is an operational review, not permission to interrupt safety-critical work.
For each case keep the agreed ground observation, its time zone, available position and event timestamps, expected result, observed result and owner. Use your normal authorised dispatch record; the worksheet should not collect unnecessary driver identity or precise historical location. Preserve contradictory evidence rather than editing the log to fit the expected result.
Investigate misses and repeated alerts separately
A missing arrival and repeated entry events need different investigations. For a miss, check whether there was a usable recorded position inside the boundary and whether the rule was active. For repeated alerts, review points around the edge, the boundary definition and any demonstrated tolerance or dwell controls. Check permissions and notification delivery separately from event generation.
Change one meaningful setting at a time, record the reason and repeat the affected test. Keep a dated before-and-after record. If reliable acceptance cannot be demonstrated, use a confirmed dispatch check for the operational decision and keep the software exception open. An alert should prompt a review, not automatically settle a customer dispute.
Agree ownership and review the boundary
Assign an owner for the site definition, an owner for configuration and a dispatcher responsible for responding. Record where an event is visible, who receives a notification and how an unavailable or delayed record is handled. Recheck after a depot layout change, device replacement or material configuration change.
Bring the worksheet and your vehicle/device inventory to a SafarTrak deployment discussion. Ask the team to demonstrate whether the proposed setup supports your required location workflow. Confirm the actual coverage and agreed response process; this guide describes a validation method and does not promise a particular geofence feature for every deployment.
Put the criteria side by side
Swipe or scroll sideways to view every column.
| Test case | Evidence to keep | Decision to record |
|---|---|---|
| Normal arrival and departure | Ground observation and available record/event times | Correct operational meaning and owner |
| Pass outside the site | Approach route and observed event | No unrelated visit classified |
| Waiting near the edge | Recorded positions and repeated/missing events | Boundary or rule needs adjustment |
| Delayed or unavailable data | Available timestamps and dispatch confirmation | Fallback response and unresolved gap |
ILLUSTRATIVE EXAMPLE
A passing vehicle mistaken for a depot visit
Illustrative scenario: a depot boundary extends over the public access road. A passing vehicle produces an entry event, but the dispatcher has no gate observation. The team records the mismatch, reviews the boundary against permitted routes and repeats the pass-outside test. It accepts the revised rule only after normal arrival and departure still work. This is a hypothetical method, not a SafarTrak customer result.
Common questions
What radius should every fleet use?
There is no universal radius suitable for all sites. Base the shape and boundary on the operational area, reception environment, recording behaviour and demonstrated test results.
Does a geofence event prove delivery completion?
No. It describes a configured location event. Delivery acceptance needs the separate evidence required by your operating process.
Should every alert lead to a driver warning?
Review the event, timestamps, positioning limits and operational context first. Agree an investigation process and avoid treating an unverified alert as proof of fault.
Sources and further reading
- GPS.gov: GPS accuracy
Primary explanation of reception and positioning limitations; not a SafarTrak accuracy guarantee.
- Geotab: GO device GNSS precision summary
Manufacturer example of coordinate validation. Its thresholds do not establish SafarTrak device behaviour.
- Learn Fleet: geofencing
Plain-language definition to use before the acceptance review.
- Blog: GPS position timestamps
Related editorial explanation of position time and message freshness.
Published by SafarTrak as general operational guidance. Examples are illustrative; confirm vehicle, device and workflow coverage for your deployment. How we publish our guides.
Download the review sheet (CSV)