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, and watch the screen
"Real-time" is used loosely. Ask for the number, then watch the map during the demo. A vehicle that jumps between positions every two 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.
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.
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.