Limits of automated crisis detection
The crisis detector is a keyword match run twice — once in the student's app as they type, once on our server when they submit. It's tuned to over-flag rather than miss. Most of the time that is enough. This page is about the times it isn't, and what to do about them.
What the detector is good at
Direct language. Explicit words. The list is intentionally broad and biased toward catching more than it needs to. When a student writes something that plainly signals distress or danger, it fires reliably and pages your team across every configured channel.
What the detector can miss
Nuance is the honest answer. Specifically:
- Indirect phrasing. A student who writes "I just can't do this any more" or "I don't know how much longer I can keep going" may be in distress without using any of the words the detector recognises.
- Reserved cultural or personal expression. Some students are taught not to speak plainly about distress. The signal is real but the phrasing is oblique.
- Context that only a human catches. A message that reads fine in isolation might be alarming because the same student was fine last week and this week is not, or because of what they said in an earlier ticket, or because of what you know about their program.
- Positive-sounding language covering something worse. "I'm okay, don't worry, I just wanted to say thank you for everything" from a student who has not sounded this settled before is a pattern that keywords will never see.
None of this is a bug in the detector. It's a limit of what pattern matching can do. The system is not a clinical assessment tool, and it was never designed to be one.
Your judgment is the final safety net
By the time a ticket lands in your inbox — flagged or not — the platform has done what code can do. Whether it should have been flagged and wasn't is a question only a human can answer. You have the context the detector doesn't: the earlier conversation, the tone shift, the "this doesn't feel right" that predates the words.
If your judgment says a ticket should be crisis and the detector didn't flag it, escalate it. Open the ticket, hit Mark as crisis, add a short reason (optional, saved to the audit log), and confirm. The same fanout runs: email + Slack + SMS on whichever channels your institution has configured. The ticket pins to the top of everyone's inbox exactly as an auto-detected crisis would. The subject line tells the team that you made this call, not the detector — so no one tries to un-flag it as "just a false positive from the keyword list".
Escalation is one-way, by the same rule as automated escalation: the priority can only ever be raised, never lowered. That's deliberate. A ticket you raised, then thought better of, is one you respond to in the human conversation — not one you demote in the system.
The cost of paging your team for a ticket that turns out to be fine is a short handled conversation. The cost of not paging when you should have is unrecoverable. If you're unsure, escalate. That's what the action is there for.
Where the platform's responsibility ends
The platform detects and routes. Your institution's protocol decides what happens next: who calls, what they say, whether emergency services are involved. First Six never invents an escalation path or prescribes clinical wording — everything from the message a responder opens with to the after-hours contact number is your institution's, configured in Library → Help routes.
This is the boundary the vendor relationship rests on. First Six is a tool that surfaces signals and routes them to your team. It is not a mental health service, not a clinical assessment, and not a substitute for the human duty of care your institution owes its students. That duty stays with your institution regardless of what the platform did or didn't detect. When you use the platform, you use it as one input to that duty, not as a discharge of it.
The DRAFT internal-limits doc (pending counsel review) restates this position in the vendor-contract voice; the wording here is the operational version staff should carry in their heads.
Common questions
If I escalate a ticket that turns out to be fine, is that a problem?
No. Escalation triggers a page and a response; if the response concludes the ticket was not crisis, that's a handled ticket and the audit log records what happened. The bias is toward paging.
Can I un-escalate a ticket I flagged in error?
Not from the UI. Priority in this platform is one-way — auto or staff, the priority can only go up. If your judgment changes, respond to the ticket and note what you found in the internal note; the audit trail carries the whole conversation.
Should I escalate if I'm not sure?
Yes. That's exactly the case the action is designed for — the ticket is on your desk, the detector didn't flag it, and you don't have enough context to decide. Escalate, and use the responder call to gather the missing context.
Does the student get told I escalated their ticket?
Not automatically in this version. The escalation pages your team; it doesn't push a new crisis-resources prompt to the student. Reach out through the ticket reply as you normally would.
Related
The fastest answer is usually one question away.