Skip to main content
Service Level Agreements (SLAs) define the expected response and resolution times for support tickets, ensuring consistent service quality and meeting customer commitments.

Overview

Frappe Helpdesk’s SLA management system:
  • Automatically applies SLAs to tickets based on conditions
  • Tracks response and resolution times
  • Accounts for working hours and holidays
  • Provides real-time SLA status indicators
  • Supports multiple SLAs with different priorities

SLA Components

Each SLA consists of:

Basic Information

  • Service Level Name: Unique identifier for the SLA
  • Description: Purpose and scope of the SLA
  • Enabled: Active/inactive status
  • Default SLA: Apply to all tickets without specific SLA

Time Commitments

  • Response Time: Time to first agent response
  • Resolution Time: Time to resolve the ticket
  • Priority-based targets: Different times for each priority level

Working Hours

  • Service Days: Which days support is available
  • Start/End Times: Business hours for each day
  • Holiday List: Days when support is unavailable

Assignment Conditions

  • Condition Rules: When to apply this SLA
  • Ticket Properties: Priority, type, team, custom fields
  • Multiple SLAs: Priority-based SLA selection

Creating an SLA

1

Navigate to SLA Settings

Go to Settings > Service Level Agreements
2

Create New SLA

Click “New” to create a new service level agreement
3

Basic Details

Enter name, description, and enable the SLA
4

Configure Working Hours

Set business hours for each day of the week
5

Set Holiday List

Select or create a holiday list for non-working days
6

Define Priorities

Configure response and resolution times for each priority
7

Set Conditions

Define when this SLA should apply to tickets
8

Save & Activate

Save the SLA to make it active

Working Hours Configuration

Define when your support team is available:

Setting Business Hours

Example Working Hours:
  Monday:
    Start: 09:00 AM
    End: 05:00 PM
  Tuesday:
    Start: 09:00 AM
    End: 05:00 PM
  Wednesday:
    Start: 09:00 AM
    End: 05:00 PM
  Thursday:
    Start: 09:00 AM
    End: 05:00 PM
  Friday:
    Start: 09:00 AM
    End: 05:00 PM
  # Saturday and Sunday not listed = no coverage
SLA timers only count business hours. A 4-hour response time doesn’t include nights, weekends, or holidays.

Holiday Lists

Create holiday calendars:
  • Company holidays
  • National holidays
  • Regional variations
  • Special closure days
Create separate holiday lists for different regions if you have global support teams.

Priority Configuration

Set different time targets for each priority level:

Priority Table

PriorityResponse TimeResolution Time
Low24 hours7 days
Medium8 hours3 days
High4 hours1 day
Critical1 hour4 hours

Apply SLA for Resolution

Optional toggle:
  • Enabled: Track both response and resolution times
  • Disabled: Track response time only
Some organizations only commit to response times, not resolution times, as resolution depends on issue complexity.

SLA Assignment Conditions

Control which tickets get which SLA:

Default SLA

The simplest approach:
  • Mark one SLA as “Default”
  • Applies to all tickets without a specific match
  • No conditions needed

Conditional SLAs

Apply SLAs based on ticket properties:
# Python expression
doc.priority == "High" and doc.ticket_type == "Bug"

Condition Examples

doc.customer in ["Premium Corp", "Enterprise Inc"]
doc.priority == "High" and doc.ticket_type == "Bug"
doc.agent_group == "Technical Support"
doc.priority in ["High", "Critical"] and 
doc.ticket_type == "Bug" and 
doc.agent_group == "Engineering"

SLA Status Tracking

Tickets show real-time SLA status:

Agreement Status Values

First Response Due

Awaiting first agent response

Resolution Due

First response sent, working toward resolution

Fulfilled

All SLA commitments met

Failed

Missed response or resolution deadline

Paused

SLA timer paused (ticket on hold)

SLA Fields on Tickets

  • SLA: Which service level agreement applies
  • Response By: Deadline for first response (with countdown)
  • Resolution By: Deadline for resolution (with countdown)
  • Agreement Status: Current SLA state
  • On Hold Since: When SLA was paused
  • Total Hold Time: Cumulative paused duration

SLA Application Logic

How SLAs are automatically applied:
1

Ticket Created

New ticket is saved to the system
2

Evaluate Conditions

System checks all SLAs with conditions
3

Match Priority

If multiple SLAs match, highest priority wins
4

Apply Default

If no conditions match, use default SLA
5

Calculate Deadlines

Compute response_by and resolution_by based on working hours
6

Start Tracking

Begin monitoring SLA compliance

SLA Timer Behavior

Timer Start

SLA tracking begins when:
  • Ticket is created
  • SLA is applied or changed
  • Ticket is reopened (new response timer)

Timer Pause

SLA timers pause when:
  • Ticket status category is “Paused”
  • Ticket is on hold
  • Waiting on customer (optional configuration)

