How to triage helpdesk tickets against an SLA

To triage helpdesk tickets against an SLA, sort every new ticket before anyone starts fixing it: match it to the client and the agreement, set its type and priority from one written matrix, ask for the missing details in the first reply, and route it to a queue while there is still response time in hand. The response target runs while a ticket sits unread, so triage needs its own owner and its own routine. An AI worker can do the reading, sorting and asking. Major incidents, security and every fix stay with your people.

What starts the job, and what starts the clock

A ticket reaches a managed service provider by email, through the portal, by phone or from a monitoring alert. From that moment your PSA is counting. In Autotask the ticket's service level agreement is picked by default from the asset, the contract or the ticket category, and the times by which a first response and a resolution are due are set by the system from that agreement, not typed in on the ticket.

The two things a hurried analyst gets wrong, the agreement and the priority, are the two things the deadline is worked out from.

Who sorts the tickets today, step by step

1. Read and match. Work out what is being asked, which client and site it belongs to, and whether the same fault is already open. Today this is a dispatcher, or whichever service desk analyst is between calls.

2. Check the agreement. Is the user covered, for this kind of work, at this hour? The dispatcher looks it up in the PSA or remembers it.

3. Set type and priority. Decide whether it is a fault or a request, then set a priority from two questions: how many people are affected, and can they still work?

4. Complete the ticket. Which device, what the error says, when it started, what changed, who else has it. Often the engineer asks this later, after the ticket has waited.

5. Route it. The right queue or board, with a two-line summary, and an engineer if your rules name one.

6. Watch what is left. Someone looks down the board for tickets still unassigned as their response time runs out.

Four things you can fix this week

• Put the priority matrix on one page. Impact down the side, urgency across the top, a priority in every cell, and two or three examples of each from your own tickets. If two analysts would place the same ticket differently, the matrix is not finished.

• Write the first-reply questions for your ten commonest ticket types. By default, HaloPSA treats its respond-by target as met after the first response to the user. Whether a reply that only asks questions counts as that response is your PSA's setting and your agreement with the client. A first reply that asks the right five questions saves the engineer a round of email.

• Check what your waiting statuses do. Autotask notes, each time a ticket goes into Waiting Customer, how long was left before its next SLA target, and HaloPSA can put a ticket on SLA hold. Whether a question to the user stops your clock is a setting in your own PSA.

• Name who owns triage for each part of the day. Give it one name, so that it is never "whoever is free".

Which steps an AI worker can take on

An AI worker can take on several of these steps. Set up as AI staff, it works to a written specification and a named person checks its work. For triage, it can read every ticket raised in writing or by an alert, match the sender to a client and site, look for a duplicate, set the type and priority from your matrix and write its reason on the ticket. It can add the asset and the agreement, send your approved questions for that ticket type (whether that counts as your first response is your decision), route the ticket with a summary and tell the dispatcher about anything still unassigned as its target approaches. The role is specified on our page for helpdesk ticket triage; answering a client who asks who has their ticket belongs to first-line client support.

What stays with your dispatcher and engineers

A major incident, a suspected security incident and a complaint go straight to the person you name, because declaring an incident commits your engineers and your reputation. A sender the worker cannot match to a client waits, because guessing the wrong client puts one firm's problem in another's record. Choosing the engineer stays with the dispatcher unless you set a rule. A priority that a person has set is not changed by the worker. Phone calls are taken and logged by your team. And every fix, password reset and change in a client's environment is an engineer's: triage sorts the work, it does not do it.

What to have ready before starting

• The priority matrix and your ticket types and categories, as your PSA has them.

• What each agreement covers, and its response and resolution times.

• Your written rules for a major incident and for anything that might be a security incident, with the name and number of who is told.

• The approved first-reply questions, by ticket type.

• A month of closed tickets showing how often one was moved to another queue or sent back for details.

Our page for MSPs and IT support firms covers the admin around triage too, from licence renewals to time entries and QBR packs. The case for taking triage off your analysts is in how to scale an MSP without hiring more staff.

Your AI worker would sort each new ticket in your PSA by your matrix and your agreements, with your dispatcher checking its work and your engineers doing the fixing. A ticket nobody has read is still using up its response time. Talk to our agent.