Ticket Triage: How A Small IT Team Sorts And Routes The Queue

Ticket triage is the first pass on a new ticket. You confirm who sent it, check the facts, set a class and a priority, pick an owner, and send the first reply. Every later step, from the fix to the invoice, depends on it.

Below: classes, intake facts, ordered routing rules with named fallbacks, exceptions, and hard cases from an MSP, an office IT team, and a school. They come from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) tool a small IT team can run alone.

What Is Ticket Triage?

Ticket triage is the sorting step between a new ticket and the work. The word comes from French for sorting, from trier, "to sort". On a helpdesk, the first level of support performs the initial triage and escalates what it can't resolve within a set time.

Four neighboring terms get mixed up with it, and each answers a different question:

The UK Cabinet Office describes the same split. Its first line is the single point of contact for staff, and it routes other tickets "to the correct 2nd line team." On a team of three, both lines are the same people, so ticket triage has to be its own step.

Why Ticket Triage Matters On A Small Team

Without ticket triage, the queue runs in arrival order, or in the order people complain. The Cabinet Office requires every incident to be classified by impact and urgency because it "ensures a consistent response."

A city audit shows what poor intake data does to sorting. Oklahoma City's auditor reviewed the fire department's IT tickets from September 2024 to June 2025.

For 16% of tickets, the "Issue" field held only "Email Generated", which the auditors put down to "a design weakness in the ticketing system." They found tickets resolved "with reasonable timeliness", but service requests and incidents weren't classified separately. Their warning: tickets "may not be prioritized" well if they aren't classified.

On a small team, the cost shows up in three places:

• The loudest email wins. One r/msp member wrote, "Lately, it feels like every ticket that comes in is marked "URGENT"".
• Tickets bounce. Each reassignment loses context and time.
• Tickets sit. A ticket with no owner has no deadline.

What You Need Before You Start

Five things should exist before you write the rules:

1. One queue. Email, portal, phone, and hallway requests all become tickets in one place.
2. Written priority levels and targets. Our ticket priority levels guide has a grid and example targets.
3. A coverage list. Who handles which skills, clients, or buildings, and who covers for each person.
4. A triage owner for every shift. One name per morning and afternoon, on a rotation everyone can see.
5. An alert channel. A phone number or chat channel that reaches the triage owner at once in coverage hours. It's for security reports, outages, and deadlines that can't wait for the next sweep.

An r/ITManagers commenter put it plainly. "There should essentially be someone always eyes on the queue who is responsible for initial triage".

A permanent dispatcher is a single point of failure, though. One r/msp member who ran that model wrote that "having one person didn't work when they took leave etc, there was no triage after hours etc".

The rotation covers leave during coverage hours. After hours, publish a separate on-call order, or tell users that tickets wait for the 8:00 a.m. sweep.

The Ticket Triage Process, Step By Step

Ticket triage runs in two passes: a quick sweep of everything new for exceptions, then full triage of each remaining ticket, oldest first. Exceptions go to their owners the moment the sweep finds them. Ordinary tickets wait until the sweep is done; then each goes to its owner as soon as it's triaged.

1. Sweep the new tickets for exceptions

   Read subjects and first lines only. When you find an exception, phone a security report to rule 1's owner, and hand an outage or qualifying deadline to its rule owner. That owner starts at once.

   Common mistake: filling in every field on a phishing report before anyone looks at the mailbox.

2. Confirm the requester and the account

   The account decides which contract, targets, and coverage apply: a client, a department, or a school building.

3. Check the intake facts, and ask once

   You need scope, a workaround, and any deadline to set a priority. If a fact is missing, ask for everything in one message, and keep the ticket until the answer arrives.

4. Set the request type and the class

   Classify from what the user needs, not from the subject line. "URGENT help" about a jammed printer is an incident in the devices class.

   Common mistake: trusting the category the user picked. Prairie Rose Public Schools tells staff not to worry about choosing the perfect category.

