Using the 85th Percentile in Jira to Set SLA Targets Your Support Team Can Actually Hit

[#1]

Every support team has SLA targets. The question is: where did those targets come from?

In most cases, the answer is uncomfortable. Someone picked a round number, four hours, eight hours, or one business day, that sounded reasonable in a planning meeting. Or the target was inherited from a previous system, a vendor requirement, or a contract clause nobody fully interrogated. The team then spends months missing those targets, escalating, and wondering whether the problem is capacity, process, or something else entirely.

There is a better starting point. It’s already sitting in your Jira data. And it’s called the 85th percentile.

What the 85th Percentile Actually Means

The 85th percentile shows how long it takes to resolve most tickets in real working conditions.

If your 85th percentile for P2 issues is six hours, it means 85 out of 100 tickets are resolved within six hours. That includes busy mornings, complex tickets, shift changes, and normal day-to-day delays.

This matters because averages often hide the real picture. One ticket stuck for two days can distort the entire average. The 85th percentile removes that noise and shows what your team can consistently achieve most of the time.

That is why many support teams use it for SLA planning. It helps set targets based on actual performance, not ideal conditions or rare worst-case incidents. The median tells you what a typical ticket looks like.
 

The 85th percentile tells you what customers can reasonably expect, even on tougher days.

Why Average Resolution Time Sets You Up to Fail

Most teams reach for the average first. It’s familiar, it’s easy to calculate, and it sounds objective. The problem is that averages are easily distorted by extreme values. A handful of tickets that took three days to close, because they involved a third-party vendor, a complex investigation, or a customer who didn’t respond for a week, can inflate your average dramatically.

If you set your SLA target at the average, you’re anchoring on a number that’s been pulled upward by the cases your process doesn’t really control. Then, when you miss the target, you can’t tell whether the problem is systematic or exceptional.

The 85th percentile sidesteps this entirely. It tells you what your team can commit to with genuine confidence, not what happens when everything goes perfectly, and not what the outliers drag it to.

How to Read Your Jira Data for SLA Target-Setting

Before you can set a defensible SLA target, you need to answer three questions about your current workflow: 

1. What is the median resolution time by priority level?
2. What is the 85th percentile resolution time by priority level? 
3. And which workflow stage is consuming the most time, and is that where you expect it?

RVS Time in Status Reports surfaces all three directly. Here’s how to run the analysis in practice.

• Install RVS Time in Status Reports from the Atlassian Marketplace. Setup takes under 10 minutes. No configuration layer, no parameter sets. Grant permissions and you’re ready to run reports on day one.
• Select report types, such as Time in Status Report and then select the “Group by” option. Then group it according to priority and issue type. 
• Select the Display unit as the 85th percentile
• Read the Time in Status breakdown by workflow stage. Total resolution time tells you how long a ticket took end-to-end. Time in status tells you where that time actually went. Open the status-level breakdown and look at which stages are accumulating dwell time. Is it “Waiting for Assignment” before anyone picks up the ticket? Is it “Pending Customer” where the clock is running, but the work is blocked externally? The stage breakdown separates the time your team controls from the time it doesn’t.

A Practical Approach to Setting Targets by Priority

Here is a straightforward methodology for using your Jira data to set SLA targets your team will actually hit:

• Pull time in status data for the last 90 days, segmented by priority. Ninety days gives you enough volume to smooth out anomalies while staying relevant to your current workflow and team size.
• Record the median and 85th percentile resolution time for each priority level. These are your baseline numbers. They reflect what your process actually delivers today.
• Identify the status stages consuming the most time. For each priority level, look at where the bulk of the elapsed time is sitting. Is it in active work stages or waiting stages? Is the waiting time within your team’s control?
• Set your SLA target at or slightly inside your current 85th percentile. If your 85th percentile is six hours, a five-hour SLA target is ambitious but achievable. It gives your team a real target, not an impossible one.
• Reassess every quarter. As your team improves its process, the 85th percentile will shift. Your SLA targets should move with it, or stay fixed while you track how your team is trending against them.

Communicating SLA Targets Backed by Data

There is a significant difference between telling a stakeholder “we aim to resolve P2 issues within six hours” and telling them “our current 85th percentile resolution time for P2 issues is 5.8 hours, and we’re committing to six hours as our SLA target.”

The second version is credible. It shows the target was set from evidence, not optimism. It shows you understand your own process. And it gives you a defensible basis for the conversation when performance varies, because you can show the underlying data, not just assert that the team is trying hard.

This is what percentile-based SLA reporting gives support leads and ops managers: the ability to have an adult conversation about service commitments, grounded in what the workflow actually produces.

Getting This Data Out of Jira: Try RVS Time in Status Reports

The analysis described above is available in Jira today if you have the right tool running.

RVS Time in Status Reports is a Jira plugin built entirely around workflow visibility. Trusted by 1800+ Jira teams, it gives process, ops, and support teams 20+ focused report types, every one designed to answer the same question: where is work getting stuck, and for how long?

Here’s what you get out of the box:

• Median and 85th percentile calculations surfaced as first-class, clearly labeled report types
• Time in status broken down by status, assignee, or issue group
• Time between statuses, see the handoff gap, not just dwell time within a stage
• Cycle time, lead time, and resolution time trend analysis over multiple periods
• Dashboard gadgets and configurable working calendar
• Native JSON feed for Power BI and CSV/Excel export

Final Thoughts

SLA targets set without data are guesses. They might be educated guesses, reasonable-sounding numbers from experienced people, but they’re still guesses. And when your team consistently misses them, neither you nor your stakeholders can tell whether the target was wrong to begin with or whether there’s a genuine process problem to fix.

The 85th percentile changes that. It takes the historical record of what your team actually delivers and turns it into a defensible, achievable commitment. It gives you a floor to work from and a direction to improve toward. It makes the conversation with stakeholders honest and the conversation with your team fair.

The data is already in Jira. You just need a way to surface it.

RVS Time in Status Reports is built to do exactly that, nothing more, nothing less.