Crisis response, end to end
This guide follows a single crisis from beginning to end, across the student app, the server, the alert channels, and the staff console. It is the companion read for anyone who needs to trust that the path holds: wellbeing leads, IT, and the staff who will be on the other end of an alert.
The design principle throughout: surface immediate help to the student instantly, and reach a human reliably, with no single point of failure between the two.
1. The student writes
A student opens the help flow and starts typing. As they type, the app checks the text against a list of crisis signals (phrases that indicate danger to themselves or to others). If it sees one, immediate-support resources appear right there, before they have even sent the message.
The student can still send. Detection never blocks them or lectures them; it just makes sure help is visible at the exact moment it is needed.
2. The server has the final word
When the message is submitted, the server re-runs the same check. This is the trust boundary: the server can only ever upgrade a request to crisis, never downgrade one.
The student's app might be an old version, offline, or running with a tampered priority. Re-detecting on the server means a genuine crisis is caught regardless of what the client claimed. The request is recorded with its true priority no matter what.
The help request is saved to the database first, before any notification goes out. The record is the system of record; everything that follows is a nudge toward a human, not the source of truth.
3. The student sees immediate help
The moment the request is crisis priority, the student is shown a card of immediate-support resources: emergency services, Lifeline, Beyond Blue, plus any line the institution has added. The app records when those resources were shown and when the student acknowledged them, so staff later know whether the student has already seen them.
The message a student gets is calm and concrete: the request is on its way, and here are people to reach right now while they wait.
4. The alert goes out, every channel at once
This is the part built for reliability. The moment a crisis is detected, the team is alerted across every configured channel in parallel, not one after another:
- Email to the institution's crisis responders.
- Slack, if a crisis webhook is configured.
- SMS, to any crisis phone numbers on file.
They fire simultaneously on purpose. Email can stall silently in a queue and look delivered when it never arrived, so SMS and Slack never wait on it. Any one channel reaching a person is enough.
If every channel fails for a crisis, that becomes the loudest alarm in the system and is escalated immediately on the operations side. A crisis that could not reach anyone is treated as an incident in its own right.
5. The staff member responds
In the console, the crisis ticket does not wait its turn. It pins to the top of the inbox with a red border and the banner "Possible crisis. Please respond now", no matter how the inbox is sorted.
The responding staff member sees the full message and, importantly, whether the student was shown the immediate-support resources and acknowledged them. That tells them whether to lead with the crisis lines or move straight to a personal check-in. They acknowledge the ticket so the rest of the team can see it is handled, then follow the institution's crisis procedure.
6. What this guarantees
Put together, the path makes three promises:
- The student gets immediate help the instant a crisis is detected, independent of whether any staff member is reachable.
- A genuine crisis is recorded with its true priority, even if the client missed it.
- At least one human is reached, or the failure is escalated loudly.
For the staff-side detail, see what fires when a crisis is detected. For the student's experience, see the crisis path.
The fastest answer is usually one question away.