> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SLAs
> Configure Service Level Agreements to track resolution time and time-to-first-response commitments
Service Level Agreements (SLAs) define your team's commitments — how quickly tickets should be resolved, how quickly a human agent should respond, and so on. Configure SLA policies to track performance and surface tickets that are at risk of breaching.
***
## Understanding SLAs
An SLA policy measures one specific commitment against a target duration. A policy has three pieces:
* **What to measure** — the *metric* (e.g. time to resolution, time to first response).
* **When the clock starts** — the *starting point* (when the SLA is attached, or backdated to when the ticket was created).
* **What stops the clock** — implied by the metric. Resolution stops on ticket closure; first response stops on the first agent reply.
Tickets that match the policy's criteria are tracked automatically. A single ticket can have several SLAs running at once as long as each one measures a different metric — for example a resolution SLA *and* a first-response SLA can coexist on the same ticket.
***
## Creating an SLA Policy
Go to **Team Settings** → **SLAs**.
Click **Add SLA**.
| Field | Description |
| :----------------------- | :--------------------------------------------------------------------------------------------------- |
| **Name** | Descriptive name (e.g., "Critical Priority Resolution") |
| **Target duration** | Time limit for the metric — choose from presets or set a custom duration in days, hours, and minutes |
| **Calendar type** | Whether to track against calendar time (24/7) or business hours |
| **What to measure** | The metric the SLA tracks. See [Metrics](#metrics) below |
| **Start the clock** | When the clock begins counting. See [Starting Points](#starting-points) below |
| **Auto-attach criteria** | Conditions that determine which tickets this SLA applies to (e.g., priority, status, labels, groups) |
Click **Create** to activate the SLA policy. Matching tickets will begin tracking automatically.
***
## Metrics
The metric determines what the SLA is measuring — and therefore what stops the clock.
| Metric | What it tracks | Clock stops when |
| :------------------------------- | :------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Time to resolution** | The total time a ticket is open | Ticket status reaches Done or Canceled |
| **Time to first human response** | The time until the first human agent replies | A human agent (not the requester, not AI, not an internal note) posts a public message on the ticket after the clock started, **or** the ticket is resolved without one |
First-human-response SLAs only count *human* agent messages. AI assistant messages, internal notes, system-generated messages, and messages from the ticket's requester do not stop the clock — first response is specifically about a person picking up the conversation.
If a ticket is resolved before a human ever responds (for example, fully handled by AI), the SLA closes out at resolution time. It records as **Met** if resolution happened within the SLA's target duration, or **Breached** if it took longer — same met/breached logic as a normal completion.
***
## Starting Points
The starting point controls *when* the clock begins.
| Starting point | When it starts |
| :------------------------------ | :---------------------------------------------------------------------------------------------- |
| **When the SLA is attached** | The moment the SLA attaches to the ticket (default) |
| **When the ticket was created** | Backdated to the ticket's creation time. Useful when tickets sit in a queue before being routed |
To measure time-to-first-human-response *after* a specific event (e.g. after escalation to a human), express the event with auto-attach criteria rather than the starting point. For example, combine the *Time to first human response* metric with `When the SLA is attached` and add `ticket.escalation_level = human` to the auto-attach criteria — the SLA will only attach (and start counting) once the ticket has been escalated.
***
## Calendar Time vs. Business Hours
When creating an SLA, you choose how time is counted:
* **Calendar time (24/7)** — The clock runs continuously, including nights and weekends. Use this for critical issues that require around-the-clock attention.
* **Business hours** — The clock only runs during your configured working schedule. Use this for standard requests where resolution outside business hours isn't expected.
### Configuring a Business Hours Schedule
If you select business hours, you'll choose a [schedule](/sections/documentation/ticketing/ticket-configuration/schedules) that defines your team's working days and hours. Schedules include a timezone and per-day time windows (e.g., Monday–Friday, 9 AM – 5 PM).
Schedules are reusable — the same schedule can be shared across SLA policies and [assignment rules](/sections/documentation/ticketing/ticket-configuration/assignment).
***
## Auto-Attach Criteria
SLA policies can automatically apply to tickets based on conditions like:
* **Priority** — Apply to tickets of a specific priority level
* **Status** — Apply based on current status
* **Labels** — Apply to tickets with specific labels
* **Groups** — Apply to tickets assigned to specific groups
This lets you create different SLA targets for different types of tickets. For example, you might have a 4-hour SLA for critical priority tickets and a 72-hour SLA for low priority requests.
***
## SLA Pausing
You can configure pause conditions so the SLA timer stops when the ticket is in certain states. This prevents your team from being penalized for time spent waiting on external parties.
Common pause scenarios:
* **Waiting on requester** — Pause while waiting for the requester to provide more information
* **Waiting on vendor** — Pause while waiting for a third-party response
* **On hold** — Pause for tickets that are intentionally paused
Pause conditions are configured per SLA policy. The timer resumes automatically when the pause condition is no longer met.
***
## SLA Tracking
### SLA Status
Tickets tracked by an SLA policy show their SLA status:
* **On track** — The ticket is within its SLA target
* **At risk** — The ticket is approaching its SLA deadline
* **Breached** — The ticket has exceeded its SLA deadline
### When SLA Tracking Ends
SLA tracking stops when the metric's completion event fires:
* **Resolution SLAs** stop when the ticket reaches a "Done" or "Canceled" status.
* **First-human-response SLAs** stop when a human agent posts the first qualifying reply on the ticket after the clock started, or when the ticket is resolved without one.
You can also **manually detach** an SLA from a ticket by opening the SLA row in the ticket sidepanel, expanding the picker, and clicking **Remove SLA**. The detached SLA is recorded in the ticket activity timeline; other SLAs on the ticket are unaffected.
***
## SLA Reporting
Track SLA performance in analytics:
The analytics dashboard includes an SLA performance chart that shows the percentage of tickets meeting SLA targets vs. breaching. You can filter the chart by priority, assignee, or other attributes to drill into specific areas.
Use the SLA filter in the ticket list to quickly find tickets that are at risk or breached and need immediate attention.
***
## Common Questions
Yes. You can create different policies for different ticket types using auto-attach criteria. For example, one policy for critical tickets with a 4-hour target and another for low priority with a 72-hour target.
A ticket can have one active SLA *per metric* — one resolution SLA and one first-response SLA can coexist, for example. If two policies on the same metric both match a ticket, the first matching policy attaches and the rest are skipped. The ticket's headline SLA status reflects the most urgent of the active SLAs (a breached SLA outranks an in-progress one; in-progress outranks paused; if two are tied, the one breaching soonest wins).
Yes — that's the point of separating *what to measure* from *when the clock starts*. Configure two policies (e.g. "Resolve within 4h from creation" and "First response within 15m from attachment"), and both will track independently. The ticket sidepanel shows one row per metric.
Yes. Updating an SLA policy affects how future tickets are tracked. Existing tickets that already have the SLA attached continue with their original target.
Filter your ticket list by SLA status to find at-risk or breached tickets. You can also use the SLA performance chart in analytics to see compliance trends.
Open the ticket, expand the SLA row in the sidepanel, and select **Remove SLA**. The SLA moves to a "cancelled" state — it stays in the ticket's activity history but no longer counts toward breach scanning. Other SLAs on the ticket are untouched.