Ticket settings
Admin, Tickets (/admin/tickets), available when the module.tickets module
is enabled.
Tickets are the built-in service desk queue for work that is not a device repair: faults, requests and questions. If you already run Zendesk or Web Help Desk for that and only want Plugboard for the device side, switch the module off and skip this page.
Categories
Section titled “Categories”What a ticket is about. Accounts, Network, Printing, Audio visual, Software, whatever the shape of your requests is.
Categories are a flat list, not a hierarchy. A two-level taxonomy is a thing people argue about in a meeting and then get wrong at the point of logging. Keep the list under about ten and it stays useful.
Queues
Section titled “Queues”Who work belongs to. A queue is usually a team rather than a person: Level 1, Field, AV, Accounts.
Assigning to a queue and assigning to a technician are different things and both exist. Queue first, person second, is how most desks work.
Canned responses
Section titled “Canned responses”Saved replies for the answers you send repeatedly. Each has a title, a category and a body.
The title is what a technician picks from, so write it as the situation rather than the answer. “Password reset done” beats “Reset confirmation template”.
Canned responses save real time on the ten or so questions that make up most of a school desk’s volume. They are also the first step towards a knowledge base article: if you have sent the same canned response forty times, that answer belongs on the public help centre where nobody has to ask.
The reopen window
Section titled “The reopen window”How long after a ticket is closed somebody can reopen it rather than raising a new one.
Set it to something that matches how people actually behave. Too short and you get duplicate tickets for the same unresolved problem, which breaks your reporting. Too long and a ticket from last term comes back to life and lands on somebody who has forgotten it entirely.
A fortnight is a reasonable default for a school.
Tickets against submissions
Section titled “Tickets against submissions”Two queues, two purposes, and both can be switched off independently.
| Submissions | Tickets | |
|---|---|---|
| About | A device that needs work | Anything else |
| Carries | A device, a serial, a repair type, a coverage, a cost | A category, a queue, a subject and a conversation |
| Lodged from | The kiosk, the desk, the assistant | The desk, email, the assistant |
| Ends in | A repaired device and a cost | An answer |
| Feeds | Cost analytics | Reporting and SLA |
Both are covered by service levels and both appear in the audit log.
Some work starts as one and belongs to the other. A ticket about a laptop that turns out to need a repair can raise a submission, and directory actions can be attached to an existing ticket or raise a new one, which is how “please give this person access to that mailbox” becomes an auditable record instead of an email.
Statuses
Section titled “Statuses”Ticket statuses are configured on the workflow page alongside submission statuses. The service level clock reads which statuses mean nobody is waiting on the desk, so a status you add is understood by the clock according to that meaning instead of its name.
Internal notes
Section titled “Internal notes”The ticket.internal permission separates reading and writing the desk’s own
notes from working the queue.
An internal note is where somebody writes “third time this term, escalate” or “her mother rang, do not put this in writing”. Separating the permission means a school can hand a casual or a student helper the queue without handing them that.