Help Desk SLA Tracking: Targets, Timers and Breaches

Help desk SLA tracking means giving every request a deadline when it arrives, counting down against it, and recording whether the first response and the resolution landed in time. In practice you need three timestamps per request (created, first response, resolved), one target per request type, and a queue sorted by whichever deadline is nearest. Everything else — pausing, business hours, escalation — refines those three.

SLA, SLO, SLI: the words first

The terms get mixed up, so pin them down. Google's Site Reliability Engineering book defines them precisely:

• SLI (service level indicator) — a measured quantity, such as "hours from request to first reply".
• SLO (service level objective) — the target for that indicator, such as "first reply within 4 hours for 95% of requests".
• SLA (service level agreement) — the promise to your users, with consequences when the SLO is missed.

An internal help desk rarely has contractual penalties, so most "SLAs" inside a company are really SLOs. That is fine — the mechanics are the same. For the neighbouring terms (OLAs and KPIs) see SLA vs OLA vs KPI.

The two clocks every request has

Track both. A desk that resolves everything in two days but leaves people in silence for the first day feels broken, even if resolution looks fine. First response is also the metric you can improve fastest — see how we cut first-response time.

Be precise about what counts as a response. In LetRelay, first response is stamped by a database trigger on the first non-internal message from someone other than the requester. An internal note between agents does not count, and neither does the requester adding details to their own ticket. Without that rule, a desk can "meet" its first-response target without ever speaking to the person who asked.

Choosing targets you can actually meet

A target nobody can hit is worse than no target: people stop looking at it. Set targets per request type, not per team, because a password reset and a new-laptop order from the same IT team have very different natural durations.

A practical way to pick them:

1. Measure before promising. Run two to four weeks with timers on and no targets shown. Take the 80th–90th percentile of actual durations per category.
2. Set the first target near that percentile. You will meet it most of the time, which keeps the number credible.
3. Tighten where it matters. Anything that blocks someone from working (access, broken equipment) deserves a shorter clock than a nice-to-have (a new monitor arm).
4. Review quarterly. If a category never breaches, the target may be slack; if it breaches a quarter of the time, it is fiction or understaffed.

Use percentiles, not averages. The SRE book makes the point that an average hides a long tail: most requests can be fast while a few wait for days, and the average looks healthy while those few people are furious.

An example set of starting targets — ours, not an industry standard, and meant to be replaced by your own measurements:

Stamping the deadline in the database

Compute the deadline once, when the request gets its category, and store it. Don't recompute it in the browser on every render — different clocks and timezones produce different answers.

-- categories.sla_hours holds the target; a trigger sets requests.sla_due_at
new.sla_due_at := coalesce(new.created_at, now()) + make_interval(hours => h);

Then "the queue" is simply:

select id, title, sla_due_at
from requests
where status in ('new', 'triaged', 'in_progress')
order by sla_due_at nulls last
limit 50;

Index (status, sla_due_at) so this stays fast as the table grows. A stored deadline also makes reporting honest: breach is resolved_at > sla_due_at, evaluated the same way for everyone. We walk through the full schema in building an internal help desk with Next.js and Supabase.

Pausing the clock (and when not to)

Most help desk tools let the resolution clock pause while a request is waiting on the requester — you asked for a screenshot and they have gone quiet. Pausing is fair: the delay isn't the desk's. It also invites abuse: a request parked in "waiting" forever never breaches.

If you implement pausing:

• Record each pause interval (start, end) rather than editing the deadline in place, so you can audit it.
• Only allow pausing when the last message was from the agent, asking a question.
• Auto-resume (or auto-close with a message) after a fixed number of days.

LetRelay's current behaviour is simpler and worth stating plainly: the deadline is wall-clock from creation, and a waiting status exists so the queue can show why a request is idle — but it does not stop the clock. For small teams that transparency is often enough; larger desks usually want pause intervals.

Business hours

A 4-hour target set at 5 pm on a Friday means Monday 9 am to a human, and 9 pm Friday to a naive timer. You have two honest options:

1. Wall-clock targets with realistic numbers — "1 business day" becomes 24 hours, or 72 over a weekend. Simple, slightly unfair to the desk.
2. Business-hour calendars — the deadline skips nights, weekends and holidays in the team's timezone. Fairer, and more complex: you need a calendar per team, a function that adds working hours to a timestamp, and care with daylight-saving transitions.

Whichever you choose, compute it in one place (the database) and show the deadline in the viewer's timezone. A due time of "14:00" is ambiguous when your team spans Kathmandu and California.

Catching breaches before they happen

A breach report at month end is an autopsy. The useful signal is about to breach:

• Colour in the queue. Green when more than half the time remains, amber in the last quarter, red when overdue.
• A "due soon" view — sla_due_at < now() + interval '1 hour' and still open.
• Escalation. If a request passes 75% of its clock unassigned, notify the team lead; at 100%, notify their manager. Escalate to a person, not a channel everyone mutes.

Keep notifications few. One well-timed nudge beats five automatic ones that train people to ignore alerts.

Reporting that people trust

Report these per category and per team, monthly:

• Attainment — share of requests resolved within target (e.g. 92%).
• First response p50 and p90.
• Resolution p50 and p90.
• Breaches by cause — unassigned too long, waiting on another team, waiting on a vendor.

All of this is a group by over the requests table; no BI tool needed. See a Postgres analytics dashboard without a BI tool and the wider set of numbers in help desk metrics that matter.

Common mistakes

• One target for everything. "Everything in 24 hours" is either too slow for outages or impossible for purchases.
• Counting internal notes as responses. Inflates first-response numbers while the requester hears nothing.
• Letting agents edit the deadline. Change the category (which recomputes the target) or record a pause — never overwrite sla_due_at by hand.
• Measuring averages. Report percentiles; averages hide the people who waited longest.
• Targets without routing. A request that sits with the wrong team burns its clock before the right team sees it. Fix routing first.

FAQ

What is a good first response time for an internal help desk?

There is no universal number. Measure your current 80th–90th percentile per request type for a few weeks and set targets near it, shorter for anything that stops someone working. Many internal desks land between one hour for blocking issues and one business day for routine ones.

Should the SLA clock pause while waiting for the requester?

Pausing is fair when the delay is genuinely theirs, but record each pause as an interval, only allow it after an agent's question, and auto-resume or close after a few days. Otherwise "waiting" becomes a place requests go to avoid breaching.

Should SLAs use business hours or 24/7 time?

Business hours are fairer to the team; wall-clock is simpler. If you use wall-clock, set targets that already account for nights and weekends. Either way, compute deadlines in one place and display them in the viewer's timezone.

How do I measure SLA attainment?

Divide requests resolved on or before their stored deadline by all requests resolved in the period, per category. Store the deadline when the request is categorized so the calculation is the same for everyone.

Sources

• Google SRE Book — Service Level Objectives
• Google SRE Workbook — Alerting on SLOs
• PostgreSQL — Date/Time Functions and Operators
• PostgreSQL — Trigger Functions
• Wikipedia — Service-level agreement