Picture this scenario: an accounting employee calls to report that the ERP system won't open at month-end. The IT team acknowledges the ticket — but nobody knows how many hours they have to fix it, and nobody alerts a manager when too much time has passed. The result: the month-end close misses its deadline, management is upset, and confidence in the IT team is gone.
This happens in many organizations, especially SMEs that don't yet have a formal SLA (Service Level Agreement) in place. This article walks you through SLA from the ground up, including how to set a Priority × Impact Matrix that works in practice for mid-sized organizations.
What Is SLA?
SLA (Service Level Agreement) is a defined commitment that specifies how quickly the IT team must respond to and resolve issues. It typically has two parts:
- Response SLA — The time by which the IT team must acknowledge the ticket and begin working on it (e.g., respond within 1 hour)
- Resolution SLA — The time by which the issue must be fully resolved (e.g., close the ticket within 8 hours)
A commonly used formula is Response SLA = Resolution SLA ÷ 4 — so if a problem must be resolved in 8 hours, the team must acknowledge and begin work within 2 hours.
Why does SLA matter? SLA isn't just a number — it's a commitment the IT team makes to the business. With a clear SLA, everyone knows what to expect, and the IT team has measurable goals.
What Is Priority?
Priority measures how urgent an issue is from a business perspective — how severely it affects ongoing operations. It's typically broken into 4 levels:
- Critical — Business is completely stopped, no workaround available (e.g., core server down, core system unavailable)
- High — Major impact on core work, some workaround possible (e.g., ERP running very slowly, email unable to send)
- Medium — Work is impacted but can continue through other means (e.g., printer down, VPN won't connect)
- Low — Minor issue, not urgent (e.g., software installation request, password change)
What Is Impact?
Impact measures the scope of an issue — how many people or departments are affected. Unlike Priority, Impact measures breadth, not urgency:
- Critical — Affects the entire organization or external customers (more than 50 users, or all departments)
- High — Affects multiple departments or key groups (11–50 users)
- Medium — Affects a single department or small group (2–10 users)
- Low — Affects a single user (1 person)
Separating Priority from Impact makes ticket prioritization far more accurate. For example, a printer problem for a senior executive may have high Priority (urgent) but low Impact (one person affected), while a slow Payroll system may have medium Priority but Critical Impact (affects everyone at month-end).
Priority × Impact Matrix: The Core of IT SLA
Combining Priority and Impact produces an SLA Matrix that defines how many hours each ticket must be resolved in. The table below is the recommended Resolution SLA for SMEs:
| Priority \ Impact | Low (1 person) |
Medium (2–10 people) |
High (11–50 people) |
Critical (entire org) |
|---|---|---|---|---|
| Low | 72 hrs | 48 hrs | 24 hrs | 8 hrs |
| Medium | 48 hrs | 24 hrs | 8 hrs | 4 hrs |
| High | 24 hrs | 8 hrs | 4 hrs | 2 hrs |
| Critical | 8 hrs | 4 hrs | 2 hrs | 30 min |
* Values above are Resolution SLA (time to close) · Response SLA = Resolution ÷ 4
A ticket with Critical Priority and Critical Impact — such as the main company server going down — must be resolved within 30 minutes, requiring the team to mobilize resources immediately. Meanwhile, a Low Priority / Low Impact ticket (such as a folder access request) can wait up to 72 hours (3 business days).
What Is an SLA Breach and Why Does It Matter?
An SLA Breach occurs when a ticket is not resolved within the time defined by its SLA. The consequences go beyond numbers in a report — they erode user trust, concern management, and for outsourced IT support companies may mean financial penalties under the service contract.
A good ITSM system alerts the team before a breach occurs — typically when 80% of the SLA time has been used (status: "At Risk") — giving the team time to escalate before the SLA is actually violated.
How to Set SLA That Works for Your Organization
Many organizations worry that setting up SLA requires full ITIL implementation. In reality, you can start simply:
- Start from the standard matrix — Use the table above as a starting point; there's no need to build from scratch.
- Adapt to your business — If your company operates 24/7 use calendar hours; if office-hours only use business hours (e.g., 08:00–18:00).
- Define Impact by actual headcount — Use real numbers: for a 100-person company, Low = 1, Medium = 2–10, High = 11–30, Critical = 31+.
- Make SLA visible to users — Show the SLA deadline on the ticket as soon as it's created; this reduces repetitive follow-up calls.
- Review quarterly — Check whether your SLA targets are actually achievable, and adjust based on your team's real capacity.
Escalation Rules: Alert Before a Breach
Escalation rules define what happens automatically when a ticket approaches its SLA deadline:
- 80% of SLA time used → notify the support agent responsible for the ticket
- 100% (Breach) → notify the Supervisor or IT Manager via Line OA or email
- Breach for more than +2 hours → notify the Company Admin with the ticket ID and impact details
Good escalation prevents issues from getting "buried" in the system unnoticed, and helps management see the full picture without having to ask.
SLA Metrics Every IT Manager Should Track
Beyond the Breach Rate, several other metrics are worth tracking in your monthly reports:
- MTTR (Mean Time to Resolution) — Average time to close a ticket, calculated across all tickets closed in the period
- MTBF (Mean Time Between Failures) — Average time between recurring incidents, showing how often the same problem returns
- Resolution Rate — Percentage of tickets closed within SLA (e.g., 92% of High-Priority tickets resolved on time)
- Reopen Rate — Percentage of tickets reopened within 7 days of closure, indicating whether issues are truly resolved or only temporarily patched
- Satisfaction Score — User satisfaction rating after ticket closure (1–5 stars)
Summary: SLA Is Not Overhead — It's the Foundation of Good IT
Setting up SLA with a Priority × Impact Matrix helps the IT team prioritize correctly — not spending time on minor issues while major problems wait in the queue — and creates transparency for users because everyone knows when their issue will be addressed.
For organizations just starting out, use the standard matrix and adjust gradually based on how your team actually performs. What matters more than perfect numbers is consistent adherence to the SLA you've set.
If you're looking for an ITSM system that automatically calculates SLA from Priority × Impact with escalation alerts to Line OA before a breach, try 1StopService free for 30 days — no credit card required.