> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thena.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Service level agreements (SLA)

> Configure and manage SLA policies for tickets

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.

<CardGroup cols={1}>
  <Card title="Core purpose" icon="stopwatch">
    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.
  </Card>
</CardGroup>

## Key concepts

<CardGroup cols={2}>
  <Card title="SLA metrics" icon="gauge">
    • First response time <br />
    • Next response time <br />
    • Resolution time <br />
    • Update time
  </Card>

  <Card title="Policy criteria" icon="filter">
    • Ticket properties <br />
    • Customer attributes <br />
    • Time-based rules <br />
    • Custom conditions
  </Card>
</CardGroup>

## Understanding response time metrics

<Note>
  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
</Note>

<Tabs>
  <Tab title="First response time">
    ```mermaid theme={null}
    sequenceDiagram
        participant Customer
        participant Ticket
        participant Agent
        Customer->>Ticket: Creates ticket
        Note over Ticket: SLA timer starts
        Agent->>Ticket: First response
        Note over Ticket: First response SLA met
    ```

    The first response time metric measures how long it takes for the first agent response after a ticket is created.
  </Tab>

  <Tab title="Next response time">
    ```mermaid theme={null}
    sequenceDiagram
        participant Customer
        participant Ticket
        participant Agent
        Customer->>Ticket: New comment
        Note over Ticket: Next response timer starts
        Agent->>Ticket: Agent responds
        Note over Ticket: Next response SLA met
        Customer->>Ticket: Another comment
        Note over Ticket: New next response timer starts
    ```

    The next response time metric tracks the time between each customer comment and the subsequent agent response.
  </Tab>

  <Tab title="Update time">
    ```mermaid theme={null}
    sequenceDiagram
        participant Ticket
        participant Agent
        Note over Ticket: Update timer starts (30m)
        Agent->>Ticket: Public comment
        Note over Ticket: Update SLA met
        Note over Ticket: Timer continues from original schedule
        Agent->>Ticket: Internal note
        Note over Ticket: No impact on update timer
        Note over Ticket: 30m elapsed - Update needed
        Agent->>Ticket: Public update
        Note over Ticket: Update SLA met
        Note over Ticket: Next 30m interval starts
    ```

    The update time metric ensures regular updates (public comments) on tickets at fixed intervals, regardless of other interactions.
  </Tab>

  <Tab title="Resolution time">
    ```mermaid theme={null}
    sequenceDiagram
        participant Customer
        participant Ticket
        participant Agent
        Customer->>Ticket: Creates ticket
        Note over Ticket: Resolution SLA starts (24h)
        Agent->>Ticket: Initial response
        Note over Ticket: Investigation ongoing
        Agent->>Ticket: Request info
        Customer->>Ticket: Provides info
        Note over Ticket: SLA paused during wait
        Agent->>Ticket: Implements solution
        Agent->>Ticket: Marks as resolved
        Note over Ticket: Resolution SLA met
    ```

    The resolution time metric tracks the total time taken to resolve a ticket, considering business hours and any pause periods.
  </Tab>
</Tabs>

***

### Common scenarios

