> ## Content Index
> Fetch the complete content index at: https://projectflow.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# JSM SLA Configuration Guide: Stop Being Afraid and Start Using It
- URL: https://projectflow.co.uk/jsm-sla-configuration-guide/
- Published: 2026-01-04T12:14:48.000Z
- Updated: 2026-06-08T07:47:30.000Z
- Author: Mike
- Tags: JSM, tutorial

**Confession time:** People are terrified of SLAs (Service Level Agreements) in JSM. I see it constantly.

New to JSM? Start with [What is JSM](https://projectflow.co.uk/what-is-jsm-jira-service-management/) for the overview.

**"SLAs feel like a police officer watching everything we do."** **"We'll never meet the targets, so why set them?""It's too complicated to configure."**

**All of these are wrong.**

After 14+ years consulting, I can tell you: **SLAs are not your enemy. They're your measurement tool.**

****Need SLAs configured properly without breaking your existing tickets?**  
**I set up and rebuild SLA configurations for clients regularly — Quick Fix from £350, no surprises.*

[→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) 

**When configured properly:**

- ✅ Give you data to improve service delivery
- ✅ Help identify bottlenecks
- ✅ Provide accountability (in a good way)
- ✅ Show management where to invest resources

**When configured poorly:**

- ❌ Cause stress and panic
- ❌ Provide useless metrics
- ❌ Get ignored completely

Let me show you how to do it right.

## What Is an SLA? (Simple Definition)

**SLA = Service Level Agreement**

It's a timer that tracks how long something takes.

**Common SLAs:**

- **Time to First Response** \- How quickly do we respond to new tickets?
- **Time to Resolution** \- How quickly do we solve the problem?
- **Time to Escalation** \- How quickly do we escalate critical issues?

**That's it.** Start timer when ticket created. Stop timer when goal met. Track if you made it.

**Not complicated.**

## The Common Misconceptions

Let me address the fears directly.

### Misconception #1: "SLAs Are Punishment"

**Reality:** SLAs are measurement, not punishment.

**Think of SLAs like a speedometer in a car:**

- Shows your current speed
- Helps you know if you're going too fast or slow
- Doesn't punish you (but helps you avoid tickets)

**Same with SLAs:**

- Shows your current performance
- Helps identify problems
- Doesn't punish agents (helps improve processes)

**If your team is missing SLAs constantly:**

- The SLA targets might be unrealistic (fix the targets)
- You might be understaffed (hire more people)
- Processes might be inefficient (improve workflows)

SLAs depend on workflow configuration. See my [Workflow Guide](https://projectflow.co.uk/jira-workflow-customization-guide/) for status setup.

**The SLA didn't cause the problem. It revealed the problem.**

### Misconception #2: "We Need Complex SLAs"

**Reality:** Start simple. 2-3 SLAs is enough for most teams.

**I've seen clients with 10-15 SLAs per request type.** Absolute chaos. Nobody knows what they're tracking. SLAs get ignored.

**My recommendation:**

- **Small teams (< 10 agents):** 2 SLAs maximum
  - Time to First Response
  - Time to Resolution
- **Medium teams (10-50 agents):** 3-4 SLAs
  - Add: Time to Escalation (for high-priority)
- **Large teams (50+ agents):** 4-6 SLAs
  - Different SLAs per issue type (Incident vs Request)

**More SLAs ≠ Better tracking.** Keep it simple.

### Misconception #3: "Out-of-the-Box SLAs Are Terrible"

**Reality:** JSM's default SLAs are actually really good.

**Here's a secret:** When I implement JSM, I often start with the defaults and tweak slightly.

**Default SLAs you get:**

- Time to Resolution
- Time to First Response
- Time to Approval (for approvals)
- Time to Close (rarely used)

**For 80% of teams, you just need:**

- Time to First Response (keep default)
- Time to Resolution (adjust targets)
- Delete the rest

**Start with defaults. Adjust based on real data.**

### Misconception #4: "SLAs Require Constant Monitoring"

**Reality:** Set them and review monthly.

**You don't need:**

- Real-time SLA dashboards on every screen
- Daily SLA meetings
- Agents obsessing over timers

Track SLA metrics on [Jira Dashboards](https://projectflow.co.uk/jira-dashboards-in-2026/).

**You do need:**

- Weekly check: Any breaches? Why?
- Monthly review: Are targets realistic?
- Quarterly adjustment: Based on actual data

**SLAs run in the background. Review results periodically.**

## How SLAs Actually Work (The Mechanics)

Before we configure, understand how they function.

### The SLA Lifecycle

```
1. Ticket Created
   ↓
2. SLA Timer Starts
   ↓
3. Timer Counts (during business hours)
   ↓
4. Timer Pauses (when waiting for customer)
   ↓
5. Timer Resumes (when customer responds)
   ↓
6. Goal Met or Breached
   ↓
7. SLA Stops

```

### Key Components

**Start Condition:**

- When does the timer start?
- Usually: Ticket created

**Goal/Target:**

- How much time allowed?
- Example: 4 hours for first response

**Pause Conditions:**

- When should timer stop temporarily?
- Example: Waiting for customer reply

**Stop Condition:**

- When is SLA complete?
- Example: First comment added (for First Response SLA)

**Calendar:**

- Business hours only? 24/7?
- Which time zone?
- What holidays?

### Business Hours vs 24/7

**Business Hours SLA:**

- Timer only runs 9am-5pm Mon-Fri
- Ticket created Friday 4:55pm with 4-hour SLA
- Timer runs 5 minutes Friday, resumes Monday 9am
- Due: Monday 1pm

**24/7 SLA:**

- Timer always runs
- Ticket created Friday 4:55pm with 4-hour SLA
- Due: Friday 8:55pm (even if office closed)

**My recommendation:** Use business hours unless you have 24/7 support staff.

## Step-by-Step SLA Configuration

Let me show you exactly how to set this up.

### Step 1: Configure Your Calendar (Do This First!)

**This is critical and often skipped.**

**Why it matters:**

- SLAs run on business hours
- Business hours vary by location
- Holidays affect SLA calculations

**To configure calendar:**

1. Go to **Project Settings**
2. Click **SLAs** (left sidebar)
3. Click **Calendars** tab
4. Click on **Default Calendar** (or create new)

**Settings to configure:**

**Time Zone:**

- Select your primary office time zone
- Example: "Europe/London" or "America/New\_York"

**Working Hours:**

- Start time: 9:00 AM
- End time: 5:00 PM
- Working days: Monday-Friday

**Adjust for your team:**

- 24/7 support? Set all days, all hours
- Weekend support? Include Saturday/Sunday
- Extended hours? 8am-6pm, etc.

**Holidays/Bank Holidays:**

- Click **Add Holiday**
- Enter date and name
- SLA timer won't run on these days

**Where to find holidays:**

- UK: https://www.gov.uk/bank-holidays
- US: Federal holidays list
- Search "\[Country\] public holidays 2026"

**Add all holidays for the year.** SLA calculations will account for them.

### Multiple Calendars (For Global Teams)

**If you have offices in different time zones:**

1. Create calendar: "London Office"
  - Time zone: Europe/London
  - Hours: 9am-5pm
  - UK bank holidays
2. Create calendar: "New York Office"
  - Time zone: America/New\_York
  - Hours: 9am-5pm
  - US federal holidays
3. Create calendar: "Sydney Office"
  - Time zone: Australia/Sydney
  - Hours: 9am-5pm
  - Australian public holidays

**Then assign different SLAs to different calendars** based on which team handles the request.

### Step 2: Review Default SLAs

JSM creates default SLAs. Let's see what you have.

1. **Project Settings** \> **SLAs**
2. You'll see a list (probably 4-6 SLAs)

**Common defaults:**

- Time to Resolution
- Time to First Response
- Time to Approval
- Time to Close After Resolution

**My recommendation: Delete what you don't need.**

**Keep:**

- Time to First Response ✅
- Time to Resolution ✅

**Delete (unless you have specific need):**

- Time to Close After Resolution ❌ (not useful for most teams)
- Time to Acknowledgement ❌ (redundant with First Response)

**Don't be afraid to delete.** You can always recreate later.

****Got SLAs that no one understands and nobody trusts?**   
**Cleaning up SLA chaos is one of my most-requested Quick Fix jobs. Single session, clean rebuilt configuration*

[→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) 

### Step 3: Configure "Time to First Response"

This SLA tracks: How quickly do we acknowledge new tickets?

**Click on "Time to First Response"** to edit.

#### Set the Goal

**Goal:** How much time is allowed?

**Example targets:**

- High Priority: 1 hour
- Medium Priority: 4 hours
- Low Priority: 8 hours

**To configure:**

1. Find **Goals** section
2. Click **Add Goal**
3. Configure:
  - **Name:** "High Priority Response"
  - **Time:** 1 hour
  - **Calendar:** Default Calendar (or specific one)
  - **Conditions:** Priority = High
4. Click **Add Goal** again
5. Configure:
  - **Name:** "Normal Priority Response"
  - **Time:** 4 hours
  - **Calendar:** Default Calendar
  - **Conditions:** Priority = Medium
6. Repeat for Low Priority (8 hours)

**Now you have tiered SLAs based on priority.**

#### Set Pause Conditions

**When should the timer stop?**

**My recommendation:**

- Pause when status = "Waiting for Customer"
- Pause when status = "Waiting for Approval"

**Why?** SLA shouldn't run while ball is in customer's court.

**To configure:**

1. Find **Pause Conditions** section
2. Click **Add Condition**
3. Select: Status = "Waiting for Customer"
4. Click **Add**

**Now SLA pauses when you're waiting for customer reply.**

#### Set Stop Condition

**When is this SLA complete?**

For "Time to First Response": **When first comment is added**

**Default setting is usually:**

- Issue Commented

**This is correct.** Leave it.

**Alternative:** Some teams use "First comment from agent" (excludes customer comments)

**To change:**

1. Find **Stop Condition**
2. Select trigger
3. Add condition: "Comment author = Agent" (if needed)

### Step 4: Configure "Time to Resolution"

This SLA tracks: How quickly do we solve the problem?

**Click on "Time to Resolution"** to edit.

#### Set the Goal

**Example targets:**

- Incidents (High): 4 hours
- Incidents (Medium): 8 hours
- Service Requests: 1 business day (8 hours)
- Change Requests: 3 business days (24 hours)

**To configure:**

1. **Add Goal**
  - Name: "Critical Incident"
  - Time: 4 hours
  - Conditions: Issue Type = Incident AND Priority = High
2. **Add Goal**
  - Name: "Standard Incident"
  - Time: 8 hours
  - Conditions: Issue Type = Incident AND Priority = Medium
3. **Add Goal**
  - Name: "Service Request"
  - Time: 24 hours (1 day)
  - Conditions: Issue Type = Service Request

#### Set Pause Conditions

**CRITICAL for Resolution SLA:**

Pause when:

- Status = "Waiting for Customer"
- Status = "Waiting for Approval"
- Status = "Waiting for Third Party"

**Why?** Resolution time should only measure time your team is working.

**To configure:**

1. **Pause Conditions** section
2. Add: Status = "Waiting for Customer"
3. Add: Status = "Waiting for Approval"
4. Add: Status = "Waiting for Third Party" (if you have this status)

#### Set Stop Condition

**Critical:** Resolution SLA stops when **Resolution field is set**, NOT when status changes.

**Why?**

Your workflow might have statuses like:

- Resolved
- Closed
- Done
- Complete

**Which one stops the SLA?** Ambiguous.

**Better:** Stop when Resolution field = "Fixed" or "Done" or "Answered"

**To configure:**

1. **Stop Condition** section
2. Select: "Resolution Set"
3. This works regardless of status

**This is why you should use Resolution field** (not just status changes).

### Step 5: Create Custom SLA (Optional)

**Example:** Time to Escalation for critical issues

**Use case:** P1 incidents must be escalated to senior team within 30 minutes.

**To create:**

1. **Project Settings** \> **SLAs**
2. Click **Add SLA**
3. Name: "Time to Escalation (P1)"
4. Configure:
  - **Goal:** 30 minutes
  - **Conditions:** Priority = Highest
  - **Start:** Issue Created
  - **Stop:** Custom field "Escalated" = Yes (or similar trigger)
  - **Pause:** None (escalation should be immediate)

**Now you're tracking escalation speed for critical issues.**

### Step 6: Test Your SLAs

**Before going live, test!**

1. Create test ticket (high priority)
2. Check: Did SLA start?
3. Add first comment
4. Check: Did "First Response" SLA stop?
5. Move to "Waiting for Customer"
6. Check: Did "Resolution" SLA pause?
7. Move back to "In Progress"
8. Check: Did "Resolution" SLA resume?
9. Set Resolution field
10. Check: Did "Resolution" SLA stop?

**If anything doesn't work: Adjust configuration.**

****Need SLAs tied into reporting and escalations properly?**  
**Full SLA setup with dashboards and alerting is part of every Optimisation Programme I deliver*

[→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) 

## SLA Best Practices (From Real Implementations)

Here's what actually works in production.

### Best Practice #1: Start Conservative

**Don't set aggressive targets initially.**

**Bad approach:**

- "We'll respond in 15 minutes!"
- Agents stressed
- Constant breaches
- SLAs ignored

**Good approach:**

- Track current performance for 2 weeks
- Calculate average response time
- Set SLA target at 80th percentile
- Example: If average is 3 hours, set SLA at 4 hours
- Gradually reduce as processes improve

**Better to meet reasonable SLAs than miss aggressive ones.**

### Best Practice #2: Different SLAs for Different Issue Types

**Incidents ≠ Requests**

**Incidents (Problems):**

- Time to First Response: 1-4 hours
- Time to Resolution: 4-24 hours
- Urgent, breaking issues

**Service Requests (Normal):**

- Time to First Response: 4-8 hours
- Time to Resolution: 1-3 days
- Standard requests, not urgent

**Change Requests:**

- Time to First Response: 8-24 hours
- Time to Resolution: 3-7 days
- Planned changes, longer timeline

**Don't use same SLAs for everything.**

### Best Practice #3: Pause SLAs When Waiting

**This is crucial and often missed.**

**Always pause when:**

- Waiting for customer information
- Waiting for approval
- Waiting for third-party vendor
- Waiting for budget/purchase approval

**Why?** These delays aren't your team's fault. Don't penalize them.

**Configure "Waiting for Customer" status:**

1. Add status to workflow: "Waiting for Customer"
2. Configure SLA pause condition
3. Train team: Move tickets to this status when waiting

**This keeps SLA measurements accurate.**

### Best Practice #4: Use Automation to Resume SLAs

**Problem:** Ticket in "Waiting for Customer", customer replies, ticket stays in that status.

**Solution:** Automation rule

**Rule:**

1. **Trigger:** Issue Commented
2. **Condition:** Comment from = Customer
3. **Condition:** Status = "Waiting for Customer"
4. **Action:** Transition to "In Progress"

**Result:** SLA automatically resumes when customer responds.

### Best Practice #5: Don't Overwhelm with SLAs

**Maximum SLAs per request type:**

- Small teams: 2 SLAs
- Medium teams: 3-4 SLAs
- Large/enterprise: 5-6 SLAs MAX

**If you have more, simplify.**

**Common mistake:** 10 SLAs tracking every tiny thing. Nobody pays attention.

**Better:** 2-3 SLAs tracking what actually matters.

### Best Practice #6: Review SLA Performance Monthly

**Set recurring calendar reminder:**

- Monthly SLA review meeting
- 30 minutes
- Review SLA reports

**Questions to ask:**

- What's our SLA compliance rate? (Target: 80%+ is good)
- Which SLAs are we consistently missing?
- Are targets realistic?
- Do we need more staff? Better processes?

**Adjust targets based on data, not feelings.**

### Best Practice #7: Display SLAs on Tickets

**Make SLAs visible:**

**Agent view:**

- SLA countdown appears on ticket
- Shows time remaining
- Red when approaching breach

**Dashboard view:**

- Create queue for "SLA at risk" tickets
- JQL: `sla = breached() OR sla = elapsed(0, 30m)`
- Shows tickets about to breach

**Visibility drives action.**

## SLA Reporting and Dashboards

SLAs are only useful if you track them.

### Built-in SLA Reports

**JSM includes SLA reports:**

1. **Project** \> **Reports** \> **SLA Performance**
2. You'll see:
  - SLA Success Rate (% met vs breached)
  - SLA Met vs Breached (count)
  - SLA Performance by Priority
  - SLA Performance by Issue Type

**Use these monthly to assess performance.**

### Create SLA Dashboard

**For real-time monitoring:**

1. Create new Dashboard
2. Add gadgets:
  - **SLA Met vs Breached** (pie chart)
  - **SLA Success Rate** (percentage)
  - **Created vs Resolved** (trend)
  - **Filter Results** (current SLA breaches)

**Share with team and management.**

### Key SLA Metrics to Track

**Metrics that matter:**

**SLA Compliance Rate:**

- Formula: (SLAs Met / Total SLAs) × 100
- Target: 80%+ is good, 90%+ is excellent

**Average Time to First Response:**

- How quickly are we acknowledging tickets?
- Track trend over time

**Average Time to Resolution:**

- How quickly are we solving problems?
- Break down by issue type

**SLA Breach Reasons:**

- Why did we miss SLA?
- Categorize: Understaffed, Complex Issue, Waiting Too Long, etc.
- Fix root causes

### Example JQL Queries for SLAs

**Find tickets that breached SLA:**

```
project = "IT Support" AND sla = breached()

```

**Find tickets approaching SLA breach (< 30 min):**

```
project = "IT Support" AND sla = elapsed(0, 30m)

```

**Find tickets with active SLAs:**

```
project = "IT Support" AND status != Resolved AND sla != completed()

```

**SLA compliance last month:**

```
project = "IT Support" AND created >= -30d AND sla = met()

```

## Common SLA Mistakes (And How to Fix Them)

### Mistake #1: 24/7 SLAs with 9-5 Staff

**Problem:**

- SLA runs 24/7
- Team works 9am-5pm
- Constant breaches outside business hours

**Fix:**

- Use business hours calendar
- SLA only runs during working hours

### Mistake #2: No Pause Conditions

**Problem:**

- SLA runs even when waiting for customer
- Agents penalized for customer delays

**Fix:**

- Add "Waiting for Customer" status
- Configure SLA pause condition

### Mistake #3: Too Many SLAs

**Problem:**

- 10-15 SLAs per request type
- Agents overwhelmed
- SLAs ignored

**Fix:**

- Simplify to 2-3 essential SLAs
- Delete the rest

### Mistake #4: Unrealistic Targets

**Problem:**

- "We'll respond in 5 minutes!"
- Constant breaches
- Team stressed

**Fix:**

- Measure current performance
- Set realistic targets (80th percentile)
- Gradually improve

### Mistake #5: Stopping SLA on Status Change

**Problem:**

- SLA stops when status = "Resolved"
- But resolution field not set
- Tickets reopened, SLA already stopped

**Fix:**

- Stop SLA when Resolution field set
- Not based on status

### Mistake #6: Forgetting Holidays

**Problem:**

- Calendar doesn't include holidays
- SLA runs on Christmas Day
- Unrealistic calculations

**Fix:**

- Add all holidays to calendar
- Review annually

### Mistake #7: Not Reviewing Performance

**Problem:**

- SLAs configured, never checked
- No one knows if they're met or breached
- Waste of effort

**Fix:**

- Monthly SLA review meeting
- Track trends
- Adjust as needed

## My Recommended SLA Setup (By Team Size)

Here's my standard configuration for different team sizes.

### Small Team (1-5 Agents)

**SLAs:**

1. Time to First Response
  - Target: 4 hours
  - No priority tiers initially
2. Time to Resolution
  - Service Requests: 1 day
  - Incidents: 4 hours

**Calendar:**

- Business hours: 9am-5pm
- Monday-Friday
- Bank holidays included

**That's it.** Keep it simple.

### Medium Team (5-20 Agents)

**SLAs:**

1. Time to First Response
  - High Priority: 1 hour
  - Normal Priority: 4 hours
  - Low Priority: 8 hours
2. Time to Resolution
  - Incidents (High): 4 hours
  - Incidents (Normal): 8 hours
  - Service Requests: 24 hours
3. Time to Escalation (optional)
  - Critical incidents: 30 minutes

**Calendar:**

- Business hours or extended hours
- Multiple calendars if multiple locations

### Large Team (20+ Agents)

**SLAs:**

1. Time to First Response (tiered by priority)
2. Time to Resolution (by issue type + priority)
3. Time to Escalation (critical only)
4. Time to Approval (for change requests)

**Calendar:**

- Multiple calendars for different regions
- 24/7 calendar for critical support tier
- Business hours for standard support

**Advanced:**

- Different SLAs for different customers (Premium vs Standard)
- Different SLAs for internal vs external requests

## The Honest Reality of SLAs

**After implementing SLAs for hundreds of teams, here's what I've learned:**

### What SLAs Do Well:

✅ Show where you're slow   
✅ Justify hiring decisions ("We're missing SLAs, need more staff")   
✅ Create accountability   
✅ Provide data for improvement   
✅ Help prioritize work (SLA about to breach = urgent)

### What SLAs Don't Do Well:

❌ Automatically improve service (you need to act on data)   
❌ Replace good processes (broken process + SLA = stressed team)   
❌ Solve staffing problems (understaffed team will miss SLAs)   
❌ Measure quality (fast ≠ good, sometimes)

### The Bottom Line on SLAs

**SLAs are a tool, not a solution.**

**They tell you:**

- Are we fast enough?
- Where are bottlenecks?
- Do we need more resources?

**They don't tell you:**

- Are customers happy? (use CSAT surveys)
- Is quality good? (use feedback + review)
- Are we solving root causes? (use problem management)

**Use SLAs as one metric among many.**

## When NOT to Use SLAs

**Controversial take:** Sometimes SLAs aren't worth it.

**Don't use SLAs if:**

- ❌ Team is 1-2 people (just do your best, SLAs add stress)
- ❌ Ticket volume is tiny (< 10/week, not worth tracking)
- ❌ Work is highly variable (creative work, research, consulting)
- ❌ Leadership will weaponize them (creates fear, not improvement)

**SLAs work when:**

- ✅ Repeatable processes
- ✅ Measurable work
- ✅ Data drives improvement (not punishment)
- ✅ Team size justifies tracking

**If you're a 2-person IT team, don't stress about SLAs.** Focus on doing good work.

**If you're a 50-person service desk, SLAs are essential.**

## The Bottom Line

**SLAs aren't scary.** They're timers with targets.

**Start simple:**

- 2 SLAs (First Response + Resolution)
- Conservative targets
- Business hours calendar
- Pause when waiting for customer

**Review monthly:**

- Are we meeting targets?
- Do targets need adjustment?
- Where are bottlenecks?

**Improve based on data:**

- Missing SLAs? Hire staff or improve process
- Meeting SLAs easily? Tighten targets gradually

**SLAs are measurement, not punishment.**

---

****Want SLAs that actually drive the behaviour you want?**  
**Book a free strategy call — let's scope your SLA design end-to-end.* 

[→ Book a Free Strategy Call ](https://projectflow.co.uk/call/) 

---

*Questions? Pushback? Something you'd handle differently? Drop it in the comments below — I read and reply to every single one.*