What this automation does
Every ticket gets the same first look within seconds of arriving, so the first human to touch it is the right one.
- Trigger. A helpdesk webhook fires when a ticket is created. In Zendesk this is a trigger with a webhook action, in Freshdesk an automation rule, in Help Scout a webhook on conversation created.
- Fetch context. The workflow pulls the ticket subject, first message, channel and requester, then looks up the requester’s organization, plan tier and any open incidents.
- Classify. A small model returns JSON with
category,product_area,language,sentiment,suggested_priority,confidenceand a one-sentencereason, chosen only from the lists you defined. - Validate. Code rejects any value not on the allowed list and combines the model’s suggested priority with plan tier and incident status to produce the final priority.
- Write back. The workflow sets custom fields and tags on the ticket, including an
ai_triagedtag, and your helpdesk’s own routing rules assign the group. - Escalate. Tickets classified as urgent, or from top-tier accounts with negative sentiment, also post to a Slack channel with a link.
When it is worth building
Triage is worth automating when tickets routinely sit in a general queue before someone sorts them, or when your specialists spend time bouncing tickets back. If your team reassigns a meaningful share of tickets after first assignment, that rework is the cost this removes.
It is not worth it if you have one queue and everyone handles everything. In that case, spend the effort on drafting replies instead. And if your tickets arrive in a shared Gmail or Outlook mailbox rather than a helpdesk, start with shared inbox triage, which has different mechanics.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Trigger | Helpdesk webhook on ticket created | Classifies before any agent opens the ticket, with no polling delay |
| Orchestration | n8n | Built-in nodes for Zendesk, Freshdesk and Help Scout, plus Slack for alerts |
| Classifier | Claude Haiku 5.5 or a small OpenAI GPT model with structured output | Classification is short and frequent, so speed and per-call cost matter more than depth |
| Taxonomy | A Google Sheet of categories, definitions and target groups | Support leads can edit categories without touching the workflow |
| Rules | Code step in n8n | Allowed-value checks and the priority formula are deterministic |
| Routing | Your helpdesk’s existing triggers and groups | Keeps assignment logic visible and editable in the tool your team already manages |
| Audit | A log row per ticket with input, output and final values | Lets you measure agreement with humans and spot drift |
How to build it
- Export 500 recent tickets with their final category and group. These are your ground truth. Clean obvious mislabels before using them.
- Write the taxonomy. One line per category saying what belongs there and one example of what does not. Store it in a sheet the workflow reads at run time.
- Create the custom fields and tags in the helpdesk: category, product area, language, AI confidence, and the
ai_triagedtag. - Build the classifier prompt with the taxonomy injected. Ask for structured JSON and a short reason. Include two or three tricky examples from your export.
- Test offline against the 500 tickets. Measure how often the model’s category matches the human one, per category. Rewrite definitions for the categories that are confused with each other.
- Wire the webhook and add the loop guard. The helpdesk trigger must exclude tickets already tagged
ai_triaged, or the field update will fire the webhook again. - Run in suggest-only mode for a week. Write the AI’s choice to a separate field while humans route as usual, then compare.
- Switch routing to the AI field for categories with high agreement, and keep the rest in the general queue until their definitions improve.
The downloadable starter template below covers the webhook, classification, validation and write-back for Zendesk.
What breaks in production
- Webhook loops. Updating a ticket fires “ticket updated” triggers. Without the
ai_triagedexclusion, a ticket can be classified repeatedly and run up model costs. - Overwriting human decisions. If an agent has already reassigned a ticket, a slow workflow should not move it back. Check the ticket’s assignee and update timestamp before writing.
- Taxonomy drift. A new product launches and tickets about it get forced into the nearest old category. Review the low-confidence queue weekly, because that is where new categories show up first.
- Sentiment is not urgency. An angry customer asking about a feature request is not a P1. A calm customer reporting that checkout is down is. Keep the priority formula grounded in account data and incident flags.
- Multi-issue tickets. Classify by the issue that needs the most specialized team, and add a secondary category tag rather than splitting the ticket automatically.
- Forwarded email chains. The first message is a long forwarded thread, and the model classifies the oldest message instead of the newest. Strip quoted text before classifying.
Timeline and cost
One helpdesk, one brand and a taxonomy of up to twenty categories typically takes one to three weeks. Lumeor builds ticket triage in the range of $4,000 to $10,000. The upper end covers multiple brands or helpdesks, CRM lookups for account tier, and a reporting view of AI versus human agreement. Model costs are small because each classification is a short prompt and response, and we estimate them from your monthly ticket count during scoping.
How to measure success
- Reassignment rate: share of tickets moved to another group after first assignment, before and after
- Time to first assignment, especially for tickets that used to land in a general queue
- Agreement with human labels, measured weekly on a random sample of 50 tickets
- First response time for urgent tickets, since faster urgent routing is usually the clearest win
- Low-confidence share, which should shrink as definitions improve and is your early warning for new issue types