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

# SLAs and business hours

> Set your first SLA in Ravenna: pick targets you can actually hit, attach a business schedule, pause the clock while you wait, and order multiple SLAs correctly.

An SLA is a promise with a clock on it. The value is not the reporting, it is that everyone stops guessing: the requester knows when to expect a reply, and your team knows which ticket is the urgent one.

Start with one SLA. Teams that launch with six spend the first month arguing about precedence instead of hitting targets.

<Info icon="list-check">
  **Prerequisites:** a channel receiving real tickets, and enough history to know your actual response times. Setting targets before you have data is how you get a permanent red dashboard.
</Info>

## First, decide what you are promising

Ravenna measures three things, and they are not the same promise:

| Target                 | Means                     | Stops when                                      |
| ---------------------- | ------------------------- | ----------------------------------------------- |
| Time to first response | Someone acknowledged this | A team member replies, not the requester        |
| Time to resolution     | The problem is handled    | Status moves to a **Done** or **Closed** status |
| Time to close          | The ticket is finished    | Status reaches **Closed**                       |

**Start with first response only.** It is the one requesters actually feel, it is entirely within your control, and it is the easiest to hit. Add resolution once first response is consistently green.

<Warning>
  Moving a ticket to Done finalizes resolution but does not stop the close timer. If you add a close target, make sure your team actually closes tickets, or you will breach a target nobody is working on.
</Warning>

## 1. Create the SLA

<Steps>
  <Step title="Open SLA settings">
    Go to **Settings** > **SLAs** and click **+ SLA**. Give it a name, description, and icon, then **Save**.
  </Step>

  <Step title="Add one target">
    Open the SLA and add a **Time to First Response** target. Pick a number you already hit most of the time, not the one you aspire to.
  </Step>

  <Step title="Add an alert">
    Alerts are measured backward from the deadline. On a 4 hour target, a 1 hour alert fires at the 3 hour mark, leaving an hour to act.

    An alert time greater than or equal to the target time schedules no alert at all, because there is no early window left.
  </Step>

  <Step title="Save and let it run">
    Matching tickets get a badge immediately. Watch it for a week before touching the numbers.
  </Step>
</Steps>