<Tabs>
  <Tab title="Multiple agent responses">
    ```mermaid theme={null}
    sequenceDiagram
        participant Customer
        participant Ticket
        participant Agent
        Customer->>Ticket: Creates ticket
        Note over Ticket: First response timer starts
        Agent->>Ticket: Agent response 1
        Note over Ticket: First response SLA met
        Agent->>Ticket: Agent response 2
        Note over Ticket: No impact on SLA
        Customer->>Ticket: Customer reply
        Note over Ticket: Next response timer starts
    ```

    Multiple agent responses before customer reply don't reset or affect the SLA timer.
  </Tab>

  <Tab title="Customer updates">
    ```mermaid theme={null}
    sequenceDiagram
        participant Customer
        participant Ticket
        participant Agent
        Customer->>Ticket: Creates ticket
        Note over Ticket: First response timer starts
        Customer->>Ticket: Additional info
        Note over Ticket: Timer continues
        Agent->>Ticket: Agent response
        Note over Ticket: First response SLA met
    ```

    Additional customer comments before first response don't reset the first response timer.
  </Tab>

  <Tab title="Pause and resume">
    ```mermaid theme={null}
    sequenceDiagram
        participant Customer
        participant Ticket
        participant Agent
        Customer->>Ticket: Creates ticket
        Note over Ticket: SLA timer starts
        Agent->>Ticket: Request information
        Note over Ticket: Auto-pause: Pending customer
        Note over Ticket: Timer paused
        Customer->>Ticket: Provides information
        Note over Ticket: Auto-resume: Customer responded
        Note over Ticket: Timer resumes
        Agent->>Ticket: Manual pause (maintenance)
        Note over Ticket: Timer paused
        Note over Ticket: System maintenance period
        Agent->>Ticket: Manual resume
        Note over Ticket: Timer resumes
        Note over Ticket: Only business hours counted
    ```

    Common pause scenarios:

    * **Automatic pauses**: <br />
      • Pending customer response <br />
      • Third-party dependencies <br />
      • Integration sync delays <br />
      • Scheduled maintenance windows <br />

    * **Manual pauses**: <br />
      • Emergency maintenance <br />
      • Major incidents <br />
      • Planned downtimes <br />
      • Customer-requested holds <br />

    * **Business rules**: <br />
      • Only business hours counted during active periods <br />
      • Pause periods completely excluded <br />
      • Auto-resume on specific triggers <br />
      • Pause reason tracking for reporting
  </Tab>
</Tabs>

***

### Business hours calculation examples

<Tabs>
  <Tab title="Basic (5-hour SLA)">
    ```mermaid theme={null}
    sequenceDiagram
        participant Monday
        participant Tuesday
        Note over Monday: 9 AM - Business hours start
        Note over Monday: 4 PM - Ticket created
        Note over Monday: 5 PM - Business hours end (7h counted)
        Note over Tuesday: 9 AM - Business hours resume
        Note over Tuesday: 12 PM - SLA breaches (3h counted)
    ```

    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
  </Tab>

  <Tab title="Weekend spanning (5-hour SLA)">
    ```mermaid theme={null}
    sequenceDiagram
        participant Friday
        participant Weekend
        participant Monday
        Note over Friday: 4 PM - Ticket created
        Note over Friday: 5 PM - Day ends (1h counted)
        Note over Weekend: No hours counted
        Note over Monday: 9 AM - Business hours resume
        Note over Monday: 1 PM - SLA breaches (4h counted)
    ```

    Example details:

    * Ticket created Friday 4:00 PM
    * 5-hour SLA
    * 1 hour counted Friday
    * 0 hours counted on weekend
    * 4 hours counted Monday
    * SLA breaches Monday at 1:00 PM
  </Tab>

  <Tab title="Multiple pause/resume (5-hour SLA)">
    ```mermaid theme={null}
    sequenceDiagram
        participant Monday
        participant Tuesday
        Note over Monday: 10 AM - Ticket created
        Note over Monday: 11 AM - SLA paused (1h counted)
        Note over Monday: 2 PM - SLA resumed
        Note over Monday: 4 PM - SLA paused (2h more counted)
        Note over Tuesday: 10 AM - SLA resumed
        Note over Tuesday: 12 PM - SLA breaches (2h final)
    ```

    Example details:

    * 5-hour SLA with multiple pauses
    * Monday: 3 hours counted (10-11 AM, 2-4 PM)
    * Tuesday: 2 hours counted (10 AM-12 PM)
    * Paused time not counted
  </Tab>
</Tabs>

***

### Complex SLA scenarios

