Ticket Triage for MSPs: Routing Is the Easy Part
A ticket comes in at 8:51 from the portal: "email not working." It lands on the Service Desk board, gets a type of Email, a priority of Medium, and is assigned to the next tech in the rotation. By most definitions it has been triaged. The tech opens it at 9:20, and the first thing they do is reply to ask whether it is just this user, what the error says, and whether webmail works. The client answers at 10:05. The tech is on something else by then. Real work on the ticket starts close to lunch.
Nothing in that ticket was misrouted. It was sorted correctly and still sat for three hours, because it arrived without the information anyone needed to start. That is the part of ticket triage most guides skip, and for an MSP it is usually the expensive part.
What ticket triage is
Ticket triage is the first pass on a new ticket: working out what kind of request it is, how urgent it is, who should work it, and whether it has what that person needs to begin. In an MSP that pass happens on a PSA board, in ConnectWise PSA, Autotask, HaloPSA or Syncro, before a technician picks the ticket up.
Most definitions stop at the first three. A typical one from a vendor in this space describes AI ticket triage as "the automated summarizing, categorizing, prioritizing, and routing of incoming service tickets" (CloudRadial). That is accurate as far as it goes. The fourth question, whether the ticket is workable yet, is the one that decides how long it sits.
The four questions triage has to answer
- What is this? The request type. Password reset, new hire, printer, email, access request, outage. This drives the board, the type and subtype, and which checklist applies.
- How urgent is it? Priority, ideally from impact (how many people or how much of the business is affected) crossed with urgency (how soon it hurts). The impact-by-urgency matrix is standard incident practice; PagerDuty's write-up is a clear one.
- Who should work it? The board, the tier, the person, or a specialist queue.
- Can someone start it? Does the ticket contain the facts the first technician will need, or will their first move be a question back to the client?
Questions one to three are classification. They are fast, and with a clean board structure they are hard to get badly wrong. Question four is a conversation, and conversations take time measured in the client's response, not yours.
Why routing gets the attention
Routing is visible. A ticket on the wrong board, or a P1 sitting as a P3, is an obvious failure that someone complains about. It is also the part dispatch tools and PSA workflow rules handle well: keyword rules, email-to-board mappings, and now AI classification all sort tickets in seconds.
A ticket with missing details looks fine on the board. It has a type, a priority and an owner. The cost only shows up later as a gap between "assigned" and "actually started," and that gap rarely appears on a dashboard because the ticket was technically in someone's queue the whole time.
Where the time actually goes
If you read your own tickets from a week, the delay on most routine requests follows the same shape:
- The first reply is a question. The tech opens the ticket and the first note is "can you tell me..." rather than any work. Every one of those is a round trip that the client controls.
- The question comes late. It is asked when a tech gets to the ticket, not when the ticket arrives. If the queue is an hour deep, the question is an hour late before the client has even seen it.
- The answer lands on a busy tech. The client replies, but the tech who asked has moved on, so the answer waits again.
- Different techs ask different questions. One asks for the error message, another asks for a screenshot, a third skips it and remotes in to look. The same request type gets worked three ways.
- Some requests can never be started without a person outside IT. A new hire needs a start date, a manager and whose access to copy. A paid software request needs whoever approves the cost. Those answers are not something a tech can find by looking harder.
None of this is solved by routing faster. A perfectly routed ticket with no error message is still a ticket that starts with a question.
Triage for workability, not just routing
The fix is to move the information-gathering to the moment the ticket arrives, and to make it consistent by request type. In practice that means four things.
Define what each request type needs. For each common request, write down the facts a tech needs before they can start. Not a long form, the short list a senior tech would ask for anyway. A reasonable starting point:
| Request type | What a tech needs before starting |
|---|---|
| Onboarding | Full name, start date, job title, manager, whose access to copy, whether a computer is needed |
| Offboarding | Name, last working day, what happens to their mailbox, who mail forwards to |
| Email problem | What exactly happens, the error word for word, where they see it (Outlook, phone, webmail) |
| Internet or network | Just them or others, which site, wired or wifi, when it started |
| Password or lockout | Which account or system, for them or someone else |
| Printing | Which printer and where, whether another printer works, any error |
| Software or licence | Which software, who needs it, which computer, who approves the cost |
| Access request | What resource, who needs it, read-only or full, who approves |
Ask at intake, not at pickup. The question should go out when the ticket arrives, so the client's response time overlaps your queue time instead of adding to it. Portal forms help here, but only for clients who use the portal and pick the right form. Email remains the main channel for many MSPs, and email tickets arrive with whatever the user felt like typing.
Cap the questions. Clients answer one short message. They ignore a questionnaire. Ask only for what is missing for that request type, and stop after a couple of rounds. A ticket that goes to a tech with two of four facts is still better than one that waits for the fourth.
Write it up where the tech will look. The answers should end up as one internal note on the ticket that says what is known and what still needs confirming, so the tech does not have to read a thread of back-and-forth to get started.
Tickets that came from a phone call are different
Everything above applies to tickets the client wrote: email and portal. A ticket a dispatcher or tech logged while on the phone is a different case. The client already had a conversation, with a person who could ask follow-up questions in real time. Emailing them afterward to ask what they just said on the phone is a bad experience.
For phone-originated tickets, the information is already there, in the call. The triage problem becomes a documentation problem: did what was said on the call make it into the ticket? That is where call-to-ticket notes matter more than a triage form. We covered why phone work is the part of the service desk most likely to go unrecorded in MSP ticketing systems: the phone call test and MSP time tracking.
Who should own triage
Most MSPs end up with one of three setups:
- A dedicated dispatcher or service coordinator. Consistent, but it is a salary, and the role becomes a single point of failure on sick days and lunch breaks.
- A rotating triage tech. Spreads the load, but quality varies with whoever is on rotation, and triage loses to real tickets when the queue is busy.
- Everyone triages their own tickets. Common in small shops. It means the information-gathering happens at pickup, which is exactly the delay described above.
Whichever you pick, the request-type checklist is what keeps it consistent. It is also what makes automation possible, because a tool can only ask the right questions if someone has decided what the right questions are.
Where AI fits in ticket triage
AI is now good at the classification questions. Reading a free-text email and deciding it is an email problem, not a network outage, is a task current language models handle reliably, and several MSP tools do it.
The more useful step is letting it handle the conversation too: match the ticket to a request type, see which facts are already in it, ask the client for only the missing ones, read the reply, and hand over a written summary. That is what Vight's ticket triage does for ConnectWise and HaloPSA. You define the scenarios (or start from ones drafted from your own recent tickets), Vight emails the requester for what is missing, posts an internal note with what was answered and what a tech should still confirm, and can move the ticket to a status you map for each board.
A few guardrails matter more than the AI itself, whichever tool you use:
- A limit on how many times it asks. Vight defaults to two asks before it writes up with what it has.
- A do-not-email list. Some clients, or some contacts, should never get an automated question.
- It stands down when a person takes over. If a technician replies on the ticket, the automation should stop.
- Only tickets the requester wrote. Vight's triage skips tickets logged on someone's behalf, such as a tech logging a call or a monitoring alert.
- Changes you approve. New scenarios should arrive switched off so someone reads the wording before a client sees it.
How to start this week
You do not need a tool to get most of the benefit.
- Pull the last two weeks of tickets from your main board and sort them by type.
- For the five most common types, write the short list of facts a tech needs to start.
- Read twenty of those tickets and count how many had a question as the first tech reply. That number is your baseline.
- Turn the lists into canned replies your dispatcher or first responder sends the moment a ticket arrives.
- Check the same count two weeks later.
If that count is high and nobody has time to send the questions fast enough, that is the case for automating it.
Frequently asked questions
What is ticket triage in IT support? Ticket triage is the first review of a new support ticket to decide what kind of request it is, how urgent it is, who should work it, and whether it contains enough information to start. In an MSP it happens on a PSA board before a technician picks the ticket up.
What is the difference between ticket triage and dispatch? Dispatch decides who works a ticket and when. Triage decides what the ticket is and whether it is ready. Dispatching a ticket that is not ready just moves the wait to the technician's queue.
How should an MSP set ticket priority? Cross impact (how many users or how much of the business is affected) with urgency (how quickly it causes harm) and map each combination to a priority. Agree the definitions with clients, since one user's "urgent" is rarely a P1.
Should triage ask the client questions automatically? For email and portal tickets on routine request types, yes, as long as the questions are short, specific to the request, capped at a couple of rounds and stopped once a technician steps in. For tickets logged from a phone call, no: capture what was said on the call instead.
Can AI do ticket triage in ConnectWise or HaloPSA? Yes. AI can classify tickets, and some tools, Vight included, can also email the requester for missing details and write the answers back onto the ticket as an internal note. Check that any tool lets you control which clients it contacts, how many times it asks, and that it stops when a technician takes over.
If thin tickets are what slow your desk down, book a demo and we will show triage running on a ConnectWise or HaloPSA board.