How to track SLA in a help desk: a practical setup guide

Tracking SLA is a process first and a feature second

Most advice on SLA tracking starts with software. That’s backwards. A help desk can only time what you’ve defined, so the real work happens before you touch a setting: deciding what you promise, to whom, and what counts as “done.”

This guide walks through the setup in the order that works for a small IT team or MSP. It doesn’t depend on any particular vendor, because the decisions are the same everywhere. (If you’re comparing what each vendor charges for SLA features, that’s covered separately in affordable help desk software with real SLA tracking.)

Step 1: Separate the two clocks

Every SLA is really two timers, and teams that blur them end up with numbers nobody trusts.

• First response time: how long until a human (or an automated agent) meaningfully acknowledges the ticket. An auto-reply that says “we got your email” usually shouldn’t stop this clock. Decide that on purpose.
• Resolution time: how long until the problem is fixed or the request is fulfilled.

Track both, but start with first response. It’s the one clients feel immediately, and it’s the one you can control even when the fix depends on a vendor or a part in the mail.

Step 2: Define priority by impact, not by who shouts loudest

SLA targets hang off priority, so priority needs a definition you can apply without arguing. A common approach is a small matrix of impact (how many people or how much business is affected) against urgency (how fast it hurts).

A workable starting point for a small team:

Keep it to four levels. Five or six levels means techs guess, and guessing defeats the point. The matrix also maps cleanly onto the difference between incidents and requests; if you want a refresher on that split, see how we think about moving from a shared inbox to a real help desk, where ticket types come up early.

Step 3: Pick targets you can actually hit

This is where small teams hurt themselves. Copying a large vendor’s “P1 in 15 minutes” target when you have three techs and one is on vacation guarantees a permanent breach count.

A better method:

1. Pull your last 30–60 days of tickets (or, if you’re coming from a shared inbox, sample the inbox).
2. Measure what you really delivered at each priority: median and the slowest 10%.
3. Set the target slightly better than your current slowest-10% figure, not better than your best day.
4. Tighten later once you consistently meet it.

If you have no history at all, start conservative: for example, a few hours for first response on P3 and a same-business-day target for P2. Those are illustrative starting points, not industry standards. Your contracts, staffing, and clients decide the real numbers.

Write each target down in plain language in the client agreement or service description. A tracked SLA nobody agreed to is just an internal goal.

Step 4: Decide when the clock runs

This is the most overlooked step, and it determines whether your reports mean anything.

Business hours versus calendar hours. A P3 target of “4 hours” means very different things if the ticket arrives at 4:45 p.m. Friday. Most small teams track response against business hours, with only P1 on a 24x7 clock. Decide per priority.

Pause conditions. The clock should stop when the ball is in the client’s court. Typical pause statuses:

• Waiting on customer reply
• Waiting on third party (ISP, software vendor)
• Scheduled for a maintenance window the client chose

Without pause states, every slow client response becomes your breach, and techs learn to game statuses to avoid that. Define pauses narrowly and audit them, because “waiting on customer” is the easiest status to abuse.

Reopens. Decide whether a reopened ticket resumes the old clock or starts a new one. Resumes is stricter and more honest; starting fresh is common. Pick one and document it.

Step 5: Build warnings before breaches

A breach flag after the fact only tells you that you failed. What helps is a warning while there’s still time to act.

Set up, at minimum:

• A warning threshold at roughly 75% of the target. The assignee gets a nudge.
• A breach alert at 100%, routed to a person who can reassign work, not just to the assignee.
• A visible queue sort by “time remaining,” so the next ticket to breach is always at the top.

For an MSP with a small bench, the escalation path can be as simple as “assignee, then whoever’s on point that week.” The point is that a missed clock never sits silently until a client notices first.

Step 6: Make the phone part of the same clock

Phone is where SLA tracking quietly falls apart. A call that never becomes a ticket has no clock at all, so a client can wait on a promised callback while your report shows 100% compliance.

Two rules fix most of this:

1. Every call that needs follow-up becomes a ticket at the moment it ends, with the call time as the ticket’s creation time.
2. Voicemails and missed calls count as arrivals. The first-response clock starts when the voicemail lands, not when someone finally listens to it.

If you haven’t set up a dedicated phone line yet, the practical steps are in how to set up a help desk phone line, and for out-of-hours coverage see how to answer support calls after hours.

Step 7: Report honestly, and report the right things

Once the clocks run, resist the urge to display a single compliance percentage and call it done. A useful monthly review has four numbers:

• Percent of tickets meeting first-response target, by priority
• Percent meeting resolution target, by priority
• Number of breaches and their reasons (staffing gap, unclear ownership, pause abuse, genuinely hard problem)
• Tickets that spent the most time paused, to catch status gaming

Read the breaches individually. A 95% compliance figure that hides three P1 breaches is a worse outcome than 88% with no P1 misses, and an aggregate hides that.

Also watch for the opposite problem: if you’re at 100% for months, your targets are probably too loose. Tighten them or offer clients a better service tier.

Common mistakes to avoid

• Too many SLA tiers. Per-client custom SLAs multiply configuration and errors. Offer two or three standard levels.
• Letting techs edit priority freely after assignment. If priority can be quietly lowered when a ticket is about to breach, your report is fiction. Log priority changes.
• Tracking only the dashboard. If nobody looks at the “time remaining” view during the workday, warnings are decoration.
• Measuring what’s easy instead of what the client experiences. Time to first meaningful reply beats time to auto-acknowledgment.

A one-hour setup checklist

1. Write down your four priority definitions.
2. Choose first-response and resolution targets per priority, based on your actual history.
3. Decide business hours versus 24x7 per priority.
4. List the pause statuses and who may use them.
5. Configure warning at ~75% and breach alert at 100%, with a named person receiving the breach alert.
6. Make phone calls and voicemails create tickets automatically.
7. Schedule a 20-minute monthly review of breaches by reason.

Where ITSM fits

ITSM includes SLA tracking in its core ticketing alongside incidents, requests, problems, changes, KB, and CMDB, and its phone features (AI phone agent, browser softphone) feed calls into the same ticket system so a call doesn’t sit outside the clock. You can see how it’s set up by trying the free tier, which needs no sales call.

Honest note: ITSM is a small product with a free tier, so test it against your own ticket history before you rely on it.