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