5. Set the priority from your written levels

   Use your impact and urgency grid. The user describes the business effect; the grid decides the level.

   Example: as one r/msp commenter put it, "The client always gets a say in business impact, its their business. The client never gets a say on technical urgency".

6. Route by the first matching rule

   Apply your numbered rules, and use the named fallback if the owner is out. Tie repeat reports of the same problem to a single parent.

   Quick fixes: after the sweep, the triage owner may close a two-minute fix on the spot if it needs no approval. Add a one-line note. Prairie Rose notes that quick items "may be dealt with first depending on the situation."

7. Send the first reply

   A person, not the automatic receipt, tells the user what happens next. UNC Asheville tells users its confirmation email is "not a reply from a person."

Our Helpdesk SOPs guide turns these steps into a copyable SOP.

Classify Each Ticket By Type And Class

Use two attributes, so two technicians pick the same answer: request type and technical class.

Request type has two values. An incident is something that worked and now doesn't, or works badly; a request is something new or a change, such as an account, access, equipment, or an install.

The University of Illinois's ticket guide lists classifications "such as Incident, Service Request, Problem, Change".

Technical class says where the work happens. Keep six to eight, and write the boundary into each one:

The axes combine: a software install is a request in Applications, a jammed printer an incident in Devices. Security reports and outages aren't classes; they are exception flags that route first.

Test the list: two technicians sort 20 closed tickets on their own. Where they disagree, move the boundary.

The Facts To Collect At Intake

Split the facts in two: what the user's form asks, and what the triage owner adds. Keep the form short.

One r/k12sysadmin commenter warned: "don't make them have to fill in 10 required fields just to submit an incident". Another set the floor: "They can't just say "I need help." They have to actually answer some basic stuff."

Missoula County Public Schools asks staff for their name, building, room number, and the name of the device with the problem. For the questions to ask on the phone, see the intake questions in our helpdesk best practices.

Groups And Assignment Rules

Routing is the part of ticket triage a rule can do every time. Build groups first, then numbered rules.

Groups. Group technicians by skill or by whom they serve (a client, a building). Then pick how a group shares tickets:

• Dispatcher. Accurate, until that person is out.
• Self-pick from a pool. One r/msp commenter's warning: "Self dispatch works until your techs learn how to cherry pick."
• Round robin. Fair by count, not by effort. An r/ITManagers commenter saw techs who "have "forgotten" to place themselves back on-queue after returning from lunch".

Rules. Number the rules, check them in order, and let the first match win. Each rule names an owner and a fallback person.

To pick the owner, the University of Alaska's guidance works well: set the responsible group to the one "completing at least 80% of the primary work."

The order settles overlaps. One user at a client with a named tech can't connect to the VPN. Rules 4 and 6 both match, so rule 4 wins: the named tech owns it. A phishing report from a school building matches rules 1 and 5, and rule 1 wins.

Owning isn't doing it alone. The owner can pull in the network admin and still keeps the ticket.

Teams forget rule 9. The University of Missouri keeps a ticket with the default group when no tier 2 or tier 3 group exists, and that group can delegate tasks to other teams.

This order is a procedure you write; check how your tool orders its rules before copying it.

Exceptions That Skip The Line

Three kinds of ticket leave the queue the moment the sweep finds them: rules 1 to 3. Write each exception down.

Security reports. A phishing click, an odd sign-in, or a ransom note goes to rule 1's owner by phone, before any form. The rest of ticket triage can wait; that call can't. The first reply thanks the reporter.

The UK's National Cyber Security Centre asks for a phishing reporting process that's "clear, simple and quick to use". It also warns that "Users who fear reprisals will not report mistakes promptly, if at all."

Outages. When several people report the same dead Wi-Fi, open one parent ticket, link the rest, and close them together. The Cabinet Office's top priority, P1, covers a critical business service outage, such as all-staff network, email, or SSO.

