Service-level policies
An SLA policy in Auralis sets two targets: how quickly a ticket should get its first response, and how quickly it should be resolved. Both are expressed in minutes.
Policies are keyed on priority. That is the whole matching rule — a policy names a priority, and tickets of that priority get its targets. There is no condition language, no matching on team, customer or channel, and no ordering between policies to reason about. Each policy also has a name, and can be enabled or disabled.
This simplicity is worth taking advantage of rather than working around. Four priorities means at most four sets of targets, which is a service-level commitment a team can actually remember and a customer can actually be told.
How the deadlines are set
When a ticket is created, the policy matching its priority is used to stamp two deadlines onto the ticket: a first-response deadline and a resolution deadline. These are stored on the ticket itself, which is why they can be sorted and filtered on directly.
Changing a ticket's priority re-stamps both deadlines from the moment of the change. The new deadlines are calculated from the new priority's targets, starting from now rather than from when the ticket arrived. This is the single most important thing to understand about SLAs here.
The consequence in both directions is worth spelling out. Escalating an old ticket from normal to urgent does not immediately mark it as breached against the tighter urgent target; it gives the ticket a fresh urgent-length window starting now. And downgrading a ticket that is minutes from breaching will hand it a new, later deadline. Neither is a bug, but if you use priority changes as a triage habit you should know that you are also resetting the clock every time.
What stops the clock
The first-response deadline is met by a reply — a message that actually goes to the customer. The time of the first response is recorded on the ticket.
Internal notes do not stop the first-response clock. This is the usual explanation when a busy ticket breaches its first-response target: the team was working on it and talking to each other, but nobody had yet said anything to the customer. If that pattern shows up repeatedly in your breach reports, it is generally a sign that an acknowledgement macro is needed rather than that the target is wrong.
A ticket that breaches is marked as breached, and records which of the two kinds of target it missed, so first-response failures and resolution failures can be told apart in reporting. A breach is also written onto the ticket's timeline, so you can see when it happened while reading the ticket rather than having to go to a report.
Working against your SLAs
Two tools in the inbox are built for this.
Sorting by SLA due orders tickets by their nearest deadline, soonest first, with tickets that have no deadline at the end. Working top-down in this order is the most direct way to reduce breaches.
Filtering by overdue shows tickets that have already passed a deadline. The inbox also carries a breach count alongside its other counts, so the number is visible without running a report.
Managing policies
Editors can create and edit SLA policies. Deleting a policy is an admin action.
Disabling a policy rather than deleting it is usually the better move when you are changing your commitments, because it leaves the record of what the targets used to be. Bear in mind that changes to a policy affect the deadlines stamped onto tickets from that point onwards — tickets already carrying deadlines keep the ones they were given until something re-stamps them.