Triage

The inbox is where help requests land. TriageThe skill of moving each help request to the right next step quickly, rather than solving everything yourself. is the skill of moving each one to the right next step quickly, rather than solving everything yourself. Done well, it keeps the queue honest: the serious things get a person fast, and nothing routine quietly ages out of view. Here is how to read the inbox and work it.

Priority and order

Every request carries a priority: normal, urgent, or crisis. Crisis tickets pin to the top no matter how the list is sorted, so the most serious thing is always in front of you. Work down from there.

The reason crisis pins rather than just sorts high is that sort order is something you can change. Pinning means no view, filter, or accidental re-sort can ever bury a crisis below routine work. You never have to remember to look for it; it is always already at the top.

New requests show their age instead of a generic "new" label (for example "3h old"), and the age tints from muted to amber to red as it climbs, so a request that has been sitting untouched is obvious at a glance. The colour is doing the work a mental note otherwise would: you can scan the column and see what is waiting without reading a single subject line.

Reading the SLA

Each ticket carries a first-response target. The SLAService-level agreement: the response-time target a ticket is measured against. pill tells you where it stands against it. It measures how long the student waits to hear from a human, not how long the request takes to resolve. A hard problem that takes a fortnight to sort out is fine; a student waiting three days to find out anyone read their message is not.

The target depends on the request's priority:

There are four pills, and a resolved ticket shows none:

• Reply in 3h: nobody has replied yet and you are still inside target. The number counts down.
• Overdue · +45m: nobody has replied and the target has passed. The number is how far past. These need attention next, after crisis.
• Met SLA · 11m: the first reply went out inside target. The number is how long the student actually waited, so 11m means they heard back eleven minutes after asking.
• SLA breach · +2h: the first reply went out, but late. The number is how far past target it was.

The first two are live and keep moving. The last two are history: once a first reply exists the pill records what happened and stops changing, so a breach stays visible rather than quietly resolving itself.

The goal is not to clear the board instantly; it is to make sure nothing urgent quietly ages past its window. A full inbox where everything is on track is in better shape than a near-empty one with two overdue tickets buried in it. Read the pills, not the unread count.

When a non-crisis ticket reads as crisis

Auto-detection catches direct language; it can miss nuance, indirect phrasing, or context that only a human would recognise. If a ticket reads as crisis to you and the priority pill isn't there, escalate it: open the ticket drawer, click Mark as crisis, add an optional reason, and confirm. The escalation runs the same fan-out as auto-detection: email to everyone holding the respond-to-crisis permission (built-in roles and custom ones alike), plus Slack or Teams where your institution has connected them, with wording that makes clear it was a staff judgment call, not the detector. Escalation is one-way; priority can only ever move up. Content editors don't have this action; institution admins, support responders, platform owners, and any custom role granted the respond-to-crisis permission do. The full boundary is on the limits of automated detection.

Assigning and handing off

Pick up a ticket with Assign to me, or assign it to a colleague through the assignee picker (search by name or email). If you reassign, add a short handoff note so the next person has the context without re-reading the whole thread.

The handoff note matters more than it looks. Without it, the next person has to reconstruct what you already know, which costs time the student does not have and risks two people repeating the same step. One sentence on what you have done and why you are passing it on is usually enough.

The ticket's timeline records every assignment and note, so the history of who held it and why is always there. If a ticket bounces between people, the timeline is the source of truth for what has already been tried.

Working a ticket to done

A ticket moves through four states: New → Acknowledged → In progress → Resolved. Acknowledge early; it signals to the rest of the team that someone has eyes on it, even before you have acted. Without that signal, two people can unknowingly pick up the same ticket, or everyone can assume someone else has it.

1. Acknowledge

   The moment you take a ticket, acknowledge it. This is the cheapest, most useful action in the inbox: it stops duplicate effort across the team.

2. Move to in progress

   As you work the request, the state reflects that it is actively being handled rather than just seen.

3. Resolve deliberately

   Close only when the student has actually been looked after. Resolving asks you to confirm, because resolved means handled, not merely read.

The pulse line

At the top of the inbox is a one-line cohort summary (for example "Week 3: 87 of 120 replied. 42% thriving, 8% wobbling, 3% asking for a hand"). It is there to frame the queue: a heavy inbox in a week where the cohort is wobbling reads differently from the same inbox in a steady week. Click it to open the full Pulse view.

This is context, not a task. The line will not tell you which ticket to open next, but it changes how you weigh the queue you are looking at. A busy inbox during a wobbling week is worth slowing down for; the same volume in a steady week is usually just normal traffic.

Troubleshooting

Common questions

Next steps

Related