How a ticket moves through the help desk¶
What happens between someone reporting a problem and the ticket closing. Useful if you're setting the help desk up, or explaining to a principal why tickets land where they do.
The six statuses¶
| Status | Means |
|---|---|
| New | Submitted, nobody assigned yet |
| Assigned | It has a technician |
| In progress | The technician is actively on it |
| Waiting on user | The technician needs something from the requester |
| Resolved | The work is done |
| Closed | Finished and filed |
Priority is separate from status: Low, Medium, High, Urgent.
1. Someone submits¶
Three ways in, all landing in the same queue: the web form, email to your support address, and text message if your district has SMS intake configured. Kiosk check-in and QR room tags are variations of the web form.
2. It gets assigned automatically¶
This is the part worth understanding. When a ticket comes in with a school attached, the help desk looks up which technician is assigned to that school under Admin → Tech Assignments and hands them the ticket. Status goes straight from New to Assigned.
That's the whole rule. One technician per school, no queues to claim from, no round-robin.
Two consequences:
- A ticket with no school stays New and unassigned until somebody picks it up. If tickets pile up unassigned, missing school values are the first thing to check.
- A school with no technician assigned behaves the same way. Admin → Tech Assignments is worth an audit at the start of a year.
If the assigned technician is out¶
If the technician the ticket would land on has an active out-of-office window and has named a backup, the ticket goes to the backup instead, and the original technician is added as a watcher so they can catch up when they return.
This only applies to automatic assignment. If somebody assigns a ticket by hand, that stands — an explicit choice is treated as deliberate, even if the person is out.
3. The clock starts¶
Every ticket gets a resolution deadline when it's created, based on your district's SLA setting.
- The default is three business days
- Weekends are skipped entirely
- The clock starts from the next business-hours start, so a ticket filed at 9pm Friday is treated as arriving Monday morning
- The deadline lands at the end of the business day, not at the same time of day it was filed
A ticket past its deadline is marked as breached. Breaches show up in reporting and on the oversight board.
Business hours are configurable for your district.
The number of business days cannot be changed from inside the help desk. There is no SLA settings page, and no SLA field under Admin — the value is set per district on our side. If three business days is wrong for you, contact us and we'll change it. Don't go looking for it in Admin; it isn't there.
4. Work happens¶
Technicians reply, add internal notes, log time, and change status. The distinction that matters:
- Public replies are emailed to the requester and visible to them
- Internal notes are staff-only and never sent to the requester
The interface labels which is which every time, on purpose.
5. Resolution and the survey¶
When a ticket is resolved, the requester can be asked a single thumbs-up / thumbs-down question with an optional comment. It's one click, which is the only reason people answer it.
6. Closed¶
Closed tickets stay searchable. Search by the ticket number on its own — 1234 works, you don't need to type TKT-01234.
Things that change the flow¶
- Automations (Admin → Automations) can reassign, escalate, or notify on rules you define
- Scheduled / recurring tickets create work on a schedule without anyone submitting
- Watchers get notified without being assigned
- Categories can carry custom fields, so a "New device request" can ask its own questions on the form