<Tabs>
  <Tab title="Priority change">
    ```mermaid theme={null}
    sequenceDiagram
        participant High
        participant Urgent
        Note over High: 8 AM - Ticket created
        Note over High: 9 AM - 1 hour elapsed
        Note over Urgent: 9 AM - Priority upgraded
        Note over Urgent: 10 AM - SLA breaches
    ```

    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)
  </Tab>

  <Tab title="Multiple metrics">
    ```mermaid theme={null}
    sequenceDiagram
        participant Customer
        participant Ticket
        participant Agent
        Customer->>Ticket: Creates ticket (9 AM)
        Note over Ticket: First response: 2hr SLA starts
        Note over Ticket: Resolution: 8hr SLA starts
        Agent->>Ticket: First response (10 AM)
        Note over Ticket: First response met (1hr)
        Agent->>Ticket: Resolution (4 PM)
        Note over Ticket: Resolution met (7hrs)
    ```

    Tracking multiple SLA metrics simultaneously:

    * First response: 2 hours (Met in 1 hour)
    * Resolution time: 8 hours (Met in 7 hours)
    * Each metric tracked independently
  </Tab>

  <Tab title="Between slots">
    ```mermaid theme={null}
    sequenceDiagram
        participant Time
        participant Ticket
        Note over Time: Morning slot (09:00-17:00)
        Note over Time: Break (17:00-18:00)
        Note over Time: Evening slot (18:00-23:59)
        Note over Ticket: Created at 17:30
        Note over Time: Non-working hours
        Note over Time: Evening slot begins
        Note over Ticket: SLA starts at 18:00
        Note over Ticket: SLA breaches at 19:00
    ```

    A ticket created between working hour slots:

    * Working hours configured in two slots:
      • Morning slot: 09:00-17:00
      • Evening slot: 18:00-23:59
    * Ticket created at 17:30 (during break)
    * 60-minute SLA duration
    * Since ticket was created during non-working hours:
      • SLA clock starts at next slot (18:00)
      • SLA breaches at 19:00 if not resolved
  </Tab>

  <Tab title="Weekend creation">
    ```mermaid theme={null}
    sequenceDiagram
        participant Sunday
        participant Monday
        Note over Sunday: 17:00 - Ticket created
        Note over Sunday: Weekend - no hours counted
        Note over Monday: 09:00 - Business hours start
        Note over Monday: 10:00 - SLA breaches
    ```

    Example of ticket created on weekend:

    * Working hours: Monday-Friday
    * Ticket created: 17:00 Sunday
    * SLA duration: 60 minutes
    * SLA breach time: 10:00 Monday
  </Tab>

  <Tab title="Holiday handling">
    ```mermaid theme={null}
    sequenceDiagram
        participant Holiday
        participant NextDay
        Note over Holiday: 10:00 (Christmas) - Ticket created
        Note over Holiday: Holiday - no hours counted
        Note over NextDay: 09:00 - Business hours start
        Note over NextDay: 10:00 - SLA breaches
    ```

    Example of ticket created on holiday:

    * Holidays: Dec 25, Dec 31, Jan 1
    * Ticket created: 10:00 on Christmas
    * SLA duration: 60 minutes
    * SLA breach time: 10:00 next business day
  </Tab>

  <Tab title="Extended duration">
    ```mermaid theme={null}
    sequenceDiagram
        participant Thursday
        participant Friday
        participant Weekend
        participant Monday
        Note over Thursday: 17:30 - Ticket created
        Note over Friday: Business hours counted
        Note over Weekend: No hours counted
        Note over Monday: 13:00 - SLA breaches
    ```

    Example of longer SLA spanning multiple days:

    * Ticket created: 17:30 Thursday
    * SLA duration: 24 hours
    * Spans across weekend
    * SLA breach time: 13:00 Monday
  </Tab>
</Tabs>

***

## SLA policies

### Policy components

<Steps>
  <Step title="Basic information">
    * Policy name and description
    * Entity type (e.g., ticket)
    * Priority level
    * Active status
  </Step>

  <Step title="Target metrics">
    * First response time targets
    * Next response time targets
    * Resolution time targets
    * Update time requirements
  </Step>

  <Step title="Conditions">
    * Ticket-based filters (priority, type, channel)
    * Customer attributes (tier, region, SLA tier)
    * Time-based conditions
    * Business hours and holidays
  </Step>

  <Step title="Pause rules">
    * Automatic pause conditions
    * Manual pause capability
    * Resume conditions
    * Multiple pause/resume support
  </Step>
</Steps>

### Policy ordering

