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

[#1]

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.

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.

Interested? Come and shape it with us 🚀

If you work with SLAs in Jira Service Management and want a direct say in where they go next, we would love to talk to you. Spots are limited, and every conversation genuinely influences the direction we take.

👉 Sign up to co-design the future of SLAs

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

[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:

1. 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.
2. 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...