SLA management is one of the most visible ways an IT service desk proves its value — and one of the easiest places to lose stakeholder trust when things go wrong. If your team is missing response or resolution targets, struggling to report on them accurately, or running SLAs that no longer reflect what the business actually needs, this guide walks through how to design, track, and continuously improve service level agreements in a modern ITSM environment.
What Is SLA Management and Why It Matters
A service level agreement is a documented commitment between an IT team and the users or business units it serves. It defines how quickly the team will respond to and resolve different types of requests or incidents. SLA management is the ongoing process of setting those targets, monitoring performance against them, and taking action when they are at risk or being breached.
Most service desks have some form of SLA in place, but many treat them as a box-ticking exercise rather than a genuine performance tool. When SLAs are poorly designed or inconsistently tracked, they create more problems than they solve:
- Agents do not know what they should be prioritising at any given moment
- Managers cannot tell whether the team is actually performing well or just getting lucky
- Business stakeholders lose confidence in IT because they see breaches but no explanation or improvement
Good SLA management connects the service desk to business outcomes. It gives agents clarity, gives managers data, and gives stakeholders a basis for trust.
SLAs, OLAs, and Underpinning Contracts
Before setting targets, it helps to understand the three layers of service commitment that ITIL v4 describes.
An SLA is the agreement with the customer or end user. An operational level agreement (OLA) is an internal agreement between IT teams that supports the SLA — for example, a commitment from the network team to respond to escalations within a certain window. An underpinning contract (UC) is a similar commitment from an external supplier.
If your SLAs are being missed, the root cause is often a broken OLA or UC rather than a failure on the service desk itself. Mapping these relationships is a prerequisite for managing SLAs effectively.
How to Set Realistic SLA Targets
The most common mistake organisations make is copying SLA targets from a template or a previous tool without validating them against actual performance data or business requirements. Targets that are too aggressive create constant breach notifications that agents start ignoring. Targets that are too loose provide no meaningful pressure to improve.
Start With Priority Tiers
Most ITSM platforms categorise tickets by priority, typically using a matrix of urgency and impact. SLA targets should be tied to these priority levels rather than applied uniformly across all tickets.
A typical four-tier model might look like:
- Priority 1 (critical): affects many users or a business-critical system — response within 15 minutes, resolution within 4 hours
- Priority 2 (high): significant impact on a group or key process — response within 1 hour, resolution within 8 hours
- Priority 3 (medium): moderate impact, workaround available — response within 4 hours, resolution within 24 hours
- Priority 4 (low): minimal impact, cosmetic or informational — response within 8 hours, resolution within 72 hours
These are illustrative only. Your actual targets should reflect your team's capacity, the nature of your services, and what the business genuinely needs.
Validate Against Historical Data
Before committing to targets, pull at least three months of ticket data and look at your actual median response and resolution times by priority. If your current median resolution time for medium-priority tickets is 30 hours, setting a 24-hour target is possible but will require process changes to achieve. Setting an 8-hour target will produce immediate, widespread breaches that demoralise the team and mislead stakeholders.
Agree Targets With the Business
SLAs should be negotiated, not dictated. Involve service owners and business unit representatives in the conversation. This does two things: it surfaces requirements you might not have been aware of, and it creates shared ownership of the targets. Stakeholders who helped set an SLA are more likely to understand and accept the occasional breach.
Tracking SLA Compliance in Real Time
Setting targets is the easier half of SLA management. The harder part is creating the operational conditions that allow agents and managers to act on SLA data before a breach happens.
SLA Clocks and Business Hours
Most ITSM platforms calculate SLA time using a clock that starts when a ticket is logged and pauses under certain conditions — for example, when the ticket is waiting for a response from the user. Understanding how your platform handles these pauses is critical, because errors here silently distort your compliance data.
Key questions to answer for your platform:
- Does the SLA clock pause when a ticket is placed on hold or waiting for third-party input
- Are SLA targets calculated against business hours or calendar hours, and does this match your SLA documentation
- How are tickets logged outside business hours treated — does the clock start immediately or at the beginning of the next working day
These are not edge cases. They affect a significant proportion of tickets in most environments.
Escalation and Breach Alerts
Effective SLA tracking is proactive, not retrospective. Your service desk platform should surface tickets that are approaching their SLA deadline before the breach occurs, not just flag them after the fact.
A practical escalation model:
- Alert the assigned agent when a ticket reaches 50% of its SLA window
- Alert the team leader when a ticket reaches 75%
- Escalate automatically to a senior agent or manager at 90%, with a notification to the requester if appropriate
This gives the team time to act. It also creates a clear audit trail showing that the escalation process was followed, which matters when you are reviewing breaches with stakeholders.
Common Reasons SLAs Are Missed
Understanding why breaches happen is as important as preventing them. Without this analysis, teams tend to apply the same generic fixes repeatedly without addressing the actual causes.
The most frequent root causes of SLA breaches include:
- Tickets assigned to agents who are absent, on leave, or overloaded with no automatic reassignment
- Priority assigned incorrectly at logging, meaning a high-impact ticket is treated as low priority
- Tickets stuck waiting for approval or information with no mechanism to chase or escalate
- Lack of visibility across the queue — agents working from personal inboxes or notification feeds rather than a shared view
- Understaffing at peak periods, particularly Monday mornings or after public holidays
- Third-party or supplier delays that are not tracked as separate OLA or UC breaches
Categorising your breaches by root cause each month gives you the data to have specific, actionable conversations rather than general pressure to "do better".
Reporting SLA Performance to Stakeholders
SLA reports serve different audiences and should be tailored accordingly. A weekly operational report for the service desk manager should look different from a monthly summary for the IT director or CIO.
Operational Reports
For day-to-day management, the most useful SLA metrics are:
- SLA compliance rate by priority tier for the current period
- Number of breaches by category or team, with root cause notes
- Tickets currently at risk of breach in the next four hours
- Average response and resolution times compared to targets
Executive Reports
For senior stakeholders, focus on trend lines and business impact rather than raw ticket counts. A compliance rate that improved from 78% to 89% over a quarter tells a clearer story than a list of individual breaches. Pair the numbers with a short narrative explaining what changed and what is planned next.
Transparency matters here. Stakeholders who receive honest reporting — including acknowledgement of where targets were missed and why — develop more trust in the IT team than those who receive only positive metrics.
Continuously Improving Your SLA Framework
SLA management is not a one-time configuration task. Targets that made sense when a platform was first deployed may become outdated as the business grows, the team changes, or new services are introduced.
A practical SLA review cycle:
- Review SLA targets formally at least once per year, or after any significant change to team size or service scope
- Review breach patterns monthly and assign ownership of root cause investigations
- Survey end users periodically on whether response times meet their expectations — perception gaps are as damaging as actual breaches
- Update OLAs and underpinning contracts whenever SLA targets change, to ensure the supporting commitments remain aligned
Connecting SLA Data to Problem Management
Recurring SLA breaches in the same category or for the same type of request are a signal worth investigating through your problem management process. If the same configuration error causes a P2 incident three times in a quarter, each one generating a near-breach, that pattern deserves a problem record and a root cause analysis — not just another incident ticket.
Key Takeaways
- SLA management requires three things working together: well-set targets, real-time tracking, and a structured response to breaches
- Targets should be validated against historical data and agreed with the business, not copied from a template
- Proactive escalation alerts — before a breach, not after — are the single most effective operational change most teams can make
- Breach analysis by root cause is more useful than overall compliance rates alone
- SLA frameworks should be reviewed regularly, not treated as permanent configuration
TIKTING includes built-in SLA management with configurable priority tiers, business-hour calendars, escalation rules, and real-time breach dashboards — designed to give service desk teams the visibility they need without complex setup. If your team is also working to keep asset and configuration data accurate alongside your SLA tracking, Odysseus asset discovery feeds current endpoint data directly into TIKTING, reducing the manual effort involved in accurate ticket prioritisation and impact assessment.
