# SLAs

SLAs in Siit set clear expectations for speed and quality. Define targets per service, control when the clocks run, and alert your team before or at breach so nothing slips.

### SLA types

Siit supports two SLA types:

* **First Response Time** — how quickly your team should send the first public reply to the requester.
* **Resolution Time (Time to Close)** — how long you have to resolve the request.

### Where SLAs are configured

SLAs are set at the **service level**: Service Catalog → \[Your Service] → Request tab → SLAs. Turn SLAs on and set targets for First Response and Time to Close.

**Controlling when the clock runs** is done via **SLA Rules**, which let you attach a Business Calendar to determine which hours count toward SLA targets. This is configured in **Settings → SLA Rules**.

> **⚠️ If you previously set SLA timing at the service level:** This configuration has moved to SLA Rules in Settings. Your existing SLA behavior is preserved — this is a location change, not a behavior change.

### Business Calendars and SLA timing

Attaching a **Business Calendar** to an SLA Rule ensures that time outside of working hours doesn't count toward your targets.

<figure><img src="/files/wkjHPYI4PVduqbAi9RUo" alt=""><figcaption></figcaption></figure>

**How it works:**

* When an SLA Rule uses a Business Calendar, the timer only runs during that calendar's configured working hours.
* Time outside those hours (evenings, weekends, public holidays) does not count toward breach.
* Different SLA Rules can use different calendars — your EU team's SLAs can run on CET hours while your US team's run on ET hours.

**Example:**

* A P1 incident ticket lands Friday at 6pm.
* The associated SLA Rule uses the "EU Support — CET" calendar (Mon–Fri, 9am–6pm).
* The SLA clock pauses at 6pm and resumes Monday at 9am CET.
* No false breach. Reporting reflects actual working time.

For teams with a single schedule, the migrated **"Office Hours"** calendar in Settings → Business Calendars already covers this — no additional setup needed.

### Pause rules

Optionally pause SLAs when the request is set to **Waiting** or **Snoozed**. This is configured per service.

| Scenario                                         | Recommended pause setting |
| ------------------------------------------------ | ------------------------- |
| IT P1 Incident                                   | Off — keep clocks running |
| HR payroll question awaiting info from requester | On — pause while waiting  |

### Notify before or on breach

Use a workflow to alert the right people as SLAs approach risk or breach:

* **Trigger:** SLA breached (or pair with status/priority conditions)
* **Actions:**
  * Send a Slack message to the assignee, inbox channel, or a leadership channel
  * Send a Communication to the assignee or participants
  * Increase priority or reassign to an escalation queue

> **💡 Tip:** Create a second workflow that posts a warning as remaining time becomes short (e.g. when status is still New/In progress with less than 30 minutes remaining). Pair with a tag like "SLA-risk" to make triage easy.

<figure><img src="/files/Kk2jDleL7SHkO8ovvSrd" alt=""><figcaption></figcaption></figure>

### Where SLAs are visible

* **Request sidebar** — see "First response" and "Time to close" with Remaining/Breached labels and color cues.
* **List and board views** — optional SLA columns and badges for quick scanning and triage.
* **Timeline** — workflow alerts and breach events are logged for audit.

<figure><img src="/files/ARZmHQFOV5PEpmUNF6ev" alt=""><figcaption></figcaption></figure>

### Examples

**IT P1 Incident**

* First response: 15 office minutes
* Time to close: 4 office hours
* Business Calendar: 24/7 On-call (always running)
* Pause on Waiting: off
* Workflow: on breach → notify #it-ops and assign to on-call

**HR Payroll Question**

* First response: 4 office hours
* Time to close: 3 office days
* Business Calendar: HR Team — CET (Mon–Fri 9am–6pm)
* Pause on Waiting: on
* Workflow: 2 hours before first response due → DM assignee; add tag "SLA-risk"

### Best practices

* Define SLAs where expectations matter most — top services and high-impact categories.
* Use [**Business Calendars**](/workspace/business-calendars.md) on SLA Rules rather than a single global schedule when you have regional or shift-based teams.
* Keep statuses simple and align pause rules with your process.
* Use inbox Views filtered by "SLA at risk" for live triage.
* Escalate early: warn before breach and provide a clear path (reassign, raise priority, notify a lead).
* Review performance monthly and tune targets by service based on real data.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.siit.io/service-catalog/slas.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.