A helpdesk SLA is only as good as the priority rules underneath it. Plenty of SLA documents have tidy target tables and no agreed way to decide whether a ticket is a P2 or a P3. So agents guess, requesters argue, and the SLA report turns into a record of disagreements rather than performance.
This guide gives you templates to copy: an impact-urgency priority matrix, P1 to P4 response and resolution targets, an escalation matrix, and a version that works across four desks: IT, HR, customer support and field service. Every target in here is a starting-point example to adapt. None of them is an industry standard, because there isn’t one.
What a helpdesk SLA actually measures
A helpdesk SLA is a commitment about time. Usually two times:
- First response time: how long until a person (not an auto-reply) acknowledges the ticket and starts work
- Resolution time: how long until the issue is fixed or a workaround restores service
Three details decide whether those numbers mean anything.
First, the clock: 24/7 or business hours only. On a 9-to-5 clock, a P2 logged at 4:55pm on a Friday with an 8-business-hour target is due late Monday afternoon, not at 1am on Saturday.
Second, pause states. Most teams stop the clock while waiting on the requester. That’s fair, but it needs a rule for how long a ticket can sit in “awaiting customer” before it auto-closes, or the pause becomes a hiding place.
Third, what counts as resolved. If reopened tickets start a fresh SLA, your resolution numbers will flatter you.
Resolution targets and mean time to resolve are two sides of the same measure. The SLA is the promise per ticket; MTTR is the average of what you delivered. Our guide to reducing MTTR with AI in ITSM covers the second half.
Priority matrix: impact and urgency
Priority should come from two questions. How many people or how much of the business is affected (impact)? And how fast does the damage grow if nobody acts (urgency)? This is the standard ITIL-style approach, and the IT Process Wiki’s incident priority checklist is a good public reference for how impact and urgency levels are usually defined.
Copy this matrix and change the definitions to fit your organisation. Urgency levels are: high (damage grows fast, no workaround), medium (work degraded, workaround exists) and low (inconvenience, can wait).
- High impact (whole organisation, a site, or a critical service): high urgency = P1, medium urgency = P2, low urgency = P3
- Medium impact (a department, team or several users): high urgency = P2, medium urgency = P3, low urgency = P4
- Low impact (one user): high urgency = P3, medium urgency = P4, low urgency = P4
Two rules keep this honest. Agents set impact and urgency, and the tool calculates priority; nobody types “P1” directly. And requesters don’t get to pick priority, though they can describe urgency in their own words at intake.
A note on VIPs: if executives get bumped a level, write that into the matrix openly. Hidden VIP rules make everyone else distrust the SLA.
P1 to P4 response and resolution targets
Here are starting-point targets. These are example numbers for a mid-size internal IT desk, meant to be edited, not benchmarks.
- P1 Critical: e.g. email down for everyone, or payment system offline. First response: 15 minutes. Resolution: 4 hours. Clock: 24/7.
- P2 High: e.g. VPN failing for one office, or shared printer fleet down. First response: 1 hour. Resolution: 8 business hours. Clock: business hours, or 24/7 if you have on-call.
- P3 Medium: e.g. one user can’t access a shared drive, or an app error with a workaround. First response: 4 business hours. Resolution: 3 business days. Clock: business hours.
- P4 Low: e.g. a software install request or minor how-to question. First response: 1 business day. Resolution: 10 business days. Clock: business hours.
Real organisations publish very different numbers for the same priority. The IT Process Wiki checklist uses five levels, with example resolution targets from one hour for critical incidents to a week for the lowest. Emory University’s incident process guidelines set the same one-hour P1 response across service tiers but vary P1 resolution from two hours on its top tier to eight hours on others, and the default tier only runs during weekday business hours. That’s the right instinct. Targets should follow what the service is worth, not a number copied from someone else’s SLA.
SLA targets for HR, customer and field desks
The matrix travels well. The targets and examples don’t. Here’s how we’d adjust them per desk:
- IT: a P1 is a company-wide outage, security incident or critical system down. Use the standard targets above, with P1 on a 24/7 clock.
- HR: a P1 is a payroll run failing before pay day, or an urgent employee welfare or safety case. Use a business-hours clock for most tickets, and route confidential cases to a restricted queue with named owners.
- Customer support: a P1 is a service outage affecting many customers, or payment or order failures. Targets may be contractual per customer tier, and first response often matters more than resolution.
- Field service: a P1 is critical equipment down at a customer or plant site. Add an on-site arrival target between response and resolution, and account for travel and parts.
What is an escalation matrix?
An escalation matrix is a table that defines when a ticket moves beyond its current owner, who it moves to, and how they’re notified. It sets time-based triggers, usually a share of the SLA elapsed, for functional escalation to more skilled teams and hierarchical escalation to managers, so breaches are caught before they happen.
The two kinds do different jobs. The IT Process Wiki’s incident management process describes functional escalation as passing an incident that first-level support can’t resolve to a specialist group in second-level support. Hierarchical escalation brings in management attention: someone with authority to pull in more people, approve spend or talk to the affected business.
Escalation matrix template
Copy this and replace the roles. The triggers use the share of the SLA target that has elapsed, so the same matrix works for every priority.
- 0. Assigned: trigger: ticket logged and prioritised. Action: auto-assign by skill and workload. Owner: assignee.
- 1. Warning: trigger: 50% of response or resolution time elapsed. Action: alert the assignee. Owner: assignee.
- 2. Functional: trigger: 75% elapsed, or assignee lacks the skill or access. Action: reassign or pull in a specialist. Owner: L2 or specialist team.
- 3. Hierarchical: trigger: 90% elapsed, or requester escalates. Action: team lead reviews resourcing. Owner: team lead or desk manager.
- 4. Breach: trigger: SLA breached. Action: breach logged, recovery plan agreed. Notified: desk manager and service owner.
- P1 override: trigger: any P1 at logging. Action: skip to stage 3 immediately; open a major incident if needed. Notified: desk manager, on-call lead, service owner.
And here’s the contact version for four desks. Fill in names, not just roles, and review it whenever someone changes jobs.
- IT desk: L1 service desk agent → L2 infrastructure or application specialist → L3 IT manager or vendor support → Executive: CIO or IT head
- HR desk: L1 HR helpdesk advisor → L2 HR business partner or payroll specialist → L3 HR manager → Executive: HR head
- Customer desk: L1 support agent → L2 senior or product specialist → L3 support manager or account manager → Executive: head of customer experience
- Field desk: L1 dispatcher → L2 field technician lead → L3 field service manager → Executive: operations head
How SLA timers and automated escalation prevent breaches
All of this can live in a spreadsheet. It just won’t work there, because manual escalation depends on someone noticing a timer at 6pm with a full queue.
What stops breaches is the helpdesk doing the watching. Timers start at logging and pause on the right states. Warnings fire at 50% and 75% without anyone checking a report. Tickets reroute when an assignee is overloaded. Managers see a live view of what’s about to breach, not a monthly chart of what already did.
This is the job SupportDesk is built for. It has configurable SLA tiers with automated escalation alerts, so the priority and escalation matrices in this article translate directly into rules. AI triage classifies, prioritises and tags incoming tickets from email, web and API channels, which takes the P2-versus-P3 guesswork away from the busiest agent. Smart auto-assign routes by skill, workload and priority, and live dashboards show SLA status as it changes. It’s deployed at HMD Global across warranty, spares and IT support workflows.
Running one SLA model across IT, HR, customer and field desks
Growing companies often end up with several desks by accident: IT in one tool, HR in a shared inbox, field service on spreadsheets. Each has its own idea of urgent.
Using one priority matrix across all of them, with desk-specific targets, fixes the language problem without forcing identical service levels. A P1 means the same thing everywhere (high impact, high urgency), even if the HR desk’s clock runs only in business hours and the field desk tracks an arrival time.
A few things are worth setting up per desk:
- Separate queues and permissions, especially for confidential HR cases
- Desk-specific categories so triage and reporting stay meaningful
- CSAT surveys at closure, so you measure whether a met SLA felt like good service
Our post on AI-powered helpdesk ticketing goes further into SLA measurement and running multiple desks on one platform.
Keeping SLA performance consistent over time
Setting the matrix is quick. Keeping it true is the job. Review breaches monthly, and for each one ask whether the target was wrong, the priority was wrong, or the process failed. Those three answers need different fixes.
Watch for gaming, too. Falling breaches paired with rising reopens means tickets are being closed early. Track reopen rates next to SLA compliance.
Process discipline matters more than the tool here. Our article on Lean Six Sigma for IT operations covers the root-cause habits that keep SLA numbers steady. If you’re building SLAs from scratch and want help with the governance and process design, our technology and operations consulting team does that work, using ISACA/ITAF-aligned IT governance.
Start with the priority matrix. Get agreement on impact and urgency definitions before anyone argues about minutes. The targets are the easy part.
Frequently asked questions
What are typical IT helpdesk SLA examples?
A common starting point is a 15-minute response and 4-hour resolution for P1 critical incidents on a 24/7 clock, one hour and eight business hours for P2, four business hours and three business days for P3, and one business day and ten business days for P4. Treat these as examples to adapt to your services and staffing, not as standards.
How do you create an escalation matrix?
List your escalation stages, then set a trigger for each one, usually a share of the SLA elapsed such as 50%, 75% and 90%. Define whether each stage is functional escalation to a specialist team or hierarchical escalation to a manager. Add named contacts per desk and level, give P1 tickets an immediate manager alert, and review the matrix whenever roles change.
What SLA targets suit an HR helpdesk?
HR desks usually run on a business-hours clock, with P1 reserved for issues like a payroll run failing before pay day or an urgent employee welfare case. Response targets matter a lot because people raising HR issues want acknowledgement quickly. Route confidential cases to a restricted queue with named owners, and set targets that reflect your HR team’s actual capacity.
What is the difference between response time and resolution time SLAs?
Response time SLA measures how long until a person acknowledges the ticket and starts work. Resolution time SLA measures how long until service is restored or the issue is fixed. Both usually pause while waiting on the requester. Response targets protect the requester’s confidence, while resolution targets protect the business from the impact of the incident dragging on.
What happens when a helpdesk SLA is breached?
The breach should be logged automatically, the ticket escalated to the desk manager and service owner, and a recovery plan agreed with the requester. Afterwards, review whether the target was unrealistic, the priority was wrong or the process failed. Repeated breaches on one category usually point to a staffing, skills or knowledge-base gap rather than individual performance.
How many priority levels should a helpdesk use?
Four levels, P1 to P4, work for most helpdesks because they’re easy to explain and apply consistently. Some organisations use five, adding a very low level for requests with no deadline. More than five tends to create arguments rather than precision. Whatever you choose, derive priority from impact and urgency so agents aren’t picking levels by instinct.
Put your SLA matrix to work
Want to see these matrices running as live rules rather than a spreadsheet? Request a SupportDesk demo and we’ll show how your priority levels, SLA tiers and escalation stages map onto it.