---
title: "Service level agreements"
description: "Set the business hours your desk works and the response and resolution times each ticket is promised, so the queue shows what runs out first."
url: "https://support.outpostplatform.com/service-desk/sla/"
product: "depot"
type: "how-to"
status: "draft"
ai_summary: "Settings > SLA (Enterprise and MSP). Business schedules set hours, time zone, and holidays. Timers start on their own: the first matching policy by run order, else the queue's default, else the catch-all policy; first response and resolution only. They pause on clock-stopping statuses, move on priority changes, and close on the first public reply and on solve. Warnings go to the assignee's bell."
availability:
  plans: ["enterprise", "msp"]
  permission: "sla:manage"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/service-desk/sla.md"
license: "CC BY 4.0"
---

# Service level agreements

A service level agreement (SLA) is a promise about how fast your desk responds
to and resolves tickets. In Outpost you set it up in two parts: business
schedules say when the desk is working, and SLA policies say what each ticket
is promised. Deadlines are counted in working time, so a ticket raised on a
Friday afternoon is due when somebody is next at work. This page shows how to
set up both.

## How SLAs work

- A **business schedule** is a calendar: working hours for each day of the
  week, a time zone, and holidays. One schedule is the default. Outpost
  starts with a built-in schedule, **24/7**, which is open every hour of every
  day in UTC and is the default until you choose another.
- An **SLA policy** decides which tickets it covers and which schedule it uses,
  and holds one or more promises.
- A **promise** is a target for one measure, optionally for one priority,
  counted in business minutes. The measures are **First response**, **Next
  response**, **Periodic update**, and **Resolution**.

### How a ticket gets its deadlines

SLA timers start on their own when a ticket is created, however it was
created: in the console, from the tray app, from a chat, by a
workflow, or by Outpost itself. Outpost picks one policy for the ticket:

1. The first enabled policy, in **Run order**, whose condition matches the
   ticket. The policy marked as the one for tickets no other policy claims is
   skipped in this pass.
2. Otherwise, the default SLA policy of the ticket's queue. See
   [Queues and canned responses](/service-desk/queues-and-automation/).
3. Otherwise, the policy marked **Use this policy for a ticket no other policy
   claims**.

Only one policy applies, unlike workflows, where every match runs. From that
policy, the ticket gets a **First response** timer and a **Resolution** timer,
each using the promise for the ticket's priority, or the **Any priority**
promise when there is none for that priority. A measure with no promise gets
no timer. Deadlines are measured from when the ticket was created.

A ticket that a technician types into the console gets no **First response**
timer, because someone has already seen it. Its **Resolution** timer still runs.
Every other ticket gets both timers, because nobody can be assumed to have seen
it yet. That covers tickets from the tray app, email, the client portal, a chat,
the API, MCP or Pioneer AI, a workflow, and tickets Outpost opens itself, such
as compliance gap and incident tickets.

While the ticket is open, its timers follow it:

| What happens | Effect on the timers |
| --- | --- |
| The status changes to one that stops the clock | The timers pause. They resume when the status changes back. |
| The priority changes | Running timers move to the promise for the new priority. |
| A technician sends the first public reply | **First response** closes as met, or as breached if it was late. |
| The ticket is solved or closed | **Resolution** closes as met or breached. A **First response** timer still running is canceled. |

A ticket reopened after it was solved keeps its closed **Resolution** timer
and does not get a second one. Editing a policy does not move tickets that
already have timers onto another policy. **Next response** and **Periodic
update** promises can be saved, but no timers start for them.

The clock stops while a ticket is **Pending**, **On hold**, **Solved**, or
**Closed**.

A promise of four hours against a nine-to-five week, on a ticket raised at
16:00, is due at 12:00 the next working day.

Until at least one policy exists, tickets have no deadlines.

### Warnings and breaches

When a ticket reaches a promise's warning point, and when it misses a target,
the assignee gets an **SLA warning** or **SLA breached** notification in the
console bell. When nobody is assigned, everyone with the Support Manager role
gets it. Each person can also have these sent by email. See
[Notifications](/depot/notifications/).

Open tickets that existed before SLA timers started on their own get timers
measured from when they were created. A warning or breach that would already
have happened is recorded without a notification.

## Before you begin

- Your plan must include the service desk: Enterprise or MSP. See
  [Plans and limits](/account/plans-and-limits/).
- You need `sla:manage`, which covers reading SLAs as well as changing them.
  See [Roles and permissions](/depot/roles-and-permissions/).

## Create a business schedule

1. Select **Settings** > **SLA**.
2. Under **Business schedules**, select **New schedule**.
3. Enter a **Name**, such as "Office hours", and a **Description**.
4. In **Time zone**, choose a zone from the searchable list, such as
   `America/Chicago`. The hours are read in this zone.
5. Under **Working hours**, select **Add hours** on each working day and enter
   a range such as `09:00-17:00`. Add more ranges for a split day. A day with
   no hours shows **Closed**, and deadlines skip over it.
6. To make this the schedule for policies that do not name one, select **Use
   this calendar when a policy does not name one**.
7. Select **Save schedule**.

### Add holidays

Holidays can be added once the schedule is saved.

1. Open the schedule with **Edit**.
2. Under **Holidays**, enter the **Holiday** name, **Month**, and **Day**, and
   a **Year** for a one-time holiday. Select **Every year** for a holiday on
   the same date each year.
3. For a part day, enter the **Hours worked (optional)**, such as
   `09:00-12:00`. Leave it blank to close the whole day.
4. Select **Add holiday**.

:::caution
A schedule that is never open makes every deadline on it unreachable. Check
that each working day has hours and that the time zone is right.
:::

## Create an SLA policy

1. Select **Settings** > **SLA**.
2. Under **SLA policies**, select **New policy**.
3. Enter a **Name**, such as "Standard", and a **Description**.
4. In **Calendar**, choose a schedule, or **The client's default calendar**.
5. In **Run order**, enter a number. The lowest run order is tried first.
6. In **Condition**, enter which tickets the policy covers, as a JSON
   condition tree. Each condition is `{"field": ..., "op": ..., "value": ...}`,
   grouped with `{"all": [...]}` or `{"any": [...]}`. The fields and operators
   are listed in [Conditions](/service-desk/workflow-reference/#conditions).
   Leave it empty to cover every ticket.
7. To use this policy for any ticket no other policy claims, select **Use this
   policy for a ticket no other policy claims**.
8. Leave **Enabled** selected and select **Save policy**.

### Add promises

Promises can be added once the policy is saved.

1. Open the policy with **Edit**.
2. Under **Promises**, choose the **Promise**: **First response**, **Next
   response**, **Periodic update**, or **Resolution**.
3. In **Priority**, choose the priority it applies to, or **Any priority**.
4. In **Minutes**, enter the target in business minutes.
5. In **Warn at %**, enter how far through the target, as a percentage, the
   ticket's next SLA event becomes a warning.
6. Select **Add target**. Repeat for each promise.

## Verify

1. Create a test ticket that the policy covers.
2. In **Tickets** > **All tickets**, the ticket shows a time in **Next SLA
   event**.
3. A ticket that misses a target shows **SLA breached**, and appears in the
   **Missed SLA** view.

## Next steps

- [Tickets](/service-desk/tickets/)
- [Queues and canned responses](/service-desk/queues-and-automation/)
- [Workflows](/service-desk/workflows/)