Escalation and SLA What the clock is measuring, and what escalating a ticket does and does not do.

The clock

Every ticket carries two deadlines: a first response due time and a resolution due time. Its SLA state is one of three:

• On track, still inside the deadline
• Met, answered or resolved in time
• Breached, past the deadline

The deadlines come from your organisation's SLA policy, which can vary by severity and by customer tier, so a critical ticket from a major account is not on the same clock as a low-severity question.

Waiting pauses the clock. That is deliberate: you should not be penalised for a customer taking three days to reply. It is also why Waiting tickets need chasing, since a paused clock never breaches and the ticket simply goes quiet.

What Escalate actually does

The Escalate button on the ticket panel does three things: sets the status to Escalated, raises the priority to High, and records when it happened.

It does not assign anyone. There is no automatic routing to an on-call person, and no notification is sent to a specific individual. Escalating raises a flag; a human still needs to see the flag and act.

In practice that means escalation works when somebody is watching the queue for escalated tickets. If nobody is, an escalated ticket is just a ticket with a different label. Decide who owns that watch before you rely on it.

Handling an escalation

Because escalating does not route, the reliable pattern is:

1. Escalate, so the state is recorded
2. Assign an owner explicitly, so it belongs to someone
3. Tell them, through whatever channel your team actually reads

Steps two and three are what make the difference. Step one is the audit trail.

Escalation boards

For cases that run for days, a board gives them somewhere to live: Investigating, Awaiting customer, Resolved. Boards are built as templates in Operations and deployed to Support.

Use them for the handful of cases that need structured oversight, not for the queue at large.