Support & Helpdesk: SLAs & Agent Operations

Every ticket runs on an SLA with two distinct targets: a first-response target (how quickly someone acknowledges and replies) and a resolution target (how quickly it is actually solved). These are separate on purpose — a fast first response buys trust even when the fix takes longer — and both come from the ticket's category, which sets each target in minutes and chooses whether the clock runs on elapsed time or on your working hours only. Priority orders the work; it does not change the deadline.

The clock is a live signal, not a report you run later. Timers show what is due soon and what is already at risk, so agents and leads can triage by urgency rather than by whoever shouts loudest. When a target is missed the ticket breaches, and a sweep every fifteen minutes alerts the assignee and their line manager — or the department queue when nobody owns it. The alert is a message, not an action: moving, re-prioritising or handing the ticket on happens through the escalation rules you configure (see the Helpdesk Automation course). The point is that a slip surfaces on its own instead of being discovered by an unhappy customer.

Because targets follow the category, honest categorisation at intake is what makes the whole system work. Filing everything under the category with the tightest targets is self-defeating: every clock shortens, the at-risk view floods, and the genuine emergencies hide among routine work. Set the real category — and an honest priority to order the queue — and the SLA numbers become a trustworthy map of where attention is needed.

An agent works a ticket from the Tickets queue or the agent dashboard. The single most important distinction is between a public reply and an internal note: a public reply is seen by the requester and stops the first-response clock; an internal note is a private message to teammates that the requester never sees. Putting sensitive or half-formed thinking in a public reply — or, conversely, hiding the actual answer in an internal note — are the two classic mistakes.

Beyond replying, agents attach files as evidence, watch a ticket to get updates even when they are not the owner, and escalate when a ticket needs more authority or a different team. Escalation and reassignment are complementary: escalate when the issue needs to go up, reassign (or move queue) when it simply needs a different pair of hands. Every change is captured against the ticket, so its history is a complete, auditable trail. For answers you send again and again, a canned reply searched from the reply box fills in details such as the requester's first name and the ticket reference, and can set status or priority in the same click.

The resolution habit that keeps requesters happy is to close the loop explicitly: move the ticket to resolved with a public reply that says what was done, rather than silently marking it done. A resolution the requester never sees feels like being ignored even when the work happened — and it invites a duplicate ticket for the same issue.

Requesters are not left in the dark. A public requester uses the tracking reference from their submission to check status and reply without ever creating an account, and staff follow their own tickets from My Tickets inside AWRA — status, comments, attachments and the eventual outcome all in one place. Self-service deflects the "any update?" messages that otherwise consume agent time.

When a ticket is resolved, the requester can leave a satisfaction rating. Ratings are the feedback loop that tells you whether "resolved" actually meant "solved" from the customer's side, and aggregated over time they surface which categories, teams or agents need support. A high resolution speed with low ratings is a signal that tickets are being closed, not solved.

Managers read the desk through these same signals: SLA performance, resolution speed, and rating trends together describe service quality far better than any one number. The throughline of the whole module is that everything — intake, queues, the SLA clock, replies and ratings — is one connected record per request, so the story of every ticket is complete and the story of the desk is measurable.