Automation  ·  IT and security

How to build IT ticket triage and routing

Most IT tickets wait in a shared queue until somebody reads them, and then they move twice before they reach the person who can fix them. Below is the model behind sorting them on arrival, the prompts that build it, and the parts that only bite once it is live.

Built with Tray Headless

  1. System Slack
  2. Step Read the request
  3. Step Classify and attach context
  4. Step Route to one team
  5. System ServiceNow
Also Ask one question

Every ticket is read once on arrival, labelled by what it is about, and sent to one team with the context already attached.

The short answer

What is IT ticket triage and routing?

IT ticket triage and routing has four parts: one intake that every channel feeds, a classification based on what the ticket is about rather than the category somebody picked, the requester's context attached before anyone reads it, and a routing rule that sends it to exactly one team with a fallback when nothing matches. The failure that costs most is reassignment. A ticket that moves between three queues before anybody works it has spent most of its life waiting, and every move resets the clock on the person who owns it.

Stage 1 of 6: Intake, triage and routing. Part of IT service desk, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

  • Classify by what the ticket says, not by the category the requester picked. Requesters pick the first option that looks close.
  • Attach the requester's role, location, devices and recent tickets before routing. Most handling time is looking those up.
  • Route to exactly one team. A ticket shared between two queues is owned by neither.
  • When the classifier is unsure, ask the requester one question instead of guessing. A wrong route costs more than a short wait.
  • Measure reassignments per ticket. It is the clearest sign that routing rules have drifted from how the teams actually split the work.

Who this is for

You run an IT service desk or own the ITSM platform. Tickets arrive from Slack, email and the portal, land in one queue, and wait for somebody to read them and decide where they go.

How it works in practice

The path from a message somebody types to the team that fixes it.

  1. 1

    The request arrives from any channel

    Slack, Teams, email and the portal all create the same kind of ticket, so nothing is triaged twice.

  2. 2

    The request is read and classified

    What it is about, how urgent it is, and whether it is a request or something broken.

  3. 3

    Context is attached

    Who raised it, their role and location, their devices, and anything similar raised this week.

  4. 4

    Routing picks one team

    By category, location and system owner, with a named fallback queue when nothing matches.

  5. 5

    Unclear tickets get one question

    Sent back to the requester in the channel they used, instead of routed on a guess.

  6. 6

    Every move is recorded

    So reassignments per category show where the rules are wrong.

What triage is made of

Four, and the second is the one most teams get wrong.

One intake for every channel

A message in Slack and an email to the help address become the same ticket with the same fields. Two intakes means two sets of rules that drift apart.

Classification from the content

Read the description, not the dropdown. The dropdown records what the requester guessed, which is usually the first option on the list.

Context before routing

The requester's role, team, location and devices, pulled from the directory and device records, plus their recent tickets. The team that receives it starts work instead of research.

Routing with a fallback

One team per ticket, decided by rules IT can read and change. Anything that matches no rule goes to a named queue that somebody watches, never to nowhere.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    Set up, then find where tickets bounce

    Reassignments show where routing is wrong today.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are ServiceNow, Slack and Okta,
or whatever we run in those seats.

Before building anything, pull the last three months of closed tickets
and show me, per category:

  How many tickets
  How many were reassigned at least once, and the median number of moves
  Median time from creation to first touch by the team that resolved it
  The category picked at creation compared with the category at close

The categories where the opening and closing category disagree most are
where the requester's choice cannot be trusted. Start the classifier
there.

    Look at time to first touch by the resolving team, not time to first response. An auto-reply makes first response look fine while the ticket sits in the wrong queue.

  2. 2

    Bring every channel into one intake

    Two intakes means two sets of rules.

    Headless skills build-workflow 

    Use build-workflow. Create a ticket in ServiceNow from each place
people ask for help today:

  A message in the IT help channel in Slack, or a direct message to the
  IT app
  A message in the Teams help channel
  An email to the help address
  The portal form

Each one creates the same ticket with the same fields: requester,
description, channel, and a link back to the original message so the
reply goes where they asked.

If the same person raises the same thing in two channels within an
hour, attach the second to the first instead of opening another ticket.
  3. 3

    Classify from what the ticket says

    The dropdown records a guess.

    Read the description and set three things:

  Category: from our list of categories, using the description, not
  the requester's choice
  Type: something broken, or a request for something new
  Urgency: based on who and how many are affected, and whether they
  can work around it

Give each a confidence. If confidence is low on the category, do not
route. Send the requester one question in the channel they used, with
two or three options to choose from, and route on the answer.

