nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Co-design SLAs in Jira Service Management - we want your help!

Ash Young

TL;DR: We're working on a substantial redesign of SLAs in Jira Service Management to make them more scalable, easier to create, maintain and far more insightful.

We're looking for admins and team leads who work with SLAs to co-design this with us. If that sounds like you, sign up here to take part and shape what comes next.

Update: 17th August 2026 - Thank you for all that signed up an participated! We'll keep you all updated on the progress of SLAs and the upcoming releases!

Hi SLA enthusiasts 👋

SLAs are one of the hardest-working parts of Jira Service Management. They quietly sit behind your service desk, keeping teams accountable and customers informed. But if you have ever set one up, tuned it as your team grew, or tried to work out why a target behaved the way it did, you will know they can also be one of the trickier things to get right.

We think SLAs deserve better, so we have started work on a meaningful redesign. This is not a small tweak. We're rethinking the experience end to end, and we would love to build it alongside the people who use it every day.

What we're trying to achieve

We're focused on three things that we hear matter most:

Easier to create and maintain. Setting up and changing SLAs should feel straightforward and safe, so you can make the change you need with confidence and get on with your day.
More scalable. As your service desk grows, your SLAs should grow with you without becoming fragile or unwieldy. We want them to hold up whether you are running a handful of targets or a complex, high-volume operation.
More insightful. Your SLAs should tell you a clear story about how your service is really performing, so you can turn that understanding into concrete improvements for your service desk.

We're keeping the specifics open on purpose. This is early, and the best version of this will be shaped by real conversations rather than assumptions on our side.

What co-designing looks like

It's genuinely low effort and high impact. You would join a short, friendly conversation with our team where we walk through ideas, listen to how you work today, and get your reactions to early thinking. There are no wrong answers, and you do not need to prepare anything. You just bring your experience, and we do the rest.

Concepts! - but save feedback for the comments or an interview.

Here are some early concepts to get you in the right headspace. We hope you have strong opinions and can join us to shape what SLA’s could look like in it’s next version.

Screenshot 2026-07-09 at 2.39.14 PM.png

Screenshot 2026-07-09 at 2.38.20 PM.png

Screenshot 2026-07-09 at 2.38.40 PM.png

Thanks in advance. We're excited to build this with you.

Comments

Dave Mathijs

@Ash Young Nice to see SLAs evolving.

I'd like to see more native support for different timezones (rather than defining a separate goal for each timezone). When a ticket is assigned to a Team/Assignee in a different timezone, SLA should be calculated accordingly to the business hours in local time.

Susanne Pietschmann

Thanks for involving the community in the SLA design process!

One improvement I would find very helpful is the ability to define and display SLA targets not only in hours, but also in days or even weeks. For longer-running requests, projects, approvals, or change-related workflows, expressing goals such as "5 business days" or "2 weeks" is often more intuitive and easier for both agents and customers to understand than converting everything into hours.

Having flexible time units for SLA configuration and reporting would greatly improve readability and usability, especially for organizations with a mix of short-term and long-term service commitments.

Thank you!

__ Jimi Wikman

Number one request:
Break out SLAs from custom fields. An SLA should not count towards custom fields. They should be their own data object.

Number two:
Divide SLAs into SLAs and Counters. They are not the same. How long it takes for a customer to respond to a ticket is NOT a Service Level Agreement. It is just a counter.

Number 3:
SLAs need to be connected to Services, and the Service Tier should determine SLA levels. Service Tier should be built into SLAs.

Rilwan Ahmed

Hi @Ash Young ,

See whether you can add SLA Helper in Jira work item and see what SLAs it is mapped to, start time and end time. Something similar to Permission helper in work items.

__ Jimi Wikman

@Rilwan Ahmed You have the SLA section that shows the connected timers, but perhaps you want to add more information to that section?

Or are you referring to having SLAs in Jira and not in Jira Service Management?

__ Jimi Wikman