Timer Resume

Timers resume when:
  • Ticket returns to “Open” status
  • Hold is removed
  • Customer responds
Paused time is tracked separately and doesn’t count against SLA commitments.

Working Hours Calculation

SLA deadlines account for business hours:

Example Calculation

Ticket created: Friday 4:00 PM
Working hours: 9 AM - 5 PM, Mon-Fri
Response time: 4 hours

Calculation:
- Friday 4:00 PM to 5:00 PM = 1 hour
- Weekend = 0 hours (not counted)
- Monday 9:00 AM to 12:00 PM = 3 hours

Response deadline: Monday 12:00 PM

Outside Working Hours

Tickets created outside working hours:
  • Flagged with “Raised outside working hours”
  • SLA countdown starts at next business hour
  • Customer may see notification about delayed response

SLA Status in Agent View

Agents see SLA information prominently:

Ticket List

  • Response By column with countdown
  • Resolution By column with countdown
  • Color coding for urgency (red = overdue, yellow = due soon)
  • SLA status badge

Ticket Detail

Dedicated tab showing:
  • SLA name and details
  • Response deadline and status
  • Resolution deadline and status
  • Time remaining/overdue
  • Pause/resume controls

SLA in Customer View

Customers see estimated times:
  • “We typically respond within 4 hours”
  • “Expected resolution by [date/time]”
  • Working hours notification if ticket created outside business hours
Setting customer expectations with visible SLA commitments improves satisfaction even when issues take time to resolve.

Pausing SLAs

Manually pause SLA timers:

When to Pause

  • Waiting for customer information
  • Escalated to third party (vendor, etc.)
  • Temporarily blocked by external factors

How to Pause

  1. Change ticket status to a “Paused” category status
  2. SLA timers automatically pause
  3. “On Hold Since” timestamp is recorded
  4. Resume by changing to “Open” category status
Clearly communicate with customers when tickets are on hold and why.

SLA Violations

When deadlines are missed:

Failure Detection

  • Automatic detection when deadlines pass
  • Agreement status changes to “Failed”
  • Visual indicators in ticket list and detail

Notifications

Optional alerts for:
  • SLA approaching deadline (warning)
  • SLA violated (failure)
  • Agent assignments on overdue tickets

Reporting

  • SLA compliance reports
  • Violation trends
  • Agent/team performance
  • Customer-specific compliance

Multi-SLA Scenarios

Different SLAs for Different Customers

Enterprise setup:
Premium SLA:
  Condition: doc.customer_type == "Enterprise"
  Response: 1 hour
  Resolution: 4 hours

Standard SLA:
  Condition: doc.customer_type == "Standard"
  Response: 8 hours
  Resolution: 3 days

Default SLA:
  Condition: None (default)
  Response: 24 hours
  Resolution: 7 days

Priority-Based SLAs

Critical Issues SLA:
  Condition: doc.priority == "Critical"
  Response: 30 minutes
  Resolution: 2 hours
  
Normal Issues SLA:
  Condition: None (default)
  Response: 8 hours
  Resolution: 3 days

Default Ticket Status

SLAs can define default statuses:
  • Default Ticket Status: Status when ticket is created
  • Ticket Reopen Status: Status when customer replies to resolved ticket
If not set in SLA, these values fall back to global HD Settings configuration.

Best Practices

Don’t promise faster response times than your team can deliver. It’s better to under-promise and over-deliver.
Different issue types deserve different response times. Match SLA to business impact.
If you have global customers, consider 24/7 SLAs or clearly communicate working hours.
Regularly review SLA performance and adjust targets or resources as needed.
Use pause feature when truly waiting on external factors, but don’t abuse it to hide poor performance.
Make sure customers know your SLA commitments and what they mean.

Reporting & Analytics

Track SLA performance:

Key Metrics

  • SLA Compliance Rate: Percentage of tickets meeting SLA
  • Average Response Time: Actual vs committed
  • Average Resolution Time: Actual vs committed
  • Violations by Type: Which SLAs are hardest to meet
  • Violations by Agent/Team: Performance comparison

Reports

Compliance Report

Overall SLA adherence over time

Violation Report

Detailed list of all SLA failures

Team Performance

SLA metrics by team

Customer Report

SLA compliance per customer

Troubleshooting SLA Issues

  • Check SLA is enabled
  • Verify conditions match ticket properties
  • Ensure default SLA is set if no conditions match
  • Check SLA validity dates if configured
  • Verify working hours are correct
  • Check holiday list is accurate
  • Confirm priority settings match intended targets
  • Ensure timezone is configured correctly
  • Confirm ticket status category is “Paused”
  • Check if custom statuses are properly categorized
  • Verify first response was recorded correctly
  • Check if resolution criteria are met
  • Ensure status changes are saving properly
Test new SLAs with sample tickets before applying to production to ensure calculations are correct.

Build docs developers (and LLMs) love