<Note>
  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.
</Note>

<Tabs>
  <Tab title="Customer tier policies">
    ```mermaid theme={null}
    graph TD
        A[Platinum SLA Policy] --> B[Gold SLA Policy]
        B --> C[Silver SLA Policy]
        C --> D[Default SLA Policy]
        
        style A fill:#C0C0C0,stroke:#333
        style B fill:#FFD700,stroke:#333
        style C fill:#CD7F32,stroke:#333
        style D fill:#FFFFFF,stroke:#333
    ```

    Example tier-based policies:

    * **Platinum tier**: <br />
      • First response: 30 minutes <br />
      • Resolution: 4 hours <br />
      • Update frequency: Every 30 minutes <br />

    * **Gold tier**: <br />
      • First response: 1 hour <br />
      • Resolution: 8 hours <br />
      • Update frequency: Every 2 hours <br />

    * **Silver tier**: <br />
      • First response: 4 hours <br />
      • Resolution: 24 hours <br />
      • Update frequency: Daily <br />

    * **Default**: <br />
      • First response: 8 hours <br />
      • Resolution: 48 hours <br />
      • Update frequency: Every 48 hours <br />
  </Tab>

  <Tab title="Policy evaluation">
    ```mermaid theme={null}
    sequenceDiagram
        participant Ticket
        participant PolicyEngine
        participant Policies
        Ticket->>PolicyEngine: New ticket created
        PolicyEngine->>Policies: Fetch applicable policies
        Note over PolicyEngine: Multiple policies match
        PolicyEngine->>Policies: Get policy order
        Note over PolicyEngine: Select highest priority policy
        PolicyEngine->>Ticket: Apply selected policy
    ```

    Policy selection process:

    1. System identifies all matching policies
    2. Evaluates policies in order of priority
    3. Applies the first matching policy
    4. Ignores lower priority policies
  </Tab>
</Tabs>

### Dynamic SLA updates

<Note>
  SLA policies can be updated based on ticket changes. The system recalculates breach times considering the time elapsed under previous policies.
</Note>

<Tabs>
  <Tab title="Priority upgrade">
    ```mermaid theme={null}
    sequenceDiagram
        participant Ticket
        participant Time
        Note over Ticket: Created at 8 AM (High priority)
        Note over Time: 4hr SLA starts
        Note over Ticket: Updated at 9 AM (Urgent)
        Note over Time: 1hr elapsed
        Note over Time: Recalculate: 2hr SLA - 1hr = 1hr
        Note over Time: New breach at 10 AM
    ```

    **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
  </Tab>

  <Tab title="Late upgrade">
    ```mermaid theme={null}
    sequenceDiagram
        participant Ticket
        participant Time
        Note over Ticket: Created at 8 AM (High priority)
        Note over Time: 4hr SLA starts
        Note over Ticket: Updated at 11 AM (Urgent)
        Note over Time: 3hr elapsed
        Note over Time: 2hr SLA already breached
        Note over Time: Immediate breach
    ```

    **Scenario 2**: Late upgrade

    * Created: 8 AM (High - 4hr SLA)
    * Updated: 11 AM (Urgent - 2hr SLA)
    * Time elapsed: 3 hours
    * Result: Immediate breach
  </Tab>

  <Tab title="Post-breach upgrade">
    ```mermaid theme={null}
    sequenceDiagram
        participant Ticket
        participant Time
        Note over Ticket: Created at 8 AM (High priority)
        Note over Time: SLA breached at 12 PM
        Note over Ticket: Updated at 1 PM (Urgent)
        Note over Time: No new breach time
        Note over Time: Maintains breached status
    ```

    **Scenario 3**: Post-breach upgrade

    * Created: 8 AM (High - 4hr SLA)
    * Breached: 12 PM
    * Updated: 1 PM (Urgent)
    * Result: Maintains breach status
  </Tab>

  <Tab title="Priority downgrade">
    ```mermaid theme={null}
    sequenceDiagram
        participant Ticket
        participant Time
        Note over Ticket: Created at 8 AM (Urgent)
        Note over Time: SLA breached at 10 AM
        Note over Ticket: Updated at 11 AM (High)
        Note over Time: No new breach calculation
        Note over Time: Maintains breached status
    ```

    **Scenario 4**: Post-breach downgrade

    * Created: 8 AM (Urgent - 2hr SLA)
    * Breached: 10 AM
    * Updated: 11 AM (High)
    * Result: Maintains breach status
  </Tab>