@Dave Mathijs SLAs don't work that way, as they are contractual obligations counted from the customer's perspective.

Counters, on the other hand, which is what the majority of use for the SLA function is actually about, it depends on what you are counting down towards and how you operate.

Counters have to have a fixed starting time, so I am assuming you are referring to the end time? We already have calendars connected to the counters, so this would be some form of escalation within the same space, I assume, where a new calendar should be used?

Escalations in general are not working very well, but I see your point if the assignee has a different work schedule than the defined one in the counter. It should not be set up that way, though, and I would use the 24/7 calendar if there are multiple time zones involved.

I still see the use case though...

Dave Mathijs

@__ Jimi Wikman

Even if they are contractual obligations counted from the customer's perspective, they are set by the service provider. Furthermore, the SLAs in Jira Service Management are sometimes also used as internal Service Level Objectives (SLOs) (~ KPIs) rather than contractual obligations.

To elaborate on the scenarios:

Customer located in Brazil submits a support request for the local IT team in Brazil. The SLA counter is based on the local service AND the business hours of the local it team in Brazil.
Customer located in Brazil submits a support request for the central IT team located in Brussels, Belgium. The SLA counter is based on the central service AND the business hours of the central IT team in Brussels, Belgium

These 2 scenarios determine when the clock starts/stops counting depending on the Calendar for that specific Service/Support Team. Currently, you need to define a separate goals for each scenario. With a maximum of 90 goals and very complex SLAs (depending on the service and the support team), these guardrails/limits sometimes don't meet our clients' requirements within larger organizations where there's no 24/7 support.

zoltanersek _outpostlabs_dev_

One thing I'd love to see is a proper test mode for SLA changes. Before publishing, let me run a few existing tickets through the new configuration and see exactly which goals would apply, when the timer starts/stops, and why. It would make refactoring complex SLAs much less risky.

__ Jimi Wikman

@Dave Mathijs Agrred. This is what I meant by counters and SLAs not being the same thing.

SLAs are contractual and actually set by the customer, as they decide the price in their contract, which determines the SLA (24/7 costs a lot more than 8/5, for example). SLAs are always open to the customer because that is their way to ensure your services and possibly request penalty fees.

Internal counters still are based on contracts, but internal ones. You define a counter based on what you want to measure against and why, and it is never shown to the customer.

Your examples, if based on SLA are incorrect, however, as that is not how SLAs work. At least unless you have multi-tiered support, which would mean that you should have multiple SLAs based on customer selection or escalation paths defined in the contract with different SLAs.

When you submit a ticket as a customer, you have the starting point at the time the customer submitted the ticket. The counter then counts down to Time to First Response, for example, or time to resolution. If the customer can choose different teams with different SLAs, then your examples can work. If not, then it does not matter who is responding or resolving the ticket, as the SLA is defined from start to finish on a single calendar.

If you escalate a ticket, then the escalation timer is added, ir does not replace the original timer, as that would invalidate the contract since you can no longer measure properly.

If you are referring to internal counters, which would make more sense, then you would do the same. If assigned to another team with a different calendar, then add a second counter for that so you can measure both the original team and the reassigned team. Full time measurement is still required.

This is why, if you have a situation with multiple calendars and time zones, you don't use 8/5 calendars, but 24/7 calendars. This way, it does not matter who is handling the ticket. If the goal is to have time tracking per team, then make sure they have separate spaces. When the original ticket is reassigned, close or pause the timer for that team. The new team will have their counter starting as normal and both teams can be measured.

You can also have multiple statuses if you have to and pause based on what team is handling the ticket...and so on.

This is where clarifications and separation of functionality between actual SLA and internal counters will come in handy. For SLA you should have a strict connection to the contracts, priority, and service tiers, while counters can have more complex handling, like having multiple sub-counters based on team assignment, for example.

