When a student conversation invokes a defined trigger, the agent calls an internal escalate tool. That tool:
Sends a structured email to a routing address on your team.
Logs the escalation in the constituent record.
Continues the student conversation without telling the student anything has been escalated (unless you have a rule where you want the student to be informed).
Escalation is a silent backend action. The student keeps getting a helpful response in real time.
When the agent escalates
There are two types of triggers:
Immediate (no back-and-forth first)
Student explicitly asks for a human
Acute distress or safety signals
Topic the agent isn't permitted to handle (e.g. financial aid specifics)
Knowledge base gap (agent can't answer confidently)
Tool or system error
After information gathering
Softer distress signals where context is needed before flagging (e.g. low pulse-check score, frustration with an advisor)
Topic-specific situations where the agent collects a few details first so the human inherits a useful summary
The exact trigger list is configured per partner based on what your team wants flagged.
Where escalations go (routing)
Routing is controlled by escalation keys. Each key maps to a recipient.
Forwarding inboxes: if a student email arrives via a forwarded inbox (e.g. [email protected] forwards into the agent), escalations from that thread route to the paired contact for that inbox instead of the default.
Useful for keeping topic-specific teams in their own queues.
What the escalation email contains
Each escalation generates a structured email to the routing recipient:
Subject: Student Escalation – [Key] – [Student Name] (Student Number)
Escalation details: key, issue category, summary of the concern
Student profile fields: configurable (e.g. Student Number, Advisor, GPA, Enrollment Status, current courses)
Interaction summary: what the agent said, what the student said, recent context
Topic-specific fields when relevant: (e.g. clinical course code)
Your team decides which student fields to include during configuration.
Follow-up after escalation
The agent can be configured to send one student-facing follow-up message on a time delay (typically 24–72 hours, although your team can define this):
If the student responds before the alarm fires → alarm cancels, no follow-up sent
If the student does not respond → one warm check-in message is sent
Only one follow-up is sent. The agent does not keep pinging (partner can adjust this to multiple replies, if desired).
The follow-up never mentions that an escalation happened. It just asks how the student is doing or whether they got the help they needed.
What the student sees
Nothing about the escalation itself. The agent:
Continues to provide helpful, on-topic responses
Does not say "I've escalated this" or "someone will reach out"
Does not promise a human response or a timeline (your team controls that side)