What are reasonable help desk SLAs for a school district?

Measure response and resolution separately, and know which one people care about

Two clocks matter and they mean different things. Time to first response is how long before a human acknowledges the ticket and says something specific about it. Time to resolution is how long until the problem is actually fixed. Districts that publish only resolution targets frustrate everyone, because the most common complaint about a school help desk is not that repairs take time — it is silence.

First response is also the target you have the most control over, since it depends on triage discipline rather than on parts availability or vendor turnaround. A district that reliably responds within a few hours during the school day has already solved most of its perceived responsiveness problem, even when the fix takes a week. Make the response substantive: an automated receipt is not a response, and treating it as one is the most common way SLA reports drift away from what people experience.

Resolution targets should be set per priority and should reflect what you can actually do. There is no virtue in publishing a target you miss half the time; it teaches people the numbers are decoration. Look at your historical distribution before you publish anything — pick a target you already hit for the large majority of tickets in that priority, and improve it deliberately later.

A third measure is worth tracking even if you never publish it: time to a workaround. For a teacher mid-lesson, a loaner device or an alternate path is functionally a resolution, and a queue that optimizes only for permanent fixes will make people wait for the wrong thing.

Finally, distinguish resolution time from time in your queue. When a ticket is waiting on a part shipment, a vendor RMA, or a reply from the requester, that time belongs in a different bucket. Rolling it into your resolution number makes your technicians look slow for a supply chain problem, and — more importantly — hides the delay you could actually fix.

Priority in a school context is about instruction, not about job title

Corporate priority models are built around revenue impact and executive escalation, neither of which translates. The right axis in a district is instructional impact: how many students cannot learn right now, and is there a workaround. That framing is defensible to a principal in a way that a VIP tier is not, and it produces sensible answers automatically.

A workable four-level scheme looks something like this. Critical is anything that stops instruction at scale or blocks a hard deadline — the network is down in a building, the state testing platform is failing during a testing window, the SIS is unreachable on the day grades are due. Response measured in minutes, all hands, and a communication channel that does not depend on the ticketing system.

High is a classroom-level blocker with no workaround: a teacher's device or projector is dead, an entire cart will not connect, a class cannot get into the application today's lesson depends on. Same-day response and, in most cases, same-day resolution — often through a loaner rather than a fix.

Normal is a single-user problem with a workaround: one student's Chromebook has a cracked screen and a loaner exists, a password reset, a printer misbehaving. A day or two is fine if the requester knows that.

Low is a request rather than a break: new software evaluation, a room move, a data extract, a projector mount. Days to weeks, scheduled rather than queued, and honesty about that is better than optimism followed by silence.

Two cautions. First, let requesters suggest a priority but let the help desk set it, and be consistent about it — self-selected priority inflates to critical within a semester otherwise. Second, build in explicit calendar overrides, because the same ticket has a different priority during a testing window than in the second week of October, and any priority scheme that cannot express that will be overridden informally anyway.

The school calendar breaks generic SLA clocks

This is the single largest difference between school and corporate service targets, and it is where most off-the-shelf configurations fail. A ticket filed at 3:45 on Friday afternoon of spring break should not accumulate SLA time over a nine-day closure. A ticket filed at 6 p.m. should start its clock in the morning. If your tooling counts wall-clock hours, your reports will show systematic breaches that correspond to nothing anyone did wrong, and staff will stop reading them.

What you need is business-hours accounting against a calendar that knows your district: daily start and end times, weekends, holidays, professional development days, breaks, and summer. Summer especially, since a district running a genuinely reduced summer operation is not failing its SLA by taking three days on a normal-priority ticket in July — it is running the schedule it published.

Build the calendar once and share it. It is the same calendar the SIS knows, and it should be the source for SLA pausing, for auto-reply messaging, and for the expectation you set with requesters. The alternative — technicians mentally discounting the numbers because everyone knows the report is wrong in August — costs you the value of measuring at all.

Define separate targets for the periods that behave differently rather than pretending one target fits. Back-to-school weeks carry several times normal volume and are the moment your responsiveness matters most; summer is low volume and slower by design. Publishing that openly is more credible than a single year-round number nobody meets in September.

And handle after-hours explicitly. Most districts do not staff overnight, and that is fine, but there should be a stated path for the genuine emergency — a network outage the night before testing — that does not run through a ticket queue nobody is watching until seven in the morning.

Setting targets you can actually meet

Start from your data rather than from a benchmark. Pull the last full year of tickets, compute the distribution of first response and resolution times by category, and look at where you already land. Setting a target at roughly your current performance and then improving it deliberately builds credibility; setting an aspirational target you miss immediately destroys it, and the credibility is the whole point of publishing.

Be realistic about staffing. A single technician covering three buildings cannot meet a same-day on-site response target, and publishing one converts a resourcing problem into a personal failure. If the target you would like requires staffing you do not have, that gap is exactly the case to bring to your board — an SLA you consistently miss, with the ticket volume and technician count beside it, is a far better argument than an assertion that the team is stretched.

Use the SLA to shape demand as well as to measure supply. If the largest category by volume is password resets, self-service password recovery removes those tickets rather than making you faster at them. If it is projector and display issues in one building, the fix is a building project, not a queue. The best SLA improvements usually come from removing tickets, and you cannot see which ones to remove without category data.

Automate the routing that a human currently does by reading each ticket. Assigning by building, by category, or by device type at intake removes a triage step that is pure latency, and the first response clock is where that latency shows up most.

Hold the resolution target constant when volume spikes rather than quietly extending it, but publish the spike. A district that says openly that the first two weeks of school run at four times normal volume and that normal-priority tickets will take longer has managed expectations honestly. One that silently misses its target for a month has just taught everyone to ignore its numbers.

Reporting without gaming it

Every metric can be gamed, and the standard help desk games are well known: closing tickets prematurely to stop the clock, splitting one problem into several tickets, marking things resolved that will reopen next week, or setting everything to low priority so nothing breaches. None of this is malice; it is what happens when a number becomes a target attached to an evaluation.

The simplest defenses are structural. Track reopen rate alongside resolution time — a queue getting faster while reopens climb is not getting faster. Track tickets per requester and per device, since the same student's Chromebook appearing four times means the underlying problem was never fixed. And measure satisfaction directly with a one-question survey at close, because that catches the technically-resolved-but-not-really cases that no timing metric will.

Report by building and by category, not just in aggregate. The district number tells you almost nothing actionable; the fact that one building's average response is triple the others tells you where a technician needs to be. Building leaders also engage far better with their own data than with a district roll-up.

Share the reports with principals routinely rather than only when asked. It converts the relationship from complaint-driven to data-driven, and it surfaces the ticket volumes that come from building-level practice — a school where every device issue is filed by the office instead of the teacher looks different in the data, and that is a conversation worth having.

Revisit the targets annually against what actually happened. An SLA is a hypothesis about what you can deliver with the staff and tools you have, and both change. The failure state is not a missed target; it is a target that has been wrong for three years and everyone has quietly stopped looking at.