Ticket Stages, On Hold & SLA Pause

Every ticket moves through the same five stages, and the SLA clock stops while you're waiting on someone outside your team. This page explains the lifecycle, how the pause works, and how to add your own pending stages.

1. The Core Lifecycle

QueueDesk uses the standard ITIL incident lifecycle. These five stages are fixed — they can't be renamed or removed, which is what lets your reports, queue filters and SLA rules stay comparable over time and across teams.

A sixth stage, Merged, appears only when a duplicate ticket is merged into another one. Agents don't set it by hand.

Which moves are allowed

Agents can't jump the lifecycle in ways that would corrupt your reporting. From any active stage (Open, In Progress, On Hold) an agent can move to any other active stage, resolve, or close directly — a direct close is there for cancellations and duplicates. A Resolved ticket can be reopened or closed. A Closed ticket can be reopened if it turns out the fix didn't hold. A Merged ticket is final.

Employees only ever see two of these on the portal: they can confirm a fix (Resolved) or reopen a ticket (Open). Putting a ticket on hold is always a service-desk decision — an employee can't pause your SLA clock.

Resolving and closing also have their own required fields — resolution notes, a close code, an assignment group. Those are configured separately in Closure Rules.

2. Putting a Ticket On Hold

An agent sets On Hold from the Status field in the ticket sidebar, exactly the way they'd set In Progress or Resolved — nothing pops up to confirm it. A second field, Pending reason, then appears directly under the status, and that's where they record what they're waiting on. Each option shows what it does to the clock, and the field itself carries a SLA STOPPED or SLA RUNNING badge so the current state is obvious at a glance.

The two are separate fields on purpose: what you're waiting on changes far more often than the status does — a vendor answers and now you're waiting on an approval, while the ticket stays on hold throughout.

If an agent sets On Hold without touching the reason, it defaults to Pending customer and the field shows that, so it's one click to correct rather than a question to answer every time.

Five reasons are built in. The clock behaviour below is the default — you can change any of it, see choosing which reasons pause the clock.

Those defaults follow one principle: the first four are delays your team can't control, so they shouldn't count against your SLA, while Pending internal action keeps the clock running because that delay is yours, and hiding it would make your reporting flattering but useless.

To change the reason later, just pick a different one in the Pending reason field. The ticket stays on hold throughout and keeps the time it has already banked — swapping the reason doesn't restart the hold.

3. How the SLA Pause Works

Both clocks pause together: first response and resolution.

1. When the ticket goes on hold with a pausing reason, QueueDesk records the moment the hold started.

2. While the ticket sits on hold, its deadlines are pushed out live by however long the hold has lasted. The ticket detail sidebar shows the SLA bar in amber with "SLA paused", plus a running count of how long the hold has lasted ("On hold for 2d 4h — SLA clock stopped").

3. When the ticket leaves On Hold, the deadlines are permanently extended by the full length of the hold, and the total paused time is banked on the ticket for reporting.

4. If the ticket goes on hold again, the same thing happens again — paused time accumulates across every hold.

So a High-priority incident with a 1-hour response target that spends three days waiting on a vendor is not breached when the vendor replies. It still has whatever was left of its hour.

Breach badges honour the pause

The SLA breached badge in the agent queue, and the overdue count on your dashboard, both use the paused deadline rather than the original one. A paused ticket won't show up as overdue and won't inflate your breach numbers.

What ends a hold automatically

• •The requester replies on a ticket that's on hold for Pending customer — by portal comment or by email reply. The ticket moves to In Progress and the clock restarts immediately, because you're no longer waiting on them.

• •The requester marks it fixed from the portal.

Any other pending reason waits for an agent, since nothing about a vendor's silence or a change window tells us the block is over.

Every pause and restart is written to the ticket's Activity timeline ("SLA clock stopped — Pending vendor / third party", "SLA clock restarted — no longer Pending customer"), so you always have the audit trail behind an extended deadline.

What the requester sees

On the portal, a ticket on hold for Pending customer reads "On hold — waiting on you", which is a useful nudge. Every other reason reads plain "On hold" — QueueDesk never tells an employee they owe you something when they don't, and never shows them your internal pending reason.

4. Adding Your Own Pending Stages

The five built-in reasons cover most teams, but you can add your own — "Pending vendor sign-off", "Awaiting CAB", "Scheduled for maintenance", "Waiting on parts delivery". Go to Settings → Ticket stages.

The page has three parts. Core lifecycle lists the five fixed stages with a padlock, so it's clear what can't change. Built-in pending reasons is where you set the clock behaviour of the five standard reasons. Your pending stages is where you add your own.

Choosing which reasons pause the clock

Whether a wait is "outside your control" is a policy call, not a fact, so it's yours to make. Under Built-in pending reasons, each of the five has a Pauses SLA checkbox that saves the moment you click it.

A desk that runs its own maintenance windows, for instance, may well want Pending change window counted — the delay is theirs. Equally, a small team whose "internal action" means a genuinely blocked queue may want Pending internal action to stop the clock.

Changing a reason affects holds started from then on. Time already banked on a ticket stays as it was, so past deadlines aren't retroactively recalculated.

Creating a stage

1. Click New stage.

2. Give it a name, up to 60 characters — this is exactly what agents will see in the Pending reason field, so name it after what you're waiting on.

3. Decide whether Stop the SLA clock while a ticket sits here should be on. Leave it on when the wait is outside your team's control; turn it off for internal delays you still want counted.

4. Click Add stage. It's live immediately — no save button, no republish.

You can create up to 12 custom pending stages. That cap keeps the agent's reason list usable.

Changing or removing a stage

Each stage row has two toggles and a delete button, and all three save the moment you click them:

Why these are sub-states of On Hold

A custom stage is a more specific flavour of On Hold, not a sixth lifecycle stage. A ticket using "Awaiting CAB" still reports as On Hold everywhere: in the queue's status filter, on your dashboard, in every SLA calculation and every export.

That's deliberate. It means you get the operational detail your team actually talks about, without fragmenting your metrics into a shape nobody else can compare against — and without breaking the ITIL lifecycle your reports depend on. If you added true new lifecycle stages, every report and every integration would have to learn about them.

5. Resolution Deadlines and the Live Timer

Alongside first response, every priority in SLA Rules has a resolution target, and QueueDesk tracks it on every ticket. Both deadlines appear in the ticket sidebar's SLA Due section — First response due and Resolution due — each with its own bar, and both pause together while a ticket is on hold.

Each bar counts down live, and switches to seconds inside the final hour so an agent racing a deadline can see it move. A paused ticket shows PAUSED with its remaining time held steady; a missed one shows how long it's been BREACHED.

The resolution deadline is set when the ticket is created and recalculated if its priority changes, so raising a ticket from Low to High tightens the target rather than leaving the original one in place.

Every new workspace starts with sensible targets already in place — 1 hour to respond and 4 hours to resolve on High, 4 hours and 1 day on Medium, 1 day and 3 days on Low — so timers work from your first ticket. Change them in SLA Rules; clear a field to switch that target off.

Next, read Assignment Rules & Groups to route tickets to the right team automatically.