Module configuration
SLA
Time commitments on tickets and tasks — measure, monitor and escalate when lead times threaten to break.
Updated Jan 23, 2026
Configuration · Modules · 4.4
An SLA (Service Level Agreement) is a time commitment on a ticket or task. The SLA module captures what you promise, which cases it applies to, and tracks whether you make the commitment — with a timer that only runs during business hours.
Why this matters to the business
"Promises unmeasurable"
Time-to-first-response and time-to-resolution made explicit — reportable per month.
"Waiting on the customer counts"
Conditions pause the timer at specific statuses — fair measurement.
"Clock keeps ticking outside office hours"
Calendar attaches to the SLA → timer only runs during business hours.
"Escalated too late"
Notification sequence on SLA percentage → reminder, manager, steering group automatically.
Four aspects of every SLA
| Aspect | What it sets |
|---|---|
| Class | Time to first response or time to resolution. Two different measurement strategies. |
| Criteria | When the SLA applies: organisation, classification, priority, kind (ticket/task), template, type. |
| Target time | Maximum allowed lead time in hours/minutes + the calendar that defines business hours. |
| Conditions | When the timer starts, pauses or stops (e.g. status "Waiting on customer" pauses). |
The combination class + criteria is unique — creating the exact same setup twice triggers an error.
Two SLA classes
Time to first response
How fast does someone respond to the ticket? Stops as soon as the first follow-up is given.
Time to resolution
How fast is it resolved? Stops on completion status.
Change behaviour
When something changes on a ticket (organisation, priority, classification), Gfacility re-checks whether an SLA matches. A new SLA becomes active, or an existing one is hidden if no criterion still fits.
When the SLA configuration itself changes, already-active SLAs stay intact — the old one keeps ticking until the ticket closes. Only when something on the ticket changes will Gfacility re-evaluate.
Which decisions will you make?
Which priority bands?
Critical · high · normal · low — each with its own target. Too many bands = needless complexity.
Business hours vs 24/7?
Which calendar do you attach? One calendar per service team is usually enough.
Which statuses pause?
"Waiting on customer", "On hold" — otherwise external waits keep ticking and you break unfairly.
SLA on ticket or task?
Both is possible, but pick per use case — otherwise you report twice.