Skip to content

Helpdesk Ticket Triage Router

Example prompt: "Whenever a new ticket comes into our Zendesk helpdesk, work out what it's about, set the priority, route it to the right team, and send the requester a short acknowledgement so they know we've picked it up."

The Problem

Most internal IT helpdesks land somewhere between 30 and 150 tickets a day, and the first person to read each one decides where it goes. In practice that triage is done in chunks — first thing in the morning, after lunch, before they leave — and tickets sit in the unassigned queue for an hour or two while the requester wonders whether anyone is even looking. The pattern repeats: a password reset that is two clicks of self-service sits behind a printer driver issue, a Wi-Fi outage report from one floor sits behind a laptop swap that could have been booked in a Monday batch, and somebody escalates because nobody answered.

How GloriaMundo Solves It

We build a workflow triggered by a new ticket landing in Zendesk. An LLM step reads the subject and body and classifies the ticket by category — access, hardware, software, network, security, or other — and by urgency. A conditional step routes the ticket: access requests go to the IT-access queue, hardware faults go to the desktop team, network issues page the on-call, security concerns go to the security inbox, and anything ambiguous stays unassigned for a human triage. An integration step sets the Zendesk fields — assignee group, priority, tags — and drafts a short acknowledgement to the requester that names the team picking it up and gives a realistic first-response window for that category. The acknowledgement is sent automatically because the only thing it commits to is "we have read this"; the actual diagnostic reply still comes from the person who picks the ticket up. Glass Box preview shows the classification, the routing decision, and the acknowledgement text before the workflow is approved.

Example Workflow Steps

  1. Trigger (webhook): Fires when a new ticket is created in Zendesk.
  2. Step 1 (LLM): Read the ticket subject and body, classify it by category (access, hardware, software, network, security, other) and by urgency (low, normal, high, urgent).
  3. Step 2 (conditional): Route by category — access to the IT-access group, hardware to desktop, network to on-call, security to the security inbox, ambiguous cases stay unassigned.
  4. Step 3 (integration): Update the Zendesk ticket — set assignee group, priority, and the category tag.
  5. Step 4 (LLM): Draft a short acknowledgement to the requester naming the team picking it up and a realistic first-response window for that category.
  6. Step 5 (integration): Post the acknowledgement as the first reply on the ticket.
  7. Step 6 (integration): For urgent network and security tickets, also post a one-line alert in the #it-oncall channel on Slack so the on-call sees it without having to refresh Zendesk.

Integrations Used

  • Zendesk — the source of the ticket and where the routing, priority, and acknowledgement are written back
  • Slack — the on-call channel for urgent network and security tickets

Who This Is For

Internal IT teams running an employee helpdesk on Zendesk, Jira Service Management, or a similar tool, where the volume is high enough that human triage on every ticket adds a real delay but low enough that a dedicated 24/7 triage rota is not justified.

Time & Cost Saved

A first-line technician triaging tickets typically spends 60-90 seconds per ticket to read, categorise, route, and acknowledge. For a 60-ticket-a-day helpdesk that is 60-90 minutes of triage daily, plus the cost of tickets that sit in the unassigned queue when the technician is in a meeting. This workflow does the categorisation and routing in seconds and the first response goes out immediately; the technician's time goes into the cases the classifier flagged as ambiguous or to the actual diagnostic work.