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

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.
• You need sla:manage, which covers reading SLAs as well as changing them. See 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. 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
• Queues and canned responses
• Workflows