What are SLAs?
SLAs (Service Level Agreements) define how quickly your team should respond to and resolve requests. Siit tracks two types:
- First Response Time — how quickly someone on your team sends the first public reply.
- Resolution Time (Time to Close) — how long it takes to fully close the request.
SLA targets are set per service. Timing logic — which hours count, which priorities get which targets — is managed through SLA Rules.
SLAs are available on the Pro plan.
How SLA Rules work
SLA Rules are the engine behind SLA timing. Each rule combines:
- Business Calendar — which working schedule governs when the SLA clock runs
- Targets by priority — First Response and Time to Close durations, defined per priority level within the rule
- Pause behavior — optionally pause the clock when a request is Waiting, Snoozed, or Pending approval
Within a single rule, you can define different targets for each priority. A rule using your Mon–Fri calendar can set a 15-minute first response for Urgent requests and a 4-hour target for Normal ones — all in one place.
If a priority needs a completely different calendar (e.g. Urgent runs 24/7 while others follow business hours), create separate rules and leave specific priorities unconfigured in each. Only the rule with a target defined for a given priority will apply to it.
Go to Settings → SLA Rules to create and manage your rules.
Setting up SLAs
Step 1 — Create your Business Calendars
Before configuring SLA Rules, make sure you have at least one Business Calendar set up in Settings → Business Calendars. Your calendars define the working hours that SLA clocks respect.
If you're an existing customer, a calendar called "Office Hours" was created automatically from your previous schedule. You can use it as-is or create additional ones.
Step 2 — Create SLA Rules
Go to Settings → SLA Rules and click New Rule. For each rule:
-
Select the Business Calendar that governs active hours
-
Set First Response and Time to Close targets per priority — you can define targets for all priorities or only the ones you want covered (e.g. only High and Urgent)
-
Optionally configure pause behavior — pause the clock when a request is Waiting, Snoozed, or Pending approval
You can assign a service directly to an SLA Rule from this tab. You can also attach an SLA Rule to a service from the service's own Request tab if you prefer to manage it from there.
If you're an existing customer, SLA Rules were created automatically from your previous service configurations. Review them in Settings → SLA Rules and adjust as needed.
First, link your SLA rules to your Business Calendar as well as your required services:
Then, set the thresholds you need for first response time and time to close as well as your time adjustments rules:
What's new: you can now define specific SLAs per request priority:
Lastly, you can decide the level of alert you want to receive:
SLA status colors
When a request is open, a colored SLA badge shows its current status:
| Color | Status | Meaning |
| 🟡 Yellow | In progress | Time remaining before the SLA deadline |
| 🔴 Red | Breached | SLA missed — badge shows how long overdue |
| 🟢 Green | Met | Request handled before the deadline |
| ⚫ Grey | Missed but closed | SLA not met — shows how late the response or resolution occurred |
SLA status is visible in the request sidebar, in list and board views as optional columns, and on the timeline for audit purposes.
Real-life example — how SLA timing works
Setup: An accessories request service has a First Response SLA of 2 hours. The SLA Rule uses a Business Calendar set to Mon–Fri, 10am–6pm.
Scenario: A request arrives at 4:16pm on a Tuesday.
- Office hours close at 6pm — only 1h44 remaining in the day.
- The SLA clock runs for 1h44, then pauses at 6pm.
- It resumes at 10am on Wednesday with 16 minutes remaining.
- The SLA deadline is 10:16am Wednesday.
- The badge shows time remaining based on working hours only — not wall clock time.
This is why a request submitted late in the day can show more than 2 hours remaining on the badge: the display reflects total time until the deadline, not just the SLA duration.
Setting up breach notifications
Use a workflow to alert the right people before or when an SLA breaches:
1. Go to Settings → Workflows and create a new workflow
2. Set the trigger to SLA breached (or add a time-remaining condition for early warnings)
3. Add actions: Slack message to the assignee or inbox channel, priority increase, or reassignment to an escalation queue
Tip: Create two workflows — one that warns when remaining time drops below a threshold (e.g. 30 minutes), and one that fires on breach. Tag at-risk requests with "SLA-risk" to make triage easier.
FAQ
Can I set different SLA targets for different priorities?
Yes, and you don't need a separate rule for each priority. Within a single SLA Rule, you can define different First Response and Time to Close targets per priority level. Set tighter targets for Urgent, looser ones for Normal — all in one rule, all using the same calendar.
If a specific priority needs a different calendar entirely (e.g. Urgent requests should run 24/7 while others follow business hours), create a separate rule for that and leave those priorities unconfigured in your main rule. A priority with no target defined in a rule is simply not covered by it.
Can different teams use different SLA timings?
Yes. Create a Business Calendar per team or region and attach each to the relevant SLA Rule. Your EU team's SLAs run on CET hours, your US team's on ET hours — independently.
Does pausing a request stop the SLA clock?
Only if you configure pause behavior on the SLA Rule. You can pause the clock when a request is set to Waiting, Snoozed, or Pending approval — each is a separate toggle you can enable or leave off. For incidents, you'll typically want to leave the clock running. For requests awaiting information from the requester or stuck on an approval, pausing makes sense.
What happens to the SLA if I change a request's priority or service?
The SLA updates immediately when priority or service changes — Siit recalculates the targets based on the new priority and the applicable SLA Rule. The SLA start date always stays anchored to the original request creation date, not the moment the priority or service was changed.
I was using Office Hours for SLA timing before. Do I need to reconfigure anything?
No. Your previous Office Hours schedule was migrated into a Business Calendar called "Office Hours", and SLA Rules were created automatically from your existing service configurations. Your SLA behavior is unchanged. You'll find everything in **Settings → SLA Rules** and **Settings → Business Calendars**.
Can I delete an SLA Rule?
Yes. Deleting a rule affects new requests only — requests already running against that rule keep their existing SLA calculation until they close.