Most engineering teams I work with don't think they have a triage problem. They have someone — usually a senior IT person or an engineering manager — who spends part of their day looking at the incoming ticket queue and deciding who should handle each one. It doesn't feel like a problem because it's always been that way.
But when you calculate what it actually costs, teams consistently find the number is 3–5× higher than their gut estimate.
The Triage Tax: A Simple Calculation
Manual triage has three cost components that most teams only count one of:
1. The direct time cost
Take your average ticket volume per week. For a 50-person company, this is typically 80–150 tickets per week across IT, dev tools, and HR systems. Each ticket needs someone to read it, decide its category, and reassign it. That's 2–5 minutes per ticket.
Quick calculation for your team:
Weekly tickets × 3 min average × hourly rate of the person triaging
Example: 120 tickets/week × 3 min × €80/hr = €480/week = €25K/year
And that assumes the triager is an IT technician, not an engineering manager.
2. The delay cost
Triage introduces a queue. Tickets don't get routed instantly — they wait for the triager to have a window. In most teams without automation, this adds 45–90 minutes to the clock before work even starts.
For tickets with an SLA of 4 hours, that's 20–40% of the SLA window consumed before anyone has looked at the actual problem.
3. The context-switch cost
Whoever does triage isn't doing only triage. They're context-switching from deep work (code review, incident response, architecture decisions) to shallow work (reading a ticket about a missing laptop charger) and back. Research consistently puts the cost of a context switch at 15–20 minutes of recovery time.
At 20 triage decisions per day, that's up to 400 minutes of lost focus time — per day.
Why Teams Accept It
Three reasons come up every time:
- "We tried Jira automation and it didn't work." Usually because the rules were too broad ("if summary contains 'laptop' → assign to IT") and broke constantly as language varied. The fix is AI classification, not keyword matching.
- "Our tickets are too varied to automate." In practice, 90%+ of tickets at 20–200 person companies fall into 4–6 categories. The long tail is real but small.
- "We don't have the engineering time to build it." This one is fair — but the build time is shorter than most expect, and the payback period is measured in weeks, not quarters.
Three Steps to Eliminate Manual Triage
Step 1: Enforce a submission template
The most valuable thing you can do before any automation is require a structured submission. If tickets come in as free-text Slack messages or vague one-liners, classification accuracy drops significantly — for both humans and AI.
A Jira intake form or a Slack modal with two required fields (summary + one-sentence description) is enough. This single change typically improves classification accuracy by 8–12 percentage points.
Step 2: Add an AI classification layer
A small language model (GPT-4o-mini, Claude Haiku, or a fine-tuned local model) reads the summary and description and outputs a category. At scale, this costs less than €5/month in API fees for a team handling a few hundred tickets per week.
The classifier doesn't replace Jira routing rules — it feeds them. It sets a custom field on the ticket, and a Jira automation rule reacts to that field. This keeps routing logic in Jira where non-engineers can modify it without a code deploy.
categories = ["IT_HARDWARE", "SOFTWARE_ACCESS", "DEV_TOOLS", "HR_SYSTEMS"] # Accuracy benchmark across typical office support vocabulary: # keyword-matching rules: ~72% # AI classifier (no fine-tuning): ~91% # AI classifier + structured template: ~96%
Step 3: Close the loop with Slack confirmations
The reason people follow up in Slack ("any update on my ticket?") is because submitting a ticket feels like sending a message into a void. A DM confirmation — "your ticket IT-1234 has been assigned to the IT team, expected response within 4 hours" — eliminates most of this informal queue.
Teams that add this step typically see a 70–80% reduction in unsolicited follow-ups. That's not just noise reduction — it's real time returned to the IT person who was being pinged.
What This Costs to Build
For a team already using Jira and Slack, the full implementation — template, classifier, routing rules, confirmation DMs — takes 2–3 weeks. Hosting runs on a small server instance for €5–10/month. The classifier API fees are negligible at typical office support volumes.
The payback calculation is straightforward: if triage is consuming €25K of engineering time per year, a project that costs €8–12K to build pays for itself in under six months — and keeps paying every year after.
The harder question isn't whether the ROI is there. It usually is. The harder question is finding three weeks when no one needs to context-switch to build the thing that eliminates context-switching.
