Most district help desks fail in one of two ways. The first is that nobody uses it: teachers email the tech they like, stop them in the hallway, or put a sticky note on the cart, and the "help desk" is a ticket system with eleven tickets in it. The second is that everybody uses it and nothing links to anything: 900 tickets a year that say "Chromebook broken," none of them tied to a device, so you cannot tell which model breaks, which building generates the work, or how long a repair takes.

A help desk that works is one people can reach from wherever they already are, that captures the device and the building without asking, and that produces three numbers you can use in a budget meeting. This is how to set one up, whether you are one person or a team of five, and it applies equally to a facilities queue and an HR queue, because the shape of the work is the same.

Decide the queues

A queue is a team with its own inbox, statuses, and form. Start with three:

  • Technology: devices, accounts, Wi-Fi, projectors, software.
  • Facilities: HVAC, custodial, keys, grounds, event setup.
  • HR (if you run it for them): onboarding and offboarding, benefits questions, forms.

Keep them separate. A facilities request in the technology queue is a request nobody owns. But keep them in one system, because the same teacher files all three, and because the superintendent's question is "how long does it take to get anything fixed around here," not "how long does IT take."

Each queue gets its own request form (facilities needs a room and a time window; technology needs a device), its own statuses, and its own notification address. If the queue has more than one person, give it assignees; if it is one person, skip assignment and just work the list.

Intake: meet people where they are

The reason teachers email the tech they like is that email is where they are. Do not fight that; route it.

Email-to-ticket. Give each queue an address (it@district.org, facilities@district.org) that turns any email into a ticket in that queue, with the sender as the requester. Replies to the ticket's notification go back onto the ticket. This alone moves most hallway requests into the system, because "email it@ and I'll get to it" is an answer a teacher accepts.

A public request form for people without accounts: substitutes, parents in a facilities context, a coach booking the gym. The form asks only what the queue needs. Technology: what is wrong, which device (see below), which room. Facilities: what, where, by when.

A QR label on every device that opens the technology form with the device already identified. A student scans the label on a cracked Chromebook, types "screen cracked," and the ticket arrives linked to that serial, that school, and that student's assignment. No login, no asset number to copy, no "which one is it" email. Edventory prints these labels from the device list; on a lighter setup, a Google Form with a URL parameter for the serial, printed on the label, gets you most of the way.

In-app for staff who are already in the system, with the device picker and the room picker prefilled from what is assigned to them.

Whatever the channel, every ticket lands in the same queue with the same fields. The channel is a convenience for the requester, not a separate pile for you.

A technology ticket that is not linked to a device is a support call. A ticket that is linked to a device is data. The link is what lets you answer, at the end of the year, "which model breaks," "which building generates the work," and "what did repairs cost." Make the link mandatory where it makes sense (a repair ticket must name a device) and easy everywhere else (a picker filtered to the requester's assigned devices).

Two things follow from the link. When a device goes into a repair ticket, its status in inventory should change to "in repair" without anyone editing the device. And when a loaner is issued against that ticket, the loaner's checkout should carry the ticket number, so closing the ticket prompts the loaner's return. In Edventory both happen automatically; if your help desk and inventory are separate systems, put the ticket number in the device record and the serial in the ticket, by hand, every time. It is tedious, and it is the difference between a help desk and a suggestion box.

Statuses that mean something

The default statuses in most systems are Open, In Progress, Closed. That is not enough to answer "why is this taking so long." Use statuses that name the reason a ticket is waiting:

  • New: nobody has looked at it.
  • In progress: someone is working it.
  • Waiting on parts: the fix is known, the part is ordered. This is the status that explains repair time to a principal.
  • Waiting on requester: you asked a question and are waiting for the answer. Tickets sit here without counting against you.
  • Done.

Add one or two per queue if the work needs it (facilities: "scheduled"; HR: "awaiting signature"). Resist adding ten. A status is useful only if the team keeps it current, and the way to keep it current is to make it the first thing you touch when you pick a ticket up.

Set a simple expectation per queue and publish it: technology acknowledges within one school day, facilities within two, and a "waiting on parts" ticket gets a note every week. Not a formal SLA, just a promise teachers can hold you to, which is what makes them use the system instead of the hallway.

Canned responses and the knowledge base

Half of a technology queue is the same twenty questions. Write the answer once, as a canned response the team can insert in one click: how to reset a password, how to project to the board, what to do when a Chromebook says "managed by your organization." Every canned response you write is a ticket you never work again, because next time it becomes a help article and the teacher finds it before filing.

Keep the canned responses in the queue's settings where the team edits them, not in a shared doc nobody opens. Review them twice a year; software changes and answers rot.

Merge, don't duplicate

The projector in room 204 fails, and four teachers file tickets. Merge them into one, keep every requester on the thread, and close them together. A queue with four open tickets for one projector reads as four problems in every report and wastes four notifications on the fix. Merging by searching a ticket title or its short ID should take seconds.

The three reports worth running

Everything above exists to produce three numbers, and if you cannot produce them, revisit the device link and the statuses.

Tickets by device model. Repair tickets grouped by model, with parts cost. This is the argument for the model you want next and for cases on the model you have. "The 2021 Acer 311s generated 340 screen tickets and $9,800 in parts; the Lenovo 300e cohort of the same size generated 60" is a sentence that changes a purchase.

Time to resolve, by queue and by status. Median time from new to done, and how much of it was "waiting on parts." This is the answer to the principal, and it is the number that justifies stocking screens and hinges instead of ordering per ticket.

Volume by building and by month. Where the work comes from and when. The spikes are handout month and collection month, and the building with twice the tickets usually has a Wi-Fi problem, not a people problem.

Edventory's reports overview gives you these across all queues, and the report builder lets you cut them any way the board asks. If you are running a help desk on email and a spreadsheet, a monthly export and three pivot tables get you a usable version, as long as the device link exists.

Rolling it out

Do not announce a new help desk in August. Announce three things: an email address that works, a QR label on every device, and a promise about response time. Print the label, put it on every device on handout day, and show it in the first staff meeting: scan this when something breaks. Give the office staff the form for facilities and the address for HR. Then keep the promise for a month. Teachers use the system that answers them; the rest is configuration.

Edventory ships with a Technology queue on day one and lets you add Facilities, HR, and any other queue with its own form, statuses, and inbox, with email-to-ticket, QR labels, and the device link built in; it is free for up to 100 devices and 100 students. Whatever you run it on, the shape is the same: a few queues, intake where people already are, the device on every ticket, statuses that name the wait, and three reports you can take to a meeting.