Most help desks have SLAs defined on paper. Sometimes they even have them in Jira Service Management, entered by someone two years ago and then forgotten. Meanwhile, tickets get closed with the response time exceeded, internal customers wait hours for P2, and monthly reports show no problem because nobody configured the breach conditions. This article shows how to build an SLA system that actually works: from the correct policy through priority queues to real-time escalation.
What an SLA is in the ITSM context and why it is not a contract
An SLA (Service Level Agreement) in ITSM is an operational contract between the IT team and internal users or external customers. It defines how quickly IT responds to a ticket and when the problem must be resolved. In practice an SLA is first and foremost a priority management tool.
Most companies confuse SLAs with the contract signed when a system is implemented. That mental error leads to bad consequences: SLAs set once, never reviewed, not mapped to priorities, with no working calendars. The result: the system reports 100% compliance because it counts the time from Friday 23:00 to Monday 8:00 as 33 business hours. A P3 "resolved" on Tuesday is then technically "on time".
SLA vs OLA vs UC
ITIL defines three levels of agreement: SLA (with the customer/end user), OLA (Operational Level Agreement, the internal agreement between IT teams, for example network and server) and UC (Underpinning Contract, the agreement with external suppliers, for example a hardware vendor). Jira Service Management natively handles SLA and OLA. UC is managed separately, but you can link it to tickets through custom fields and links.
For companies of 50-300 people the most practical approach is two SLA policies: time to first response and time to resolution, with different goals per priority. That covers most needs without excessive configuration complexity.
SLA types: response, resolution, assign
Jira Service Management lets you create any number of SLA policies, but in practice three types are used:
Time to first response
The time from ticket creation to the first public comment from a technician or agent. The most important metric for user experience: the customer wants to know that someone has seen their problem. The clock starts automatically on ticket creation and stops at the first public comment (not an internal one).
Time to resolution
The time from ticket creation to transition into "Resolved" or "Done". This is a business metric: it measures how long the problem actually affects the user's work. The clock can be paused when the status is "Waiting for customer" or "Pending vendor". Configure this via a Pause condition.
Time to assign
The time from ticket creation to assignment to a specific technician. Useful for critical P1/P2 incidents, where every minute without an owner is a potential escalation. For P3/P4 it is rarely necessary.
Configuring SLA policies in Jira Service Management
You configure SLAs in JSM at: Project settings → SLAs. Each policy is a separate tab with start, pause, and stop conditions plus time goals per priority. Below are four steps for a complete configuration.
In the "SLAs" section click "Create SLA" and give it a name. Then define three conditions:
Condition configuration
- Start: Issue Created (for response) OR Issue Transitioned to "In Progress" (for resolution)
- Pause: Status changes to "Waiting for customer" (SLA time does not run while we wait for the user)
- Stop: Issue Transitioned to "Resolved" OR "Done" OR "Closed"
In the "Goals" section add JQL conditions and assign a time goal. Each row = one priority.
Goals for Time to first response
- P1:
priority = Critical→ goal: 30 minutes (24/7) - P2:
priority = High→ goal: 2 hours (business hours) - P3:
priority = Medium→ goal: 8 hours (business hours) - P4:
priority = Low→ goal: 24 hours (business hours)
Calendars are configured in Project settings → Calendars. Without a calendar JSM counts time 24/7. A P3 submitted Friday at 20:00 will breach the "8h" SLA at 4:00 in the morning.
Recommended calendars
- 24/7 calendar: assign to P1 goals (critical outages do not respect working hours)
- Working calendar: Mon-Fri, 8:00-17:00, with Polish public holidays, assign to P2/P3/P4
- Add Polish holidays manually or through Google Calendar integration (JSM Cloud Premium)
SLA policies on their own do not send notifications. That is what Automation is for. Go to Project settings → Automation → Create rule.
Pre-breach alert rule
- Trigger: SLA threshold breached → choose the policy → "30 minutes before breach"
- Condition:
status != Resolved AND status != Done - Action 1: Send email → Assignee + Team lead with a link to the ticket
- Action 2 (P1/P2): Send web request → Teams webhook or Slack: instant notification to the incident channel
Queues and P1-P4 priorities: table and definitions
Ticket prioritization is the foundation of the entire SLA system. Without clear definitions each technician interprets priorities differently: either everything ends up as P1 (panic) or as P3 (underestimation). The matrix below combines two dimensions: impact (how many users the problem affects) and urgency (how fast the situation gets worse).
| Priority | Response time | Resolution time | Definition | Examples |
|---|---|---|---|---|
| P1: Critical | 30 min (24/7) | 4 h (24/7) | Total outage, no production, all users affected | No internet in the entire office, ERP server down, Active Directory failure |
| P2: High | 2 h (biz hrs) | 8 h (biz hrs) | Significant function unavailable, large impact on performance | Email not working for a department, VPN unavailable for remote staff, production printer |
| P3: Normal | 8 h (biz hrs) | 3 working days | One user affected, a workaround exists | Laptop running slowly, no access to one application, password reset |
| P4: Low | 24 h (biz hrs) | 5 working days | Request, question, no impact on work | New software, settings change, "how do I do this" question |
Queues in JSM: how to organize them
Queues are the technician's working view. They display tickets sorted by urgency. In JSM you configure queues via Queues → New queue. Optimal structure for a help desk serving 50-300 people:
- My open P1/P2: JQL:
assignee = currentUser() AND priority in (Critical, High) AND status not in (Resolved, Done) - Unassigned P1/P2: visible to all technicians, instantly attracts attention
- Approaching SLA breach: JQL with
slaTimeRemaining("Time to resolution") < 2h - My open (all): full per-technician queue, sorted by priority
- Waiting for customer: tickets in "Waiting for customer" status, must be monitored and closed after 5 days
Escalation rules: before breach and after
Escalation is not a sign of failure. It is a designed safety mechanism. A good escalation system works in two modes: proactive (before SLA breach) and reactive (after breach, if the first alerts failed).
Proactive escalation: before breach
Goal: the technician and their manager know about an SLA risk before the breach actually occurs. Configured via Automation with the trigger "SLA threshold breached, X minutes before breach":
- P1, 15 min before breach: Email + Teams to the technician, team lead, and IT manager. If there is no assignee: automatic assignment to the on-call.
- P2, 30 min before breach: Email to the technician and team lead.
- P3, 2 h before breach: Email only to the technician, no hierarchical escalation.
- P4: No pre-breach alert, a breach notification is enough.
Reactive escalation: after breach
If the SLA has been breached, the system must act immediately, especially for P1/P2:
- P1 breach: Automatic change of priority to "Blocker" + notification to the CTO/IT director + addition to the active incidents dashboard. If the breach lasts more than 1h, auto-escalation to a specialist team.
- P2 breach: Notification to the manager + change of assignee if the previous one has not reacted within 30 min of the breach.
- P3 breach: Internal comment on the ticket + entry in the weekly report.
Escalation through priority change
A separate mechanism: a technician or manager can manually raise the priority, and the system should react automatically. Rule: trigger "Field value changed: Priority", condition "new value = Critical", action: notify the IT manager + change the queue to "Unassigned P1/P2" if there is no assignee.
SLA reporting and dashboards in JSM
Correct SLA configuration without dashboards is like buying an insurance policy without the option to file a claim. SLA reports must be visible to three groups: technicians (current state), IT managers (weekly trends), and the management board (monthly KPIs).
Built-in JSM reports
In the Reports section of a JSM project you will find:
- SLA goals: percent of tickets handled on time per policy and per priority. The basic compliance view.
- Created vs resolved: trend of ticket creation and closure. If the "created" line stays above "resolved", the queue grows and SLA will suffer next week.
- Time to resolution: distribution of resolution time. Identifies outliers, i.e. tickets that took 10x the median.
JSM dashboard: configuration for a manager
In Jira Dashboard (Dashboards → Create dashboard) add gadgets:
- Filter results with a JQL filter for open P1/P2: always visible, not hidden in a report
- Two-dimensional filter statistics: priority x status matrix, instant overview of the state
- SLA statistics gadget (built-in): compliance % per policy
Eazybi and external BI tools
For advanced reporting (monthly trends, heat maps, breach prediction) use Eazybi for Jira, the most popular reporting add-on for JSM. Alternative: export data via the JSM API into Power BI or Grafana if you already have a BI environment.
The most common SLA configuration mistakes
After dozens of JSM rollouts in companies from 50 to 500 users I see the same mistakes recurring regardless of industry:
Mistake 1: No working calendar
Mistake "8 hours" SLA counts 24/7, so a P3 submitted at 22:00 on Friday breaches SLA at 6:00 on Saturday morning.
Correct For P2/P3/P4 assign a working calendar. Only P1 should have a 24/7 clock.
Mistake 2: The SLA clock does not stop on "Waiting for customer"
Mistake The technician asked for information, the customer did not reply for three days. SLA breached, technician blamed.
Correct Configure a Pause condition: "Status changes to Waiting for customer". SLA time is paused until a reply.
Mistake 3: One SLA goal for all priorities
Mistake Every ticket has a "24 hours" SLA. P1 (total outage) and P4 (request for new software) treated identically.
Correct Separate goal per priority. If you have only one goal, you do not have an SLA system, just one time limit.
Mistake 4: Breach alert sent after the fact
Mistake The "SLA breached" email arrives when the breach has already happened. There is no time to react.
Correct Use the trigger "X minutes before breach". The alert should give time to intervene, not just document the breach.
Mistake 5: Priorities without definitions, set intuitively
Mistake One technician marks a password reset as P2, another as P4. SLA reports are inconsistent and useless.
Correct Create an internal priority matrix (like the table above) and enforce it as a team policy. Standardize through automation: ticket type → default priority.
Related articles
10 Jira automation rules you must know [2026] Jira Service Management vs traditional Service Desk: TCO analysis ManageEngine SDP vs Jira Service Management: comparisonFrequently asked questions
How many SLA policies should I create in Jira Service Management?
For companies of 50-300 people the optimal number is 2-4 SLA policies: (1) Time to first response, (2) Time to resolution, optionally (3) Time to assign for critical incidents. More policies increase configuration and reporting complexity without proportional value. Each policy can have separate conditions and goals per priority.
How does the working calendar in SLA JSM work and when should I configure it?
The working calendar in JSM (Service Management > Calendars) defines the hours during which SLA time is counted. By default JSM counts time 24/7, meaning a ticket submitted Friday at 23:00 may breach a "time to respond: 4h" SLA already at 3:00 in the morning. Configure a calendar 8:00-17:00, Mon-Fri, and assign it to the SLA policy for P3 and P4. For P1 (critical) leave it 24/7.
How does a queue differ from a JQL filter in JSM?
A queue in JSM is a view in the technician panel with a defined display order: the technician sees what to handle first. A JQL filter is a search query you can save and reuse anywhere: in a queue, dashboard, report, or automation. A queue contains a JQL filter as its definition plus column configuration and permissions. You create a JQL filter and then use it as the basis for a queue.
How do I configure SLA breach escalation to Microsoft Teams instead of email?
In JSM Automation create a rule: Trigger = SLA threshold breached, Action = Send web request (webhook). Copy the Incoming Webhook URL from the Teams channel (Manage channel > Connectors > Incoming Webhook) and paste it as the request URL. (Note: Microsoft is retiring Office 365 Connectors in 2025. The recommended method is Microsoft Workflow - Power Automate with the "Post to Teams channel" action.) Set method POST, Content-Type: application/json, body: {"text": "SLA Breach: {{issue.key}} | Priority: {{issue.priority.name}} | Assignee: {{issue.assignee.displayName}}"}. The message will appear in Teams immediately after the breach.
How do I measure SLA effectiveness after configuration: which metrics to track?
Three key metrics: (1) SLA Met %, the percent of tickets handled on time, minimum target 95% for P3/P4 and 99% for P1/P2. (2) Breach by priority, the distribution of breaches per priority, shows where the system has gaps. (3) Breach by agent, which identifies overloaded technicians or mis-assigned tickets. In JSM you will find them in Reports > SLA. Supplement with Eazybi or built-in dashboards for weekly trends.
Audit of your help desk SLA
We will analyze your current SLA configuration in JSM or another help desk tool. We will point out gaps in policies, calendar errors, and escalation rules that only work on paper. No theory, a concrete report, and a list of fixes.
Order an SLA audit →Want to roll out JSM or ManageEngine with a correctly configured SLA? See what a Rotech Group implementation looks like →