Every morning at my last company, I'd sit down, open the helpdesk queue, and spend the first 20–30 minutes triaging overnight tickets. Category. Priority. SLA. Assign to the right person. Write a one-line note for the technician. Repeat.
It wasn't hard work. It was just slow, manual, and prone to inconsistency, especially on Mondays after a long weekend, or at 4pm when my brain had already checked out. A P2 that should have been a P1 is an SLA breach. A P4 that got routed to the wrong team sits in the wrong queue for days.
At roughly 5,000 tickets per year across a 900-person org, even 2 minutes per triage decision adds up to 166 hours a year. That's a month of Fridays.
The Tool
The IT Helpdesk Triage Agent is a Streamlit app that takes a batch of raw ticket descriptions, sends them to Claude in a single API call, and returns structured triage output for each one:
- Category (hardware / software / access / onboarding / etc.)
- Priority (P1–P4 with the reasoning)
- SLA (hours to resolution based on priority and category)
- Owner (which team or individual gets it)
- Suggested action (first thing the technician should try)
- Auto-resolve flag (should this go straight to a knowledge base article with no human touch?)
Thirty tickets in about 5 seconds. One API call, structured JSON back, parsed into a clean table.
What I Actually Learned Building This
The hard part wasn't the code. It was the prompt.
First version: I asked Claude to "triage these IT support tickets and assign priority P1–P4." Got wildly inconsistent results. Some P1s were actually "I can't remember my password" and some P4s were production outages.
The fix was giving Claude the same triage rubric my team actually used, specifically the internal escalation guide I'd written for new hires. Once that was in the system prompt, the priority logic snapped into place immediately. Claude wasn't guessing; it was applying the same rules we'd always used.
The second insight: auto-resolve flagging. We'd never thought to explicitly define what "auto-resolvable" meant. Building this forced me to write it out: if the ticket matches a known KB article, if it's a password reset, if it's a how-do-I question with a documented answer: auto-resolve. That definition, once written, made the tool dramatically more useful because it surfaced the tickets that never needed a human at all.
About 15–20% of our ticket volume was genuinely auto-resolvable. We just never had time to notice.
The Number That Mattered
When I ran a backtest against three months of historical tickets, the tool agreed with human triage decisions on priority 87% of the time. The 13% disagreement wasn't random; it clustered around two patterns: tickets where the user described symptoms vaguely, and tickets involving unusual edge-case hardware configurations.
Both of those are actually useful signals. The vague-description tickets often needed a follow-up question before triage, which the tool flagged. The hardware edge cases needed human judgment, which the auto-resolve flag correctly didn't set.
87% agreement on a batch tool running in 5 seconds is extremely useful. You don't need 100%; you need to reduce the cognitive load on the human who reviews the output.
What I'd Add Next
The version I shipped was intentionally minimal. If I were building this for production deployment in a larger org, the next layer would be:
Feedback loop. When a technician overrides a priority or routing decision, that correction gets logged. After enough corrections cluster around a pattern, the system prompt gets updated. Self-improving triage.
Ticket aging. Priority should escalate the longer a ticket sits. A P3 that's been open for 72 hours without response should automatically surface for review, not stay buried in the queue.
Integrations. The current version is standalone. The real version pushes directly into ServiceNow or Jira, with no copy-paste.
If you manage a helpdesk and want to try it, the live demo is on my portfolio. You can paste in your own ticket descriptions and see how it triages them. No data is stored.
The thing I'd tell any IT manager who's skeptical: run it in parallel with your existing process for two weeks. Log where it agrees and disagrees. The disagreements will teach you something about your own triage logic.