JSM SLA Configuration Guide: Stop Being Afraid and Start Using It

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

"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.

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)

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

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.

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.

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.

Need help configuring SLAs for your team? I work with organizations regularly on JSM implementations including SLA strategy and setup. Book a consultation to get it configured properly from day one.

Questions about SLAs? Join my Skool community where I answer JSM questions regularly.