Queues and SLA policies

Queues group tickets and decide how they are assigned. SLA policies set how quickly a ticket must get a first response and a resolution, and UnitX tracks each ticket against those targets: running, paused while you wait on the customer, at risk, breached or met. This page explains how both work, and exactly how a ticket’s SLA state is worked out.

Who can use it#

Queues#

A queue is a named group of tickets (for example “Billing & subscriptions”) with a set of members and an assignment mode. Queues can also carry a default SLA policy, which applies to tickets that arrive in that queue.

Create a queue#

1. Open Support settings

   Go to SupportSettings. The Queues tab opens first.

2. Name and describe it

   Enter a Name (required, unique) and an optional Description.

3. Pick the Assignment mode

   Choose manual, round robin or least loaded.

4. Tick the Members

   Select everyone who should receive tickets from this queue.

5. Select Create queue

   The queue appears in the list with its mode and member count.

Assignment modes#

manual

Nobody is picked automatically. Someone chooses the assignee on the ticket.

round robin

Members take turns. Each automatic assignment goes to the next member in the rotation, and two simultaneous assignments never pick the same turn.

least loaded

The member with the fewest unresolved tickets in this queue gets the next one.

SLA policies#

Create an SLA policy#

1. Open the SLA policies tab

   SupportSettingsSLA policies

2. Fill in the targets

   Enter a Name, First response (min) and Resolution (min). For example, 60 and 480 give one hour to respond and eight hours to resolve.

3. Set the warning threshold

   Warn at % (1–100, default 80) is how much of the resolution time can pass before the ticket counts as at risk.

4. Choose the Reopen behavior

   Required: restart, continue or new cycle. See Reopen behavior.

5. Select Create policy

   The policy is listed as Active, with a summary such as “First response 1h · resolution 8h · warn at 75% · reopen: restart”.

Policy names must be unique, and both targets must be at least one minute. Policies can’t be edited or deactivated from the web app.

Which policy applies to a ticket#

A ticket’s policy is chosen once, when the ticket is created. The first of these that applies wins:

1. A policy named explicitly for the ticket, for example by a ticket template.
2. For a customer contact requester: the SLA policy on an active service contract for that contact’s customer (the one with the latest start date, if there are several).
3. The default SLA policy of the ticket’s queue.
4. Otherwise, no SLA. The ticket isn’t tracked.

How due dates are calculated#

When a policy applies, the ticket gets a first response due time and a resolution due time, counted from when the ticket was created:

• If your organization has a business calendar, only working hours count, and holidays are skipped. A four-hour target on a ticket raised at 16:00 on Friday falls due partway through Monday.
• With no business calendar, the targets run around the clock.

SLA states, and how each is reached#

What counts as a first response#

The first comment posted as a Public reply on the ticket. Internal notes don’t count, and neither do status or assignee changes.

Pausing while you wait on the customer#

Changing a ticket’s status to Pending pauses its clock. When the status changes to anything else, the clock resumes, and both due times move later by exactly as long as the ticket was paused, so waiting on the customer never counts against you. (A due time that’s already been achieved, such as first response after a public reply, isn’t moved.)

Reopen behavior#

restart

Reopening gives the ticket fresh first response and resolution due times, counted from the moment it was reopened.

new cycle

Like restart, and the first response is tracked again: the next public reply counts as a new first response.

continue

The original due times are kept, so a ticket reopened after its resolution due time is already overdue.

In every case the SLA state goes back to Running.

Check for breaches#

Breaches aren’t checked on a schedule. The SLA policies tab says so: “No scheduler exists yet — breach checks run manually.” To update every ticket’s SLA state:

1. Open the SLA policies tab

   SupportSettingsSLA policies

2. Select Check breaches now

   Every ticket with a policy that isn’t paused, resolved, closed, or already breached or met is checked against the rules above.

3. Read the result

   The message says “No breaches found”, or lists the tickets whose state changed by ticket number. The list includes tickets that became at risk as well as breached ones.

FAQ#

Related#

• Support tickets
• Support settings
• Business calendars