Service-level agreements

An SLA in Iskue is a named metric — "Time to first response", "Time to resolution" — with conditions that start, pause and stop its clock, and goals that set the target for different kinds of ticket. A project can define several. Iskue keeps timer cycles per ticket and metric, so a reopened ticket resumes its clock instead of starting over.

Conditions

• Start — for example when the ticket is created.
• Pause — for example while the ticket waits for the customer. Paused time is not counted.
• Stop — for example when an agent first responds, or the ticket is resolved.

Leaving a done status resumes the completed resolution cycle without counting the time the ticket spent closed.

Goals

Goals are an ordered list of TQL → target → calendar rows (up to 90). The first goal whose TQL matches the ticket applies; a blank TQL at the end is the catch-all. One metric can say "4 hours for priority = HIGHEST, 8 business hours for access requests, 3 days otherwise". A goal with no target means "not tracked".

Time to resolution
  priority = HIGHEST                  → 4h   (24/7)
  requestType = "Access request"      → 8h   (Business hours)
  (everything else)                   → 3d   (Business hours)

Calendars

A project can hold several named calendars, one of them the default. Each has a timezone, per-day working windows (Monday first) and holidays. With a calendar, SLA minutes only elapse inside working time, so a request raised on Friday evening does not burn its target over the weekend.

Where timers show

• On the ticket, with the remaining time.
• As queue columns, sortable (ORDER BY sla).
• On the portal, for metrics you mark as visible to customers, in the customer's language.
• In the SLA report and the SLA dashboard gadget: met versus breached per metric.

SLA in TQL

breached("Time to resolution")
running("Time to first response") AND priority = HIGHEST
project = SUP ORDER BY remaining("Time to resolution") ASC

Breaches and automation

A sweep runs every 5 minutes. Each breached target is notified exactly once, through the project's notification scheme (the assignee by default), and the message names the metric. The sweep is safe on a multi-node cluster: the notified flag is claimed atomically, so two backends never send the same alert. For earlier warnings, an automation rule on the SLA_THRESHOLD trigger fires when a timer crosses the threshold you choose.