See where the fleet is. Make sure they know you can.

What a dispatcher gets today

Fleet tracking lives where dispatch already works, rather than in a second telematics product. Open Fleet Map for the whole operation or keep the map under the radio in Dispatch.

• Where is it now. The latest position from every reporting unit, with current and delayed units separated at a glance
• What state is it in. Battery, speed, heading, altitude, accuracy and the age of the last fix appear with the selected unit
• Where has it been. Open a quality-filtered 24-hour trail; weak fixes and impossible jumps are named and omitted rather than joined into a route that never happened
• What happened out of coverage. The handset stores fixes first and backfills them after reconnecting, and the trail identifies the recovered points and any gaps that remain

How location data is handled

Location is more sensitive than ordinary operational data, so the useful answer is the exact boundary rather than an encryption adjective. Fleet positions are scoped to the organisation and available only to its signed-in administrators.

• The latest fleet view and one person's history are separate reads. Opening an individual trail writes an entry to the organisation audit log with the reader's name
• Retention is explicit and enforced. Administrators choose how many days to keep, up to one year; expired fixes are purged rather than merely hidden from the map
• Turning reporting off also closes the ingest. The handset stops collecting, and the server stores nothing from a device that has not received the new policy yet
• Raw evidence and the line on the map stay distinct. Provider, accuracy and capture time remain in the record even when an unreliable point is left out of the displayed trail

The honest limit: fleet coordinates travel over the encrypted connection but are not end-to-end encrypted like channel messages. push.tt stores the coordinates in a form the service can read to return the fleet view and trails. If server-blind location is a requirement, the current feature is not the right fit.

Where we draw the line, and why it is not marketing

This is continuous location reporting, and we do not disguise that. What push.tt refuses is covert reporting: a policy that suppresses the on-device disclosure is rejected by the server and by the handset independently.

• Company-owned and personal Android phones are separate policy choices. Personal and work-profile phones require their own tier to be enabled and location permission on the device; enabling managed handsets does not silently opt them in
• Visible on the device the whole time. Reporting runs as an Android foreground service with an ongoing indicator naming the organisation. A paid organisation can make it quieter, never remove it
• On-duty-only works. Signing out stops reporting immediately; an abandoned or disconnected handset stops on an expired duty signal rather than continuing indefinitely
• No covert mode. Hidden location reporting is a forbidden policy key, not an option omitted from the settings screen

The indicator and audit log do not make a deployment lawful by themselves. Employers still need the notice, lawful basis and proportionality their jurisdiction requires, especially when asking a personal phone to report.

The limits worth knowing before a pilot

The feature exists; these are the boundaries of the version that exists now.

• Android only today. Reporting is built into the Android radio and Device Manage apps; it is not available on iOS yet
• Battery and precision trade places. The reporting interval is configurable from 10 seconds to one hour, with GPS or coarse network positioning; faster and more precise costs more battery
• The handset is the asset. This tracks the phone and therefore the person carrying it. It is not an engine-connected telematics unit and cannot report ignition, fuel or diagnostics
• No indoor map or geofence events yet. BLE beacon-to-floor mapping, arrival alerts and departure alerts remain outside the current beta