It would also make sense to have more scenario-driven counters or possibly even chained ones for internal counters. Perhaps even take them away from SLAs completely and connect them to team resource planning, for example, since the counter would also depend on the number of available resources and so on...

There are many options that can be explored here, and we have not even begun talking about reports where we today measure apples and giraffes with little distinction...

__ Jimi Wikman

@zoltanersek _outpostlabs_dev_ You should probably set things up in a sandbox first, but having the ability to test without publishing is a good idea. It would also be good to be able to trigger automations based on SLA and counter states without having to wait for hours, days and weeks...

Matthew Challenger

We'd love SLA options that are focused around due dates, but recognize this isn't the typical/traditional usage.

As a team that uses Jira Service Management as a marketing request portal, that could be anything from "help put together a pitch/RFP" to "help with planning this event we want to host", it's oftentimes unrealistic to give every request of the same expected x hours to complete timeline. Instead, our goals are more focused on working back from the requested due date to determine how on-time we are.

__ Jimi Wikman

@Matthew Challenger for this, you can actually use Due Date and automations for notifications and more.

You will not get the countdown for it, which would be a nice addition if the countdown could be per ticket and connected to a date or date/time field instead of being predefined.

I like that suggestion.

__ Jimi Wikman

I also think that with a shift in how SLAs are defined (Actual SLAs and counters) I see that counters could be added to Jira and other apps as a way to visualize different things.

I also think it can be useful to have dynamic counters for things like sick leave, where we in Sweden have different periods with different requirements. For example, you need to hand in a medical report after one week, and if you are unfortunate to be sick for an extended period of time, there need to be checks, internal processes kick in, and so on.

Having counters with multiple breakpoints, variable times, and perhaps even exposing some of them to customers and participants... that would be great

Dirk Ronsmans

Perhaps an odd feature but I'd love to be able to create an SLA with all the triggers and notifications available but now have it show up on the work item view.

We often use SLA's as a way to count the time passed before actually sending reminders/closing items/... as it seems to be the only way to take in to account the business hours/holidays/weekends/...

These more functional SLA's have no real value on the work item view itself but are used in the process of the work type. Being able to flag an SLA as "hidden" in it's configuration would clean up the interface already a bit.

Besides that, would be nice if we could set multiple breach points for a single SLA. Yes we can play with the "will breach in x amount of time" or "has been breached for x amount of time" but being able to set certain "milestones" or intermediate goals before a breach would make it clear from the SLA configuration itself and not need to be set in an Automation flow.

Oh and being able to "type" an SLA would also be nice. That would make it clearer whether we are counting an SLA, SLO or UC (underpinning contract)

Luke Schneider_au2tsv

One enhancement we would like to see in the new SLA functionality is the ability to track ticket follow-ups. Specifically, once a ticket has been opened, organizations should be able to define communication intervals that require regular updates to customers.

Today, we ask our technicians to add comments to tickets so that our customers know the ticket is still being worked on, while also providing better communication as we move toward the SLA resolution date. Having an SLA metric that tracks these follow-up requirements would help teams maintain consistent communication and improve the overall customer experience.

__ Jimi Wikman

@Dirk Ronsmans have you considered using automations for this by setting a scheduled automation and then taking actions based on values such as time in status or even due date? If you don't need a visualisation of an SLA, then I use this to trigger events based on time.

@Luke Schneider a common addition to SLA contracts is the update frequency based on priority. You can set this up as an SLA and trigger a status loop on agent comments to track communication cycle success or failures. Some add custom fields for this as well, and you probably could use the calculated fields now to get a percentage... I have not tried that tough

IFLOW Helpdesk

SLA should be configurable based on the request type. Different request types have different expected resolution times. For example, some requests can be resolved within a few hours, while others may require more time due to dependencies such as approvals, third-party involvement, or additional validations.

Allowing SLAs to be defined at the request type level would provide more accurate tracking, realistic expectations, and better reporting.

david_trevino_jackson_com

