In most tiered support teams the nightmare isn't actually the first response. It's the escalation. You've got an agent who moves it to L2, L2 then asks engineering for assistance, engineering then need QA and the customer is still waiting on the other side.
At that very instant a rather simple question really has no answer at all: who owns the clock now?
In this article I'm going to show you a practical way of designing internal targets (OLAs) for each handover, an example of how they all add up to a customer SLA and four metrics that show where the escalations are slowing down.
L1 is well covered. Escalations are where it gets blurry
Jira Service Management does a great job for the support front line. Inside a service project, you can set response and resolution goals, use working calendars, and build automation around SLA thresholds.
Escalations are a different story. Once a request leaves L1, the work often moves to other teams and other projects:
- L2 and L3 may work in the same JSM project, but nobody has a target for how long their part should take.
- Engineering usually works in Jira Software, where JSM SLAs aren't available, so the dev part of the wait has no clock at all.
- The request can bounce back and forth between tiers, and each bounce adds time the customer feels but no team owns.
The customer SLA still runs end to end. What's missing is a clear answer to how much of it each team is allowed to use. That's exactly what OLAs (operational level agreements) are for.
Designing an OLA: four questions for every handoff
Before touching any configuration, sit down with the team leads involved and answer four questions for each handoff:
- Owner: which team owns this step? One team per step. If two teams share it, nobody owns it.
- Start: what event hands the work over? Make it something Jira can see, such as a status change to "Escalated to L2" or a linked dev work item being created. "When L2 notices it" isn't measurable.
- Pause: what can legitimately stop the clock? Usually waiting for the customer or a vendor. Keep this list short, because every pause reason is time the customer still feels.
- Target: what's the goal for each priority? A P1 and a P3 shouldn't share a target. Start with what each team can realistically commit to, not what sounds ambitious.
Write the answers down in a shared page (a Confluence page works well) before you configure anything. The conversation between team leads is often more valuable than the numbers themselves.
Example: OLA targets that add up to the SLA
Here's a simplified example for a team with a 24-hour resolution SLA for P1 requests:
- L1 Support: first response within 15 minutes
- L2 Tech support: diagnosis within 2 hours
- L3 and Dev: fix within 12 hours
- QA: verification within 4 hours
Together, that's a little over 18 hours, which leaves a buffer of almost 6 hours inside the 24-hour SLA for reassignments, clarifications and the unexpected.
Two rules of thumb make this work:
- The sum of OLAs should be lower than the SLA. If the internal targets add up to exactly the customer promise, any small delay becomes a breach.
- Review the numbers after a month. Real data will show which targets are too tight and which teams have room to commit to more.
Four escalation metrics worth a dashboard
Once OLAs exist, these four numbers tell you how escalations actually behave:
- Escalation rate: the share of requests that go beyond L1. If it keeps rising, L1 may need better knowledge base articles or clearer triage rules.
- Time in each tier: how long requests spend with L1, L2, dev and QA. This shows which handoff uses most of the SLA.
- Ping-pong: how many times a request bounces between tiers. More than one bounce per escalation usually means the escalation criteria aren't clear.
- OLA compliance per team: the share of handoffs completed within target. Use it to find the team that needs help, not someone to blame.
You can get a first look at the escalation rate natively with JQL, for example:
project = SUP AND status WAS "Escalated to L2" DURING (startOfMonth(-1), endOfMonth(-1))
Compare the count with all requests created in the same period. Time in each tier and OLA compliance are harder to get out of the box, which is where most teams start looking at Marketplace apps.
If your SLAs end at L1, native JSM is often enough. When you need to go beyond its limits and measure the teams behind support, that's the gap SLA Time and Report for Jira is built for:
- OLAs as real targets for each team, with their own start, pause and stop conditions.
- Multiple-Projects SLAs that follow a request from a JSM project into Jira Software and Jira Work Management.
- Goals by priority, customer or any custom field, with several working calendars.
- SLA Grid and charts across projects, plus scheduled reports for team leads.
- Pre-breach notifications right in the Jira work item, so the assignee sees the risk before the deadline. When an SLA is breached, notifications in Slack or Microsoft Teams and automatic actions such as changing the status or the assignee.
It works on Cloud, Data Center, Isolated Cloud and Atlassian Government Cloud, and it runs alongside your native JSM SLAs, so you can set up one OLA, compare it with what you have today, and decide from there.
Quick answers
Does every tier need its own OLA? No. Start with the handoff that hurts most, usually L2 to engineering, and add others once the first one is stable.
Should customers see OLAs? No. OLAs are internal commitments. Customers see the SLA; OLAs help the team keep it.
Where should an OLA live if developers work in Jira Software? Ideally on the work item where the work happens. Native JSM SLAs can't be added to Jira Software projects, so teams either track only the JSM side or use an app that supports SLAs across project types.
What if teams disagree on targets? Start with last month's real data for each step, agree on a target slightly better than today, and review it after a month.
Your turn
How does your team handle escalations today? Do you have internal targets for L2, L3 or engineering, or does the customer SLA cover everything? Share your setup in the comments. I'm especially curious how teams measure the dev side of escalations. 🙌
