A text box is a bad interface for somebody with one free hand
Typing is the wrong ask at exactly the moment you most need detail. The person reporting is outdoors, holding a phone in the rain, maybe walking away from whatever worried them, possibly frightened. What comes back is “man acting weird by gate 4”, and everything that would have made that report actionable, what he was wearing, which direction he went, whether anyone else was with him, stays in the reporter's head.
Speech does not have that problem. Fifteen seconds of talking carries more usable detail than two minutes of thumb-typing, and it costs the reporter almost nothing. So both public reporting pages now take a voice message and photos: the “report an issue” page behind your QR codes, and the private response page that every emergency alert links to.
The recording does not sit in a folder waiting to be listened to. It is transcribed on arrival, so it is searchable as text and readable at a glance. A short synopsis is written for whoever picks it up, what is being reported, where, and any urgency in the speaker's own words, along with flags for abuse or a message that is obviously not a real report. That summary is decoration on the recording, not a replacement for it: the audio is always there to play.
And then the clip goes where your team already is. An issue report lands in a transmit-only room you nominate when you build the form. During a live alert it lands in that alert's own room, arriving next to your team's own radio traffic, transcribed, in sequence. Nobody has to remember to go and check a queue, because the report reaches them on the channel they are already listening to.
Fifteen seconds of speech, handled six ways
What happens between somebody pressing record and an operator acting on it.
- Hold the button, say what you see
- Record up to 110 seconds in the browser, with no app and no account
- The mic is only ever asked for at the moment somebody chooses to record
- Clips upload as they finish, so every state on screen reads sent, never attached
- Add photos
- Up to four photos on an issue report, up to eight during a live alert
- Each one is downscaled on the handset before it leaves, so a weak signal still works
- Photos open in a gallery beside the report or on the incident's own media tab
- Transcribed on arrival
- Every clip is transcribed automatically, so a report is searchable as text
- A short synopsis is written for the operator: what is being reported, where, how urgent
- Warning flags mark abuse or a message that is plainly not a genuine report
- Straight into a voice room
- An issue-report clip lands in the transmit-only room you bind to the form
- During an alert it lands in that alert's own room, beside the team's radio traffic
- The sender is an external party record, never a user account somebody has to be given
- Offered after the status reply
- On a live alert the recorder appears only once someone has reported their status
- Nothing about media sits on the path between opening the link and "I need help"
- Per-alert switches decide whether photos, voice, or neither are offered at all
- Every photo and clip in one tab
- The Active Incident media tab lists every photo and clip as it arrives, newest first
- Filter by kind or by person, and play a recording inline without leaving the incident
- The list keeps polling on its own, so a dropped connection never freezes the view
A report page can afford to reject a bad submission, but a person trapped in a stairwell cannot afford to be turned away, so during an alert nothing on the page is allowed to fail.
The recording is saved before anything else happens
Mid-incident, the failure that matters is not a missing transcript. It is a person who recorded a message about where they are trapped, saw an error, and gave up. So on the response page the audio is stored and the record written before anything clever is attempted with it. Only then is the clip handed off to be transcribed and delivered into the room.
If the cluster is busy, or the summariser is unreachable, the clip is simply marked as awaiting its transcript and your team still gets a recording they can play. The reporter is never told, never blocked, and never asked to do it again. The same reasoning is why the response page carries no CAPTCHA at all: the cost of a challenge is somebody injured failing to reach “I need help”, and no amount of abuse prevention is worth that trade.
- During an alert the recording is stored first and processed second
- Transcription, summarising and delivery to the room are all best-effort decoration
- A busy cluster or an unreachable model marks the clip and moves on
- The person in the emergency is never shown an error or asked to try again
- A failed upload keeps the audio on the handset and offers one calm retry
- The response link is the credential: no CAPTCHA stands between somebody and help