School bus GPS tracking: how to tell real-time from a position log

5 min read

Every school ERP claims GPS transport tracking. Most of them mean a table of coordinates written every few minutes that a member of office staff can open a report to read.

That satisfies a tender requirement and helps nobody. Here's how to tell during a demo which one you're being shown.

Ask who can see it

This one question separates real tracking from a compliance feature faster than anything else. If the answer is "the transport in-charge can view it in the admin console", you're buying a log.

The person who needs the information is the parent standing at a stop wondering whether to keep a six-year-old outside in the rain. If they can't see it on their phone, the feature has not reduced a single phone call to your office — which was the actual problem you were solving.

Ask for the refresh interval — then ask what happens when nobody is watching

"Real-time" is used loosely. Ask for the number, then watch the map during the demo. A vehicle that jumps between positions every couple of minutes is being polled; one that moves continuously is being streamed. For a parent deciding when to walk to a stop, a two-minute-old position on a bus in traffic can be most of a kilometre wrong, so the number matters.

But press further, because a continuously moving dot still requires a parent to sit and watch it. The better question is what the system does on its own: does crossing a stop raise an event, and does that event reach the phone of the families at that stop — and only them? A vendor with a beautiful streaming map and no alert has built something to look at. A vendor whose map is a last-known position but who tells you the moment the bus reaches your stop has solved the thing you were actually asking about.

Ask both. The honest answer to the first question is a number, and the honest answer to the second is a demonstration.

Ask whether stops are records or just pins

A route should be a structured record — an ordered list of defined stops — not a freehand line on a map. That's what makes arrival and departure into events you can act on, rather than something a driver phones in.

Geofencing around each stop is what turns "the bus is somewhere near here" into "the bus has reached this stop". Without it you have a moving dot and no events.

Ask what happens to the fee when a route changes

Transport is usually a billed component. If your transport module and your fee module don't know about each other, every route change becomes a manual billing correction — and the corrections that get missed are the ones you hear about from a parent.

Ask to see a student moved between routes, and then ask to see their fee. If that takes two systems, you've found a source of ongoing work.

The short version

Ask who can see the map, ask for the refresh interval and watch it, and ask what happens to the fee when a route changes. Three questions, and they're hard to answer well without a real implementation.

More from the blog

Book a demo