Service Level Agreements (SLAs) in the Thena platform help organizations define, track, and maintain service standards for ticket resolution. This feature enables teams to set up granular policies based on various criteria and monitor performance against defined targets.

Core purpose

SLAs establish clear expectations for response and resolution times, helping teams prioritize work and maintain consistent service quality. The system supports multiple metrics, business hours, and complex policy conditions.

​
Key concepts

SLA metrics

• First response time
• Next response time
• Resolution time
• Update time

Policy criteria

• Ticket properties
• Customer attributes
• Time-based rules
• Custom conditions

​
Understanding response time metrics

Key response time metrics:
  • First response time: Time to first agent response after ticket creation
  • Next response time: Time between customer comments and subsequent agent responses
  • Update time: Regular updates at fixed intervals (e.g., every 30 minutes for incidents)
  • Resolution time: Total time to resolve the ticket, considering business hours and pauses
Update time specific characteristics:
  • Run on fixed intervals (e.g., 30 minutes for incidents)
  • Are not reset by agent responses
  • Continue on the original schedule regardless of early updates
  • Require regular updates even if there are other interactions
The first response time metric measures how long it takes for the first agent response after a ticket is created.

​
Common scenarios

Multiple agent responses before customer reply don’t reset or affect the SLA timer.

​
Business hours calculation examples

Example details:
  • Ticket created Monday 10:00 AM
  • Business hours: 9 AM - 5 PM
  • 5-hour SLA requirement
  • Monday: 7 hours counted (10 AM - 5 PM)
  • Tuesday: Needs 3 more hours, counted from 9 AM
  • SLA breaches Tuesday at 12:00 PM if not resolved

​
Complex SLA scenarios

When priority changes from High (4hr SLA) to Urgent (2hr SLA):
  • Time already elapsed (1hr) is considered
  • New breach time = Current time + (New SLA duration - Elapsed time)

​
SLA policies

​
Policy components

1

Basic information

  • Policy name and description
  • Entity type (e.g., ticket)
  • Priority level
  • Active status
2

Target metrics

  • First response time targets
  • Next response time targets
  • Resolution time targets
  • Update time requirements
3

Conditions

  • Ticket-based filters (priority, type, channel)
  • Customer attributes (tier, region, SLA tier)
  • Time-based conditions
  • Business hours and holidays
4

Pause rules

  • Automatic pause conditions
  • Manual pause capability
  • Resume conditions
  • Multiple pause/resume support

​
Policy ordering

When multiple SLA policies are applicable to a ticket, the system applies the policy with the highest priority in the policy order. This allows for precise control over which policies take precedence.
Example tier-based policies:
  • Platinum tier:
    • First response: 30 minutes
    • Resolution: 4 hours
    • Update frequency: Every 30 minutes
  • Gold tier:
    • First response: 1 hour
    • Resolution: 8 hours
    • Update frequency: Every 2 hours
  • Silver tier:
    • First response: 4 hours
    • Resolution: 24 hours
    • Update frequency: Daily
  • Default:
    • First response: 8 hours
    • Resolution: 48 hours
    • Update frequency: Every 48 hours

​
Dynamic SLA updates

SLA policies can be updated based on ticket changes. The system recalculates breach times considering the time elapsed under previous policies.
Scenario 1: Early upgrade
  • Created: 8 AM (High - 4hr SLA)
  • Updated: 9 AM (Urgent - 2hr SLA)
  • Time elapsed: 1 hour
  • New breach time: 10 AM
Manual Override: Users with appropriate permissions can manually override the SLA policy for specific tickets. This allows for exceptional cases while maintaining the standard policy hierarchy for regular operations.

​
Business hours

Configuration

• Define working hours per day
• Set up multiple time zones
• Configure holiday calendar
• Specify weekend rules

Impact on SLA

• Only count business hours
• Handle timezone differences
• Skip holidays automatically

​
SLA tracking

​
Real-time monitoring

Status indicators

• Time remaining display
• Breach warnings
• Pause status

Notifications

• Breach alerts
• Team notifications

​
API endpoints

​
Sample SLA policy

{
  "name": "High Priority Ticket SLA",
  "description": "SLA policy for handling high priority tickets",
  "entityType": "ticket",
  "teamId": "team-123456",
  "filter": {
    "all": [
      {
        "entity": "ticket",
        "field": "status",
        "operator": "equals",
        "values": [
          {
            "label": "Open",
            "id": "status-1"
          }
        ]
      }
    ],
    "any": [
      {
        "entity": "ticket",
        "field": "priority",
        "operator": "in",
        "values": [
          {
            "label": "High Priority",
            "id": "priority-1"
          },
          {
            "label": "Urgent",
            "id": "priority-2"
          }
        ]
      }
    ]
  },
  "policyMetrics": [
    {
      "metric": "first_time_response",
      "default": true,
      "durationInMinutes": "120",
      "specific": [
        {
          "entity": "ticket",
          "field": "priority",
          "operator": "equals",
          "values": [
            {
              "label": "Urgent",
              "id": "priority-2"
            }
          ],
          "durationInMinutes": "60"
        }
      ]
    },
    {
      "metric": "total_resolution_time",
      "default": true,
      "durationInMinutes": "480",
      "specific": []
    }
  ],
  "pauseConditions": {
    "all": [
      {
        "entity": "ticket",
        "field": "status",
        "operator": "equals",
        "values": [
          {
            "label": "Pending Customer",
            "id": "status-2"
          }
        ]
      }
    ],
    "any": []
  }
}
For detailed API specifications and examples, see Create SLA Policy. The response includes all fields from the request plus these system-managed fields:
  • organizationId: Organization that owns the policy
  • version: Policy version number
  • priority: Policy priority in the evaluation order
  • isActive: Whether the policy is currently active
  • uid: Unique identifier for the policy
  • createdAt: Creation timestamp
  • updatedAt: Last update timestamp

​
Available operations

​
Best practices

1

Policy design

  • Start with broad policies
  • Define clear hierarchies
  • Use specific conditions
  • Regular policy reviews
2

Monitoring and tracking

  • Set up early warnings
  • Track team performance
  • Monitor breach patterns
  • Regular reporting review
3

Team management

  • Clear escalation paths
  • Define team responsibilities
  • Set notification rules
  • Regular team training

Ticket lifecycle

Understanding ticket states and transitions

Ticket priority

Managing ticket priorities