SLA management is the daily work of keeping the response and resolution times you promised. You set goals per priority, run the clock on business hours, and sweep due-by times. You act before a breach, update the client when a miss is likely or has happened, and review compliance monthly.
This routine comes from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) tool a small IT team can run alone.
What Is SLA Management?
The SLA itself is a contract between a service provider and its customers. You write it once, from our service level agreement template. SLA management is everything after the signature.
Definition
SLA management: keeping each ticket inside the response and resolution goals of your service level agreement, and proving it every month.
Why SLA Management Matters On A Small Team
An SLA is only worth the proof that you kept it. "Verifying the provider's service delivery levels is necessary to the enforcement of a service-level agreement," as TechTarget puts it. Customers can enforce service credits when a provider misses the agreed standards.
On a team of two or three technicians, a clock nobody defined can cause a miss by itself. In a thread about one copier ticket, an r/msp member asked: "What is the 'S' in your SLA? Is it triage? First response?"
What You Need Before You Start
- A signed SLA with response and resolution goals per priority.
- Written priority levels, so any technician sets the same priority. Start from our P1 to P4 matrix.
- A business calendar and a pause rule: the hours your SLA covers, holidays, and the status that stops the clock.
- A daily owner for the due-by sweep, with a named backup.
Published clock rules vary:
| Service desk | Clock hours | What pauses the clock |
|---|---|---|
| Grand Valley State University | 8 AM to 5 PM, Monday to Friday | On Hold status |
| Purdue University | Emergency and Critical: 24-hour SLA, no operational hours listed; others: 8 a.m. to 5 p.m. Eastern, weekdays | Awaiting Customer Response; resumes with the time left |
| Laurentian University | 9:00 AM to 4:30 PM, Monday to Friday, for most requests | Waiting on the user, an external vendor, or a scheduled time |
SLA Management, Step By Step
-
Load each priority's goals into the helpdesk
Give every priority its own response and resolution goal, so each ticket gets a due-by time the moment it's logged.
Example: P1 response in one hour, P4 in two business days.
Common mistake: one goal for every ticket, outage and toner request alike.
-
Set business hours and holidays
The clock should run only when the SLA says you work. Enter the hours your SLA covers and this year's holidays before the first ticket arrives.
Example: on an 8-to-5 week, an 8-hour goal logged Friday at 4 PM is due Monday at 3 PM.
Common mistake: skipping holidays, so a Christmas Eve ticket breaches before anyone is back.
-
Write the pause rule
Decide which status stops the clock. Laurentian pauses for vendor waits too. A strict version: pause only when the next move is the user's.
Example: you asked for a screenshot, so the clock waits for the reply.
Common mistake: parking a ticket on hold to stop a clock that's about to run out.
-
Sweep the due-by times twice a day
Sort the open queue by its nearest unmet deadline, response or resolution, each morning and after lunch. Anything due before the next sweep gets an owner now.
Check new urgent tickets as they arrive, and look again between sweeps as often as your shortest goal needs. The University of Alaska's system can send a warning before the deadline.
Example: with a 1-hour P1 response goal, check the queue every 30 minutes.
Common mistake: working the oldest ticket, not the one due first.
-
Act before the breach
When a ticket will miss its due-by time, change how you work it. Pick up the phone, or reassign the ticket if its owner is stuck on a bigger one.
Example: on a two-hour email thread about a copier prompt, one r/msp member said: "The whole thing was asynchronous, and should not have been."
Common mistake: raising the priority to jump the queue or hide a breach. If impact or urgency changed, re-rate it against your matrix and note why.
-
Tell the client about an SLA breach right away
Once a miss is likely or has happened, tell the client the next step and when you'll update them. After the fix, explain what was late and what changes. Apply service credits on the terms your SLA sets.
Example: "Your scanner ticket will miss its 4-hour fix. A technician is on it, and we'll update you by 3 PM."
Common mistake: staying silent until the fix.
-
Review SLA compliance every month
On the first working day, score last month's closed tickets by priority, response and resolution apart, and list open tickets already past due. Give every breach one cause.
A repeat cause gets one action, an owner, and a date; next month's review starts there. The formula is in our helpdesk metrics guide; the client version goes into your QBR.
Example: three of four breaches waited on one vendor, so the owner asks that vendor for a faster parts route by the 15th.
Common mistake: reading only the percentage, never the tickets behind it.
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
- 14 days free
- No credit card required
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
- 15 minutes
- Your workflow, your questions
A live walkthrough tailored to your team.
A Checklist For Tickets About To Breach
Run it when a ticket's next deadline falls before your next check.
The SLA sets the latest time, not the target. As one r/msp member put it, "It's an agreement of what the max time is not what you should aim for in terms of closing the ticket."
How To Measure It Worked
Treat each priority's goal as a monthly budget of misses.
Example
Say a client's month will count 60 P2 tickets and your SLA promises 95% on resolution. That month can absorb 3 misses. If all 3 happen by the 10th, every other P2 must land on time, so an at-risk P2 gets an owner at the first sweep that sees it.
After three months of SLA management, watch three numbers:
- Compliance per priority, response and resolution apart, at or above the goal.
- Repeat causes, each with last month's action done and the cause shrinking.
- Paused hours per ticket, flat. A rising number can mean the pause is dodging breaches.
Track The Clock On The Ticket
How this works in SherpaDesk
Every ticket shows its own due-by
You can give each priority an SLA response goal and a completion goal, and define your business hours and holidays. Each ticket's details show SLA Due By, Waited, and Completion. A Wait (Tech) clock shows how long the user has been waiting for a technician's response, and it resets when any technician responds.
For the monthly review, Reports > SLA & Priority gives you an On-Time Report and a Goal vs. Actual Report on closed tickets, by response or completion. Group or filter by priority; without either, the report uses a blended goal.
A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin.
Base Camp is $45 per agent per month ($40 billed annually), the first agent is free, forever, and the trial is 14 days free with no card.
Who this isn't for
Teams that sell an uptime percentage for a software service. Their SLOs live in monitoring and alerting, not in ticket clocks.
Frequently Asked Questions
What is service level agreement (SLA) management?
It's the work of meeting an SLA after it's signed. You load each priority's goals, run the clock on agreed hours, and watch due-by times. You act before a breach, update the client when a miss is likely or has happened, and review compliance monthly. See the steps.
What is a SLA or KPI?
An SLA is a contract between a service provider and its customers. A KPI is a quantifiable measure tied to a specific performance goal. They meet on the helpdesk: the SLA sets the goal for each priority, and the share of tickets that met it is a KPI you report against it.
What is SLA, SLI, and SLO?
An SLI is the measure and an SLO is the target for it. Google's SRE book defines an SLA as "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain." On a helpdesk, first response time is the SLI, "P2 within one business hour" the SLO, and the client agreement the SLA.
Should the SLA clock stop while you wait on the user?
Yes, if the SLA says so and the next move really is the user's. Grand Valley State pauses the time while a ticket is On Hold. Purdue pauses on "Awaiting Customer Response." Check paused hours monthly so nobody uses the pause to dodge a breach.
Should a low-priority ticket wait while you work a higher one?
Only when the two collide. If a technician is free, work the low-priority ticket now. As one r/msp member wrote, "If a higher priority SLA is at risk, then lower priority tickets may experience interruption." Send the waiting user a reply with the next step and a time.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.