Deadlines. A deadline leaves the queue only when it falls before the next sweep, there's no workaround, and missing it stops work or costs money. Payroll must go out by 10:30 a.m., the 10:00 sweep finds the ticket, and no other PC can run it, so staff would be paid late: that qualifies. A laptop needed next month doesn't: it gets normal routing and a due date.

VIPs. If the owner's laptop gets faster service, write that into a rule. The Cabinet Office lists seniority as an impact factor: "Are SCS, Ministers, or their Private Offices affected?"

What The First Reply Must Contain

The first reply ends ticket triage. It's short, written by a person, and answers five things:

1. The ticket number.
2. What you understood, in one line, so the user can correct it.
3. Who owns it, by name.
4. What happens next, and anything you need from the user.
5. When they'll hear from you again, as a time, not "soon".

As one r/k12sysadmin commenter wrote, "people just want to know that someone is hearing them or acknowledging their issue."

Keep the reply separate from the fix. An r/msp commenter noted that their "SLA is for "first touch," not issue resolution." Prairie Rose Public Schools aims "to acknowledge tickets within 2 business hours, depending on our volume".

Example: "Ticket 4821: Room 114's projector shows no signal. Dana, your technician, will be there by 9:20. Next update by 9:35." For more wording, see our support ticket response templates.

A Daily Ticket Triage Routine

Run ticket triage at fixed times; between sweeps, the alert channel catches security reports, outages, and deadlines that can't wait for the next sweep.

1. 8:00 a.m.
   Morning sweep

   Exceptions sweep over the overnight tickets, handing each exception over as it's found. Then full triage, oldest first, with each ticket going to its owner as it's triaged.

2. 8:30 a.m.
   Five-minute huddle

   P1 and P2 tickets, anything unowned, and who's out today.

3. Every hour
   Short sweep

   The same two passes on new tickets; quick fixes under two minutes get closed.

4. 3:30 p.m.
   Aging check

   Re-triage tickets with no owner, reply, or update since morning. Phone users whose facts haven't arrived.

5. 4:45 p.m.
   Hand-off

   Owners of open P1 and P2 tickets write the status and next step for the next shift or the on-call tech.

Worked Examples From An MSP, An Office, And A School

The rules above, applied to a missing fact, overlapping rules, a deadline, and an owner who's out.

For an MSP, the account set at ticket triage is also the account the time bills to. The wrong client means the hours land on the wrong invoice.

A Routing Rule Template

Most teams never write each rule down. Copy one block per rule.

Routing rule
Order: [number; 1 is checked first, first match wins]
Condition: [exception flag, account, building, request type, or class]
Owner: [person or group]
Fallback person: [who takes it when the owner is out]
Yields to: [rule numbers checked before this one]
Manual override allowed when: [an agreed exception, e.g. a contract that names another owner]
Reason logged on override: [one line on the ticket]
Last reviewed: [date] by [name]
Pulling in a specialist is not an override; the owner keeps the ticket.

Example
Order: 4
Condition: Account has a named tech in the contract
Owner: The named technician
Fallback person: Backup tech on the coverage list
Yields to: 1 (security), 2 (outage), 3 (deadline)
Manual override allowed when: the contract assigns network work
  to the network admin (agreed exception)
Reason logged on override: "Contract exception: network work"
Last reviewed: [date] by [lead tech]

Common Ticket Triage Mistakes

Working before the sweep. Until the sweep is done, nobody knows whether a security report or an outage is waiting. Exceptions go out as they're found; ordinary tickets go out one by one after the sweep.

How To Measure Ticket Triage

Measure ticket triage by the rework it causes, not only by speed. Five numbers, read monthly:

Then sample 20 closed tickets a month: were the class, priority, and first owner right the first time?

For first response time and SLA compliance, see our helpdesk metrics guide.

Set Up Ticket Triage In SherpaDesk

About the author

Patrick Clements Co-founder & CEO, SherpaDesk

Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.

All Articles