<Callout icon="link" color="#6B7280">Learn more about [creating SLAs](/documentation/measure/slas#creating-slas)</Callout>

## 2. Attach a business schedule

Without a schedule, SLAs use wall-clock time. A 4 hour response target on a Friday 6pm ticket breaches overnight while nobody was ever going to be working.

Create a schedule under **Settings** > **Business Schedules** with a timezone and weekly working hours, then select it in the SLA's **Settings** tab. Timers only advance inside those windows, and a ticket's badge shows **Resumes at** rather than counting down outside them.

One schedule can be shared across SLAs. Most teams need one, maybe two if they have a follow-the-sun rotation.

<Tip>
  If you deliberately want 24/7 measurement, for example a Sev 1 SLA, leave the schedule blank on that SLA only. Business hours and always-on can coexist as separate SLAs.
</Tip>

<Callout icon="link" color="#6B7280">Learn more about [business schedules](/documentation/measure/slas#business-schedules)</Callout>

## 3. Stop the clock when you are blocked

If half your tickets are waiting on the requester, your SLA is measuring their response time, not yours.

Create a status like **Waiting on requester** and select it as a pause status on the SLA. Time in that status is excluded from every calculation, and the timer resumes where it left off.

Two things to know:

* Statuses in the **Done** and **Closed** groups cannot be pause statuses. Reaching a terminal status already stops the clock permanently.
* **Snooze does not pause SLA timers.** This surprises people. Use a pause status.

<Callout icon="link" color="#6B7280">Learn more about [pause statuses](/documentation/measure/slas#pause-statuses)</Callout>

## 4. Add a second SLA, carefully

Only one SLA applies per ticket. Ravenna evaluates the list top to bottom and applies the first match, so ordering is the whole configuration.

Order from most specific to most general:

1. Urgent or critical, filtered by priority
2. Team or channel specific
3. A catch-all with **Apply to all tickets** on, at the bottom

Two more things that catch people out:

* **The SLA is locked at ticket creation.** Changing priority, channel, or form afterwards does not re-evaluate which SLA applies. If escalation needs a tighter clock, that is a workflow that changes assignment and notifies, not an SLA that retroactively tightens.
* **Filters use AND logic.** To scope an SLA to a team rather than a person, use the **Assignee** filter with **is member of** and pick a user group.

<Callout icon="link" color="#6B7280">Learn more about [priority evaluation](/documentation/measure/slas#priority-evaluation)</Callout>

## 5. Make breaches visible before they happen

Notifications go to the assignee, followers, channel auto-assignees when nothing is assigned, and workspace admins. That is a good default and a bad monitoring strategy on its own, because notifications get muted.

Build one view instead. Filter on **Breaching Within** with a threshold of a few hours, and pin it. It shows only tickets with a pending target that will breach inside the window, so it is a work list rather than a postmortem. Already-breached tickets are excluded, which is the point.

Add a second view on **SLA Outcome** is **Breached** for the weekly review.

<Callout icon="link" color="#6B7280">Learn more about [filtering and exporting by SLA](/documentation/measure/slas#filter-and-export-by-sla)</Callout>

## 6. Escalate with a workflow, not the SLA

SLAs are passive. They measure, badge, and notify. They do not reassign, re-prioritize, or trigger anything.

If you want an at-risk ticket escalated automatically, build a workflow that reacts to ticket changes and checks SLA outcome in a condition, then reassigns or posts to a channel. The **Due Date** action is useful for keeping a ticket's own deadline aligned with the SLA target.

<Callout icon="link" color="#6B7280">Learn more about [set up your first workflow](/guides/day-one/set-up-first-workflow)</Callout>

## 7. Report on it

Custom analytics cards on the Tickets data source expose two families of duration fields, and picking the wrong one produces numbers you cannot explain:

* **SLA Time to First Response**, **SLA Time to Resolution**, **SLA Time to Close** read the SLA target record. They honor business schedules and pause statuses, and only cover tickets an SLA applies to. Use these for compliance reporting.
* **Time to First Response**, **Time to Resolution**, **Time to Close** measure wall-clock from the ticket's own timestamps, across every ticket. Use these to benchmark the team, including channels with no SLA.

<Callout icon="link" color="#6B7280">Learn more about [choosing a duration field](/documentation/measure/slas#choosing-a-duration-field-on-custom-cards) and [reporting and briefs](/guides/playbooks/reporting-and-briefs)</Callout>

## Where teams get this wrong

<AccordionGroup>
  <Accordion title="Aspirational targets">
    An SLA nobody hits is ignored within two weeks. Set the target you already meet, then tighten it.
  </Accordion>

  <Accordion title="No business schedule">
    Overnight and weekend breaches on a business-hours team make the whole dashboard meaningless.
  </Accordion>

  <Accordion title="No pause status">
    You end up reporting on how fast your requesters answer email.
  </Accordion>

  <Accordion title="Six SLAs on day one">
    One, for the highest-volume channel, then expand.
  </Accordion>

  <Accordion title="Expecting the SLA to act">
    Escalation is a workflow. The SLA only tells you it is time.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Reporting and briefs" icon="chart-line" href="/guides/playbooks/reporting-and-briefs" horizontal>
    Dashboards, CSAT, and a weekly brief in Slack.
  </Card>

  <Card title="IT help desk" icon="headset" href="/guides/playbooks/it/help-desk" horizontal>
    Where a single SLA fits into a full desk.
  </Card>
</CardGroup>


## Related topics

- [Incident intake](/guides/playbooks/security/incident-intake.md)
- [Device lifecycle](/guides/playbooks/it/device-lifecycle.md)
- [Approval flows](/guides/playbooks/approval-flows.md)
- [Email support](/guides/playbooks/email-support.md)
- [Playbooks](/guides/playbooks/overview.md)