Glad to see a little love to the SLA configuration. I am not sure I will be able to participate, so dropping a suggestion or two here.

I would love to see the concept of an action/event added. Add an optional section to the SLA goals, to allow you to define an event which occurs when it is met. Some basic standard actions, like updating a field, sending a notification (possibly adding a responder for Operations Enabled instances), could be added/managed from UI, or could define an SLA event, which could be used with a corresponding automation trigger condition to provide additional flexibility.

Ryan Klappenbach

I'd like to see a closer integration with Services so that SLAs can be associated with Service Tiers, including the flexibility for scenarios like a Tier 4 service not being able to have an Emergency/P1 Priority.

Andreas Hausjell

I would have a couple requests and ideas.

In general we are using JSM as a hybrid with Emails and Portal-usage.

Some customers write Emails and tickets are created based on that, some create the tickets directly in the Portal, some use the phone. (Comments working Similar)

1) Negotiable start and endtime.

We come into the situation that a customer calls at 08:10, describes the issue and the call ends after 10 minutes with: "I'll send you an email in a minute": the email creates a ticket at 08:20 -> I would like to change the starting-date easily using a negotiable field to the correct value. (Although 10 minutes are not a big deal, I have other scenarios where it becomes more interesting)

previously we just stored the creation-date in a seperate field and just changed this field if needed.

2) Similar the closure of the ticket. I'm aware that I can choose between first/last/longest cycle, but I have this scenario. We have a status: "Waiting External / Customer Action Requried" which pauses our SLA. We can not solve the incident, because of lack of information or we are maybe not sure if the issue was solved for the customer. So we put the ticket to "Waiting External". SLA is paused. if the customer sends an Email/comments, the ticket changes to "In Progress" again -> SLA continues.

Sometimes the customer answers with an email: "Yeah, thanks. Issue solved". Every minute the agent isn't closing the ticket (which can happen) the SLA is counting up worsening our results a little. So if the agent returns to the desk, closes the ticket, it would come in really handy to say: "Ticket closed with a timestamp like 20 minutes ago".

Also sometimes the agent just presses the resolve-button too late. can happen, and just can't be repaired when using the event-trigger.

3) Maybe a bizarre scenario but now the negotiable starting-time from #1 comes into play again: I would request to have a different calender for Coverage and Resolution-Time.

We have a contract where we say: We solve incidents Prio 3-4 within 24/48 hours during business hours 08:00 - 17:00. so far so good.

BUT, for Prio1-tickets we extend the resolution-time! we say, if there is a Priority-1 issue we solve it within 9 hours on the clock. for Priority 2 tickets we solve it within 18 hours on the clock.

Although that would be the most extreme situation it comes down to to the situation:

Customer opens a priority 1 incident on friday 16:59. we would be supposed to solve it until saturday 2 o'clock in the morning. If the customer would create the ticket friday 17:01 -> time would start monday morning. Doesn't happen too often, but in general we can have calculating issues daily with "afternoon-blockers"

if we use a 24/6 calender in general for this issues, it is working, BUT:

than the time is also counting if the customer creates the ticket ahead of 08:00 or after 17:00.

We already solved this for us and use a SLA with a 24/6-calender and use some scripts to set the starting-time in a negotiable field. we are using a different plugin in general. We could also switch to something, that would fire an event at 08:00 for all tickets created outside of office-hours, but so far we use a plugin which is capable of a negotiable time.

4) probably an easier thing, where I didn't check all given report possibilities yet. We would have a contract to say: We solve 80% of Priority-1 Tickets in 9 hours. we solve 98% of Priority-1 Tickets in 18 hours, and 100% of blockers in 72 hours in a certain period. This is more a nice to have, we mainly make such things in excel, and it's not that relevant if we have less than a couple blockers per month anyway, than always the 80% rule applies anyway.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-administration

administration

itsm

sla

jira-service-management-cloud

jira-service-management

service-desk

service-management

jira-admin

service-level-agreement

jsm