push.tt / Solutions
In beta

A dispatch position, not a phone on a desk

Every channel on one screen, the floor in one glance, and the fleet on a map underneath it. Push to talk with the space bar.

Try for free Contact us
In beta. The dispatch position ships and is in daily use, with three gaps named below rather than left for you to find. It is a real push-to-talk client — same socket, same frame format, same encryption as the handsets — not a viewer bolted onto the console.

One exchange, drawn with the console's own states and colours. The dispatcher never picks up a handset. Map data © OpenStreetMap contributors.

One screen for someone whose whole job is the radio

A dispatcher works in a browser all shift. Making them pick up a handset to answer the radio was the single biggest thing missing, and this is what replaced it.

  • Monitor several channels at once — join what you need, leave what you do not, and see how many people are on each
  • Hold to talk with the mouse or the space bar; the talk control can float over the map if you would rather watch that
  • Radio tones on transmit and receive, because the talk-permit tone is what tells you the floor is actually yours
  • Server-side floor control, exactly as on the handsets: one speaker holds a channel at a time
The dispatch position: three channels joined, the fleet on the map, and the channel log alongside

The fleet, where the dispatcher is already looking

Position is not a separate product with its own tab. It is the ground the dispatch screen is built on, so "where is Truck 3" and "talk to Truck 3" are the same glance.

  • Last known position per unit, with accuracy, battery and how long ago it reported
  • Units only appear when a handset is enrolled in Device Manage with location switched on — an empty map outside working hours is the feature working, not a fault
  • Live video from the scene alongside the map, so several people can broadcast while you keep talking
  • Voice and text in one channel log, with any stored transmission replayable from the row

Why transcripts change the shape of the job

Voice is fast to send and slow to consume. A dispatcher can read six transcripts in the time it takes to listen to one message, which is what lets one person hold more channels.

  • Transcription runs on the sending device, so the transcript is encrypted with the message
  • That means the dispatcher gets scannable text without us gaining the ability to read your traffic
  • Where the sending device cannot transcribe, the row says so rather than silently showing nothing

The three gaps, named

These are the limits worth knowing before you put a desk on it, and the panel surfaces each one in place rather than failing quietly.

  • Each browser needs its own key grant on encrypted channels. Keys are sealed per device, so a newly opened dispatch position holds none until a handset that already has them re-seals them to it — done on the phone, under Profile → Accounts. Until then those channels read "waiting" instead of playing silence
  • Opus playback needs WebCodecs — Chrome, Edge, Safari 16.4+ and recent Firefox. Where it is missing the stream is reported as undecodable rather than played as noise. The console always sends PCM16, which every handset understands
  • No shared queue or workload analytics yet. Several dispatchers can each run a position, but they cannot yet divide one inbound queue between them, and there is no reporting on peaks or resolution times

Tell us what your desk actually needs

Dispatch is the area where operations differ most. The position exists now, so the useful conversation is which of the gaps above is the one blocking you.

Get in touch