IT ticket triage: why tickets keep getting moved

A laptop that won’t connect to the VPN is raised as “Software”, because that’s the first option on the form. It goes to the applications team, who move it to networking on Tuesday afternoon. Networking finds an expired certificate on the laptop and moves it to the endpoint team on Wednesday. The endpoint team fixes it in ten minutes. The ticket spent two days in queues and ten minutes being worked.

Sorting each ticket to the team that fixes it is the first stage of the IT service desk. Every later stage starts from wherever triage put the ticket.

What is IT ticket triage?

IT ticket triage reads each incoming request, works out what it’s about and how urgent it is, attaches the requester’s context, and sends it to the one team that can fix it. It happens on arrival, for every channel, and a ticket that matches no rule goes to a named queue that someone watches.

Why tickets keep getting moved

1. The requester picks the category. People choose the first option that looks close, and routing trusts the choice.
2. Every channel has its own intake. A Slack message, an email and a portal form follow different rules, so the same problem is routed three ways.
3. Context arrives late. The team that receives the ticket starts by looking up the person’s role, location and devices, and sometimes finds the ticket belongs somewhere else.
4. Two teams share a ticket. A ticket assigned to two queues is owned by neither, and each team waits for the other.
5. Unclear tickets are routed on a guess. A one-line “it’s broken” goes somewhere, and comes back.
6. Nobody counts the moves. Routing rules drift away from how the teams split the work, and nothing shows it.

What it costs

Every move restarts the wait. A ticket that moves three times spends most of its life in queues, so the time to resolve it measures the routing more than the fix.

It also costs the people doing the moving. Each reassignment means someone read the ticket, decided it wasn’t theirs and passed it on, which is work that fixes nothing.

What to fix first

1. Find where tickets bounce. Compare the category each ticket was opened with against the category it closed with, and count the moves per category. Start where they disagree most.
2. Bring every channel into one intake. Slack, Teams, email and the portal create the same ticket with the same fields.
3. Classify from the description. Read what the ticket says, and treat the category the requester picked as a hint.
4. Attach context before routing. Pull the requester’s role, team, location, devices and recent tickets from the directory and device records.
5. Route to exactly one team, with a fallback. Anything that matches no rule goes to a named queue that someone watches.
6. Ask one question when the classifier is unsure. Send it to the requester in the channel they used, instead of routing on a guess.

The guide to building IT ticket triage and routing has the prompts for each step.

What it looks like at Life360

Life360 gives employees one place to ask for help: an orchestrator agent in Slack that routes each request to a sub-agent for ITSM, Jira, Confluence or Slack management. The tickets it creates carry the full Slack thread, so IT starts with the context instead of asking for it.

Where it fits

Triage decides where everything else starts. Password resets and requests the role already allows can be handled without a person once triage recognizes them. Incidents need spotting on arrival, before forty people raise the same ticket.

For all six stages, see the IT service desk process.