TL;DR
A service level agreement (SLA) sets the response and resolution times your service desk commits to, usually by priority. Good SLAs are based on your current performance, measured in business hours, paused while you wait on the customer, and backed by internal agreements (OLAs) with the teams you depend on. In Jira Service Management, each SLA is a set of start, pause and stop conditions plus goals and a calendar, and automation can warn you before one breaches. Pair SLAs with an experience measure, because hitting every target doesn't guarantee happy users.
Service level agreements are the promises a service desk makes: how quickly it will respond, and how quickly it will fix things. Set well, they focus a team on what matters and give the business confidence. Set badly, they become a number everyone games or ignores.
This guide covers how to set SLAs that work, and how to configure them in Jira Service Management.
SLAs, OLAs and XLAs
- Service level agreement (SLA): the commitment to the people you serve, such as "we'll respond to a critical incident within 15 minutes".
- Operational level agreement (OLA): an internal agreement between teams that makes the SLA achievable, such as the network team agreeing to pick up escalations within 30 minutes.
- Underpinning contract: the equivalent with an external supplier.
- Experience level agreement (XLA): a measure of how people experience the service, such as satisfaction or effort, which complements SLAs rather than replacing them.
The shift towards experience is reflected in ITIL Version 5, released by PeopleCert in early 2026, which puts digital experience and outcomes at the centre of service management.
Step 1: Define your services and priorities
Before you set a single target, agree what you are measuring. List the services you provide and define priority levels in terms of business impact and urgency, for example:
- Critical: a business-critical service is down for many people, with no workaround.
- High: a major service is degraded, or one person can't work.
- Medium: something is broken but there is a workaround.
- Low: questions, minor issues and standard requests.
Write the definitions down and put examples in the portal, so people and agents choose priorities consistently.
Step 2: Choose the right metrics
Most service desks need only two SLAs to start:
- Time to first response: how quickly a person acknowledges the request.
- Time to resolution: how quickly it is fixed or fulfilled.
Add others only when they drive a real decision, for example time to approve changes, or service availability for critical systems. Every extra SLA adds noise.
Step 3: Set targets from your baseline
Look at how long requests take today, by priority, and set targets you can meet most of the time, then tighten them as you improve. Targets plucked from another organisation's SLA almost always fail. As a starting point only, many internal IT service desks use targets along these lines:
| Priority | First response | Resolution |
|---|---|---|
| Critical | 15 minutes | 4 business hours |
| High | 1 business hour | 1 business day |
| Medium | 4 business hours | 3 business days |
| Low | 1 business day | 5 business days |
Step 4: Measure in business hours, with the right calendars
An SLA measured around the clock makes every overnight request look late. Use calendars that reflect when each team actually works. In Australia that usually means more than one: teams in Perth, Brisbane and Sydney work in different time zones for much of the year, and public holidays differ by state. Critical incidents may run on a 24/7 calendar while everything else uses business hours.
Step 5: Decide when the clock pauses
Pause the clock when you are waiting on the person who raised the request, or on a scheduled event such as a change window. Without pause conditions, agents close requests early to protect the number, which is exactly the behaviour you don't want.
Step 6: Escalate before you breach
An SLA is most useful before it is missed. Set warnings, for example at 75% of the time elapsed, that notify the assignee and team lead, and escalate critical requests automatically.
Step 7: Report and review
Review SLA performance monthly, by priority and request type. Look for patterns: one request type that always breaches usually has a process or OLA problem, not a people problem. Review the targets themselves every six to twelve months.
How to set up SLAs in Jira Service Management
Jira Service Management builds each SLA from a few parts (Atlassian's documentation covers each in detail):
- Conditions: when the clock starts (for example, when the request is created), pauses (for example, status "Waiting for customer") and stops (for example, when it's resolved). Any start condition starts the clock, and the first stop condition met stops it.
- Goals: a time target plus a calendar, applied to the requests a JQL query selects. Goals are usually grouped by priority, and the timer adjusts if the priority changes.
- Calendars: a time zone, working days, working hours (including split shifts) and holidays. The default is 9am to 5pm, so change it.
- JQL functions: build queues and filters such as breached(), remaining() and withinCalendarHours(). For example,
"Time to resolution" < remaining("2h")finds requests due within two hours. - Automation: the "SLA threshold breached" trigger fires when an SLA has breached or is about to, so you can notify, reassign or escalate automatically.
- Reports: the built-in and custom reports show SLA performance over time, which you can filter by team or request type.
Practical tips: create a separate calendar for each region you support, name SLAs plainly ("Time to first response", "Time to resolution"), and test every goal with sample requests before go-live. If you use several service projects, keep SLA names consistent so reporting compares like with like.
Common SLA mistakes
- Too many SLAs. Start with response and resolution.
- Targets without a baseline. Set them from your data, not someone else's contract.
- No pause conditions. They encourage closing requests early.
- SLAs without OLAs. If the teams you escalate to have no commitments, your SLA depends on goodwill.
- Watermelon reporting. Green on the outside, red inside: every SLA met while users are unhappy. Add an experience measure.
How Great Minds helps
Great Minds is an Atlassian Silver Solution Partner. We help service teams design SLAs, OLAs and experience measures, configure them in Jira Service Management, and connect the platform to the systems around it. For a mid-sized financial services company, our work cut average incident resolution from five hours to three and a half.
Frequently asked questions
What's the difference between an SLA and a KPI?
An SLA is a commitment to the people you serve, with a target. A KPI is any measure you track to manage performance. SLA attainment is usually one of your KPIs.
Should internal IT have SLAs?
Yes. They set expectations with the business, help prioritise work and show where processes or staffing need attention.
What's a good SLA attainment rate?
There's no universal number: agree one with the business that reflects how much each priority matters. Hitting 100% every month usually means the targets are too loose to drive improvement.
What is an XLA?
An experience level agreement measures how people experience the service, such as satisfaction or effort. It complements SLAs, which measure speed.
Where to start
Pull the last three months of resolution times by priority from your current tool. Set your first targets just inside what you achieve most of the time, add calendars and pause conditions, and review in a month. If you'd like help, talk to us.