Never lower urgency the requester set without a reason recorded on the
ticket.
  4. 4

    Attach the context the fixer would look up

    Most handling time is research rather than resolution.

    Before routing, add to the ticket:

  From Okta: the requester's role, department, manager and the apps
  they have
  From Workday: location and start date, so a new starter's ticket is
  flagged as one
  From the device records: their laptop, its operating system and when
  it last checked in
  From ServiceNow: their last five tickets, and any open ticket from
  anyone else on the same system this week

If three or more people raise the same system in an hour, link the
tickets and alert the on-call engineer, because that is an incident and
not three requests.
  5. 5

    Route to one team, with a fallback

    A ticket shared between two queues is owned by neither.

    Headless skills tray-gotchas 

    Use tray-gotchas, then route each ticket to exactly one assignment
group, using rules IT can read:

  Category and type decide the team
  Location decides the regional queue where the team is split by region
  The system owner list decides the group for a named application
  Anything that matches no rule goes to the triage queue, with a reason

Keep the rules in a table IT can edit without a deployment. Team
splits change every quarter and the rules have to move with them.

Record every reassignment with who moved it and why, so the report
shows which rules send tickets to the wrong place.
  6. 6

    Report, then hand the rules to IT

    Routing rules drift as teams change.

    Report weekly, per category: volume, share routed without a person,
reassignments per ticket, time to first touch by the resolving team,
and how often the classifier asked a question.

Then open the same workflow in Tray Build so the service desk lead can
change categories, routing rules and the confidence threshold in the
visual canvas. A reorganised team should mean an edited rule, not an
engineering ticket.

What it connects to

Requests arrive where people already ask, and the context lives in the directory, the HR system and the device records.

ServiceNow

Create the ticket, set category, urgency and assignment group, and record every reassignment.

Reads and writes

Slack

Take requests from the help channel and direct messages, ask the clarifying question, and reply in the original thread.

Reads and writes

Microsoft Teams

Take requests from the Teams help channel for the parts of the company that work there.

Reads and writes

Okta

Look up the requester's role, department, manager and current apps.

Reads

Workday

Add location and start date, so tickets from new starters are flagged and routed to the right region.

Reads

Microsoft Intune

Add the requester's device, its operating system and last check-in.

Reads

Jira Service Desk

Route to engineering or app teams that work from Jira rather than the ITSM platform.

Writes

Snowflake

Land routing outcomes and reassignments, so the weekly report is a query rather than an export.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Google BigQuery, Google Chat, Azure Active Directory, SAP SuccessFactors, Jira or Databricks.

Connections in this build

Field mapping, templates and common problems for each pairing: ServiceNow + Slack, ServiceNow + Microsoft Teams, Okta + ServiceNow and Okta + Slack.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

This decides which team owns every ticket the company raises. When it is wrong, everything downstream is slower.

It runs on the platform, not on your laptop

Tickets arrive at any hour and are sorted on arrival, instead of waiting for the first person on shift to read the queue.

The fallback queue is watched

Anything that matches no rule lands somewhere a named person checks every day. A ticket routed to nowhere is worse than one never routed.

Credentials are managed, never written into the build

Reading the directory, HR records and device records needs three separate authentications in your workspace, scoped to read only.

IT owns the rules

Categories, routing rules and the confidence threshold open in Tray Build and change when the teams change.

Every move is on the ticket

Who routed it, which rule matched and every reassignment after, so a complaint about a lost ticket has an answer.

Questions people ask

Why not route on the category the requester picks?

Because requesters pick the first option that looks close. Comparing the category at creation with the category at close usually shows a large share were wrong, and every one of those is a reassignment.

What should happen when the classifier is not sure?

Ask the requester one question in the channel they used, with a few options to pick from, and route on the answer. A short wait for an answer costs less than a ticket that moves between three queues.

How do you spot an incident in the queue?

Several people raising the same system in a short window. Link those tickets and alert the on-call engineer, rather than letting each one wait in a queue as a separate request.

What should triage be measured on?

Reassignments per ticket and time to first touch by the team that resolved it. Time to first response is easy to make look good with an auto-reply and says nothing about whether the ticket reached the right people.

Further reading

Background on the same subject, for the case rather than the build.

Related guides

IT and security

How to build IT service desk fulfilment

Catalogue the requests worth automating, fulfil the safe ones end to end, and route the rest with everything already gathered. The prompts that build it.

IT and security

How to build incident to resolution

Declare fast, assemble the channel and the timeline automatically, keep customers informed on a cadence, and make the postmortem unavoidable. The prompts.

IT and security

How to build self-service password reset

Let people reset a password or clear a lockout from Slack or Teams, with the identity check that makes it safe and a record IT can audit. The prompts that build it.

Last reviewed October 2026.