Emergency SOS for Housing Societies: Panic Button, Response & Audit
Emergency SOS for housing societies
An emergency in a residential society is rarely a failure of goodwill. Neighbours help. The failure is almost always routing: the person who needs help does not know which guard is on duty, the guard does not know which flat called, and the committee finds out the next morning from a WhatsApp thread with forty messages and no timeline.
An SOS system fixes the routing problem. One tap from a resident creates a structured incident that reaches whoever is on duty, records who acknowledged it and when, and leaves a record the committee can review afterwards.
This page covers what an SOS feature should do, how to roll one out without generating false alarms, and what to check before you trust it in a real emergency.
What a society SOS is actually for
It is worth being precise, because societies often buy the wrong thing.
An SOS button is not a replacement for 112, 108, or the fire brigade. It does not dispatch an ambulance. What it does is compress the gap between "something is wrong in B-704" and "the guard, the secretary, and the resident's emergency contacts all know it, and one of them has taken ownership."
That gap is usually five to fifteen minutes. In a medical event or a fire, that is the whole game.
The four incident categories
Categorising at the moment of raising matters, because the right responder differs:
| Category | Typical first responder | What the alert should carry |
|---|---|---|
| Medical | Nearest neighbour, then guard with lift access | Flat number, whether the resident can move |
| Fire | All guards, all residents in the affected wing | Location precise enough to find, wing-wide broadcast |
| Security | Guard at the relevant gate, committee | Whether the threat is inside or outside the flat |
| Other | Guard on duty | Free-text note |
A single undifferentiated "help" button forces every responder to call back and ask what happened, which costs the minutes you were trying to save. Four categories is about right — more than that and people hesitate at the moment they should be tapping.
The incident lifecycle
A usable SOS moves through explicit states, and each transition is recorded:
- Open. A resident raises the SOS. The system captures the flat, the category, an optional note, and — if the resident permits location access — coordinates. Notifications fan out immediately.
- Acknowledged. A guard or committee member takes ownership. This is the critical state: it tells everyone else that someone is on it, and it starts the clock on response time. Until somebody acknowledges, the alert should keep escalating.
- Resolved. The incident is closed with a short resolution note describing what actually happened. Without the note the record is useless three months later.
- False alarm. A separate closing state, not a variety of "resolved". You need to be able to count these separately, because a rising false-alarm rate is the leading indicator that residents have the button somewhere they keep hitting by accident.
Keeping "false alarm" distinct from "resolved" is a small design decision that pays off at review time. If both collapse into one bucket you cannot tell a well-drilled society from a noisy one.
Emergency contacts belong to the flat, not the app
The most common gap: the system alerts guards, but nobody thinks to call the resident's son who lives twenty minutes away.
Store one or two emergency contacts per flat — a label and a phone number is enough. Elderly residents living alone are the reason this feature exists. When an SOS is raised from that flat, the responder should see the contacts on the incident screen without hunting through a directory.
Keep the list short and keep it current. An emergency contact list that was accurate in 2023 is worse than none, because it creates false confidence.
Rolling it out without a false-alarm problem
Societies that switch on SOS and announce it society-wide the same day almost always get a bad first month. A slower rollout works better:
- Pilot one wing or tower first. You will discover the specific ways your residents misfire the button, and you can fix the placement before it annoys everyone.
- Run a drill, and mark it as a drill. A good system has an explicit drill flag so practice incidents are recorded but excluded from response-time statistics. Drill on a weekday morning, when your weakest staffing usually is.
- Brief the guards before the residents. If the first real SOS reaches a guard who has never seen the screen, the feature has failed regardless of how good the software is.
- Agree an acknowledgement target. Ninety seconds is a reasonable starting point for a manned gate. Publish it, then measure against it.
- Tell residents what it is not. Explicitly: this does not call an ambulance. Put the actual emergency numbers on the same screen.
What the committee should review
Once a quarter, look at four numbers: total incidents, median time to acknowledge, median time to resolve, and false alarms as a share of the total. Present them at the AGM alongside the security report.
This is where the audit trail earns its keep. If a resident later says "I pressed the button and nobody came," the society should be able to produce the incident, the timestamps, and who acknowledged it. If the record shows nobody acknowledged for eleven minutes, that is a staffing problem you now have evidence for — which is considerably more useful than an argument.
How this works on Plinth
Emergency SOS is part of the Safety suite. Residents raise an incident from their own screen; guards and committee members see it on the incident desk.
Every action goes through a controlled server-side function rather than a direct database write, so the incident timeline cannot be edited after the fact. Each transition — raised, acknowledged, resolved, cancelled — writes both an event on the incident and an entry in the society's append-only audit log. Incidents are visible only within your own society.
Notes are capped at 500 characters to keep them scannable, location is optional and only captured with the resident's permission, and drills are flagged so they never pollute your response-time figures.
Frequently asked questions
Does an SOS button call the police or an ambulance? No. It alerts people inside your society — guards, committee, and the flat's emergency contacts. Always call 112 (or 108 for an ambulance in states where it operates) as well. Treat the two as parallel, not alternatives.
What stops residents raising false alarms? Category selection and a confirmation step remove most accidental taps. The rest is cultural: track the false-alarm rate, and if one flat is responsible for most of them, have a quiet word rather than disabling the feature.
Can a resident cancel their own SOS? Yes, and they should be able to. An accidental tap that cannot be cancelled trains people not to use the button at all. The cancellation is still recorded.
Does it work if the resident has no mobile data? The app needs a connection to raise the incident. This is the honest limitation of every app-based panic button, and it is why the physical intercom and the gate phone should stay working.
Who can see a raised incident? Guards on duty and committee members with the safety role, within your society only. Residents see their own incidents.
Step-by-step guides
Related: guard patrol and QR checkpoints · child and senior safety alerts · society security guidelines checklist
Get Plinth in your inbox
Monthly digest of governance tips and product updates.