SLAs and business hours

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.

​

First, decide what you are promising

Ravenna measures three things, and they are not the same promise: 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.

​

1. Create the SLA

​

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.

​

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.

​

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.

​

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.

​

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.

​

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.

​

Where teams get this wrong

​

Next