SLA Configuration

An SLA in Crystal Desk is configured per stage, not per ticket as a whole — a single ticket can have different deadline pressure at each stage it passes through.

Setting an SLA

In a stage's configuration panel, the SLA is set as a number of hours — the amount of time the assignee has to complete the stage once it's genuinely their turn to work on it. A Script stage might carry a 24-hour SLA, while a QC stage on the same template might only need 2 hours.

When the clock starts

The SLA clock starts the moment the assignee is notified of the assignment — not when the stage instance first activated, and not when the ticket itself was created. If a stage sits for six hours before an eligible assignee is found (see How Assignment Works), that delay doesn't count against the assignee's window; the clock is a measure of their response time, not the ticket's total age.

Pre-breach warning threshold

Each stage can define a pre-breach warning threshold — a percentage of the SLA window (commonly 80%) at which a supervisor is notified that a stage is at risk, while there's still time to intervene. This is the mechanism that actually changes day-to-day behavior, rather than a policy nobody checks until it's already too late.

What happens on breach

If the SLA window fully elapses without submission, the breach is recorded as a sla_breached event on the ticket's timeline (see Ticket Lifecycle), and the configured supervisor is notified. Breaches feed into SLA performance reporting rolled up by workflow, stage, and team member, making a recurring bottleneck visible as a pattern rather than a string of individually-forgotten incidents.

For how supervisors and assignees actually receive these notifications, see Notifications.