</Tabs>

<Note>
  **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.
</Note>

### Business hours

<CardGroup cols={2}>
  <Card title="Configuration" icon="clock">
    • Define working hours per day <br />
    • Set up multiple time zones <br />
    • Configure holiday calendar <br />
    • Specify weekend rules
  </Card>

  <Card title="Impact on SLA" icon="calendar-days">
    • Only count business hours <br />
    • Handle timezone differences <br />
    • Skip holidays automatically <br />
  </Card>
</CardGroup>

## SLA tracking

### Real-time monitoring

<CardGroup cols={2}>
  <Card title="Status indicators" icon="circle-info">
    • Time remaining display <br />
    • Breach warnings <br />
    • Pause status
  </Card>

  <Card title="Notifications" icon="bell">
    • Breach alerts <br />
    • Team notifications <br />
  </Card>
</CardGroup>

## API endpoints

### Sample SLA policy

<CodeGroup>
  ```json request.json theme={null}
  {
    "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": []
    }
  }
  ```

  ```json response.json theme={null}
  {
    "organizationId": "org-123456",
    "version": 1,
    "priority": 1,
    "isActive": true,
    "uid": "sla-policy-123456",
    "createdAt": "2024-03-21T08:00:00Z",
    "updatedAt": "2024-03-21T08:00:00Z",
    "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": []
    }
  }
  ```
</CodeGroup>

For detailed API specifications and examples, see [Create SLA Policy](/api-reference/platform/sla-policies/create-a-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

<AccordionGroup>
  <Accordion title="Policy management" icon="gear">
    ```http theme={null}
    # Create new SLA policy
    POST /v1/sla/policy
    Content-Type: application/json

    # List all policies
    GET /v1/sla/policy?teamId={teamId}&entityType={entityType}

    # Get specific policy
    GET /v1/sla/policy/{id}

    # Update policy
    PATCH /v1/sla/policy/{id}
    Content-Type: application/json

    # Archive policy
    DELETE /v1/sla/policy/{id}
    ```

    For detailed API specifications, see [SLA Policy Management](/api-reference/platform/sla-policies)
  </Accordion>

  <Accordion title="Policy priorities" icon="arrow-up-wide-short">
    ```http theme={null}
    # Update policy priorities
    PATCH /v1/sla/priorities
    Content-Type: application/json

    Example request body:
    {
      "teamId": "team-123456",
      "entityType": "ticket",
      "priorityUpdates": [
        {
          "id": "policy-123",
          "priority": 1
        },
        {
          "id": "policy-456",
          "priority": 2
        }
      ]
    }
    ```

    For detailed API specifications, see [SLA Policy Priorities](/api-reference/platform/sla-policies/update-priorities-of-multiple-sla-policies)
  </Accordion>
</AccordionGroup>

## Best practices

<Steps>
  <Step title="Policy design">
    * Start with broad policies
    * Define clear hierarchies
    * Use specific conditions
    * Regular policy reviews
  </Step>

  <Step title="Monitoring and tracking">
    * Set up early warnings
    * Track team performance
    * Monitor breach patterns
    * Regular reporting review
  </Step>

  <Step title="Team management">
    * Clear escalation paths
    * Define team responsibilities
    * Set notification rules
    * Regular team training
  </Step>
</Steps>

## Related resources

<CardGroup cols={2}>
  <Card title="Ticket lifecycle" icon="ticket" href="/platform/core-concepts/tickets/lifecycle">
    Understanding ticket states and transitions
  </Card>

  <Card title="Ticket priority" icon="arrow-up-wide-short" href="/platform/core-concepts/tickets/priority">
    Managing ticket priorities
  </Card>
</CardGroup>