Sort every incoming ticket before a person reads the first one

Route every support ticket by type and urgency the moment it arrives, so outages surface before password resets.

For anyone whose queue is a single undifferentiated list · 8 steps · 7 min

How it works today.

Every ticket lands in a single shared inbox in the order customers sent them. You open the first unread message, discover it is a billing question, handle it, then open the next and find an outage report that arrived thirty seconds earlier. The customer experiencing downtime has already been waiting behind three low-priority requests.

You spend the first hour of every shift reading subject lines and mentally sorting: urgent, routine, can wait. By the time you have identified the fires, you have already opened a dozen tickets that could have been batched or handled later. There is no view that shows you critical issues first, so you build that view in your head every single day.

Before you start.

All of it has to be true, or step one fails in a way that is annoying to debug.

Admin access to your support platform with permission to create views, tags, or priority fields.
API access or webhook capability in your ticketing system so an agent can read new tickets as they arrive.
A list of the ticket types you see most often, with a clear definition of what makes something urgent versus routine.
Write access for the agent to apply labels, set priority, or move tickets between views without closing them.

The steps.

Export two weeks of closed tickets with subject, body and resolution time
Pull a CSV or JSON export from your support platform that includes at minimum the ticket subject, the first message body, any tags you applied manually, and time to close. You need enough examples that the agent can learn the difference between a password reset and a data breach. If your platform has a ticket type or category field, include that column.

Write down what makes a ticket urgent in your world

List the scenarios that must surface immediately: service outages, security issues, payment failures blocking access, anything that stops a customer working. Write the opposite list as well—requests that are important but can wait six hours, like feature questions or feedback. These definitions will go directly into the classification prompt, so be specific about keywords or patterns that signal urgency.

Paste this

You are triaging incoming support tickets. Your job is to read the subject and body, then assign two labels: type and urgency.

Urgent tickets:
- [describe outage patterns, e.g. "customer reports they cannot log in and error messages mention server or database"]
- [describe security patterns]
- [describe payment or access blocking issues]

Routine tickets:
- [describe password resets, how-to questions, feature requests]

For each ticket, return JSON with this shape:
{
  "type": "outage" | "billing" | "access" | "question" | "feature-request" | "unknown",
  "urgency": "urgent" | "routine" | "low",
  "reasoning": "one sentence explaining why you chose these labels"
}

If you cannot confidently classify the ticket, set type to "unknown" and urgency to "routine" so a human reviews it.

Create the views or labels the agent will write to
In your support platform, create a tag or label for each ticket type you defined, and create a priority field or tag for urgent versus routine. If your platform uses views, create one view filtered to urgent tickets and another for each type. The agent will need the exact API name or ID of these labels, so note them down as you create them.
Connect the agent to your support platform and give it read and tag permissions
Use a builder or vertical agent that offers a pre-built connector to your ticketing system. Authenticate the connection and confirm the agent can read new tickets and write labels or priority values. Test that it cannot close, reassign, or reply to tickets—it should only be able to read and tag. If the connector does not exist, check whether your platform exposes webhooks for new tickets and whether the agent can call your API to apply labels.
Set the trigger to run when a new ticket arrives
Configure the agent to fire every time a ticket is created, or poll the untagged ticket view every two minutes if your platform does not support webhooks. The agent reads the subject and body, sends them to the classification prompt, receives the type and urgency, then writes those labels to the ticket. If the agent returns "unknown" for type, it should apply a label like "needs-human-triage" instead of guessing.
Run the agent against ten recent tickets and check the labels it applied
Manually trigger the agent on a sample of closed tickets where you already know the correct type and urgency. Compare what the agent labeled against what you would have chosen. If it misclassifies a billing question as urgent, or marks an outage as routine, revise the definitions in the classification prompt and test again. Do not move to live tickets until the agent agrees with you on at least nine out of ten.
Turn on the trigger for all new tickets and monitor the first fifty
Let the agent tag every incoming ticket for one business day. Check the urgent view hourly to confirm real outages are surfacing, and check the unknown bucket to see what the agent could not classify. If more than ten percent land in unknown, your type definitions may be too narrow or your ticket language too varied. Refine the prompt with examples from the unknown bucket.
Build a dashboard or view that shows you urgent-first, then type-grouped
Create a saved view or report in your support platform that sorts by urgency descending, then groups by type. This becomes the view you open every morning. Urgent tickets appear at the top regardless of arrival time, and routine tickets are batched by type so you can answer five billing questions in a row instead of context-switching. If your platform does not support grouped views, export the tagged ticket list to a spreadsheet and sort it there until you have a better tool.

What you keep.

Automating the typing does not move the accountability. These stay with a person.

Reviewing every ticket the agent marked as unknown and deciding whether to expand the type list or refine the definitions.
Checking the urgent queue within the SLA window you promise customers, because the agent only sorts—it does not reply or escalate.
Deciding when a ticket type has grown large enough to deserve its own workflow or macro, and writing that macro yourself.
Approving any change to what the agent considers urgent, because mislabeling an outage as routine breaks customer trust.

Once it works.

The first run is the demo. These are where the time actually comes back.

Run it on a loop

Every Friday, export the tickets the agent marked as unknown that week and add the three most common patterns to the classification prompt so fewer reach the unknown bucket.

Fire it from an event

When the agent labels a ticket as urgent, trigger a second automation that posts the ticket link to a dedicated Slack channel so the on-call person sees it without polling the queue.

Hand off to another agent

Once ticket types are stable, hand the routine password-reset tickets to a second agent that auto-replies with the reset link and closes the ticket if the customer does not respond in ten minutes.

Scale it wider

If you support multiple products, add a product label to the classification prompt and create per-product views so specialists see only the tickets they can answer.