🎫 AI Ticket Routing and Sentiment Analysis: How Machine Learning Cuts Customer Support Costs
How intent classification, smart ticket routing, and real-time sentiment analysis let support teams automate routine work, prioritize at-risk customers, and cut costs without losing service quality.
How it Works
Every ticket spawns above the scene and falls to the glowing classifier hub at the centre. There it is scored twice: a confidence score for its intent, and an urgency score built from its sentiment. The urgency check runs first — if a ticket reads as critical (an irate customer, an explicit churn threat) it shoots straight up to the manager node, skipping every queue. Otherwise the confidence gate decides: a high-confidence prediction is handed to whichever support agent currently has the lightest load; a low-confidence one is diverted to human review instead of risking a wrong automated response.
Agents glow brighter as their active load rises and dim as tickets resolve and free up capacity, so the ring visually tracks who is overloaded in real time — exactly the signal a skill-aware routing model uses instead of blind round-robin assignment.
Frequently Asked Questions
What is intent classification in customer support automation?
A transformer model reads a ticket's free text and assigns it to one of 15-20 intents — order status, return request, complaint, and so on — each backed by roughly 500 labeled example phrases, so the downstream system knows what the customer actually wants before deciding how to handle it.
Why does raising the confidence threshold send more tickets to human review?
Every classification carries a confidence score, and the system only automates when that score clears the threshold. Raising θ_conf makes the gate stricter, so a larger share of borderline predictions fall below it and get handed to a person instead of being auto-routed.
How does sentiment-driven urgency scoring work in this simulation?
Each ticket gets a sentiment value; the urgency score blends the negativity of that sentiment with a small random chance of an explicit churn phrase like "switching to a competitor." When the score clears the critical threshold, the ticket is flagged for escalation regardless of how confident the intent classifier is.
Why do critical tickets bypass the agent queue entirely?
The escalation check runs before the confidence gate. Catching a customer's frustration at the moment of expression, rather than after a slow queue, is often the entire difference between a saved account and a lost one, so critical tickets route straight to a manager instead of waiting in line.
How does the simulation decide which agent gets a ticket?
At assignment time every agent is scored, and the ticket goes to whichever agent currently has the lowest active load — a simplified stand-in for a supervised routing model that predicts each agent's probability of successfully resolving that category of ticket.
About this simulation
This simulator runs a live routing pipeline over a stream of synthetic support tickets. Every arrival is scored for urgency and confidence exactly as described in production support-ML stacks: a sentiment-driven escalation check runs first and can send a ticket straight to a manager, and everything else passes through a confidence gate that separates safe automation from cases that need a human. Watch the agent ring brighten under load and the manager node flare on every critical escalation.
🔬 What it shows
A confidence gate separating auto-routed tickets from human review, a sentiment-to-urgency scoring step that runs before that gate, and a least-loaded agent-assignment policy that reacts live to each agent's current queue.
🎮 How to use
Adjust the ticket arrival rate, the confidence threshold, the critical urgency threshold and the number of support agents. Pause freezes the engine; Reset queue clears every in-flight ticket and load counter.
💡Did you know?
Because the escalation check runs before the confidence gate, a ticket can be simultaneously high-confidence and critical — the simulation always sends it to the manager first, mirroring how real support platforms treat an at-risk customer as more urgent than a routine, easily-automated request.
Frequently asked questions
Why does the agent ring glow unevenly even with agents set to the same count?
assignTicket() always picks argmin(currentLoad), so early in a run tickets spread evenly, but resolution durations are randomised — an agent that happens to draw a few long-running tickets in a row stays lit longer than its neighbours, exactly like real handle-time variance.
Why do more tickets go to human review when I raise the confidence threshold?
classify() compares each ticket's randomly-drawn confidence value against θ_conf; raising the slider shrinks the fraction of draws that clear it, so a larger share fall through to the human-review branch instead of the auto-agent branch.
Why does lowering the critical urgency threshold flood the manager node?
computeUrgency() derives a 0-1 score from each ticket's sentiment plus an occasional keyword bump; lowering θ_crit means a lower bar counts as critical, so a wider slice of the same underlying urgency distribution now triggers the manager-escalation branch.
Why does raising the arrival rate not proportionally raise the critical-escalation count?
The escalation share depends only on the urgency distribution and θ_crit, not on volume — spawnTicket() draws sentiment independently of the rate slider, so a higher rate produces more tickets overall but the same roughly-constant fraction of them are critical.
What happens if I add more agents mid-run?
Changing the agent-count slider rebuilds the agent ring and resets every load counter and in-flight ticket, the same way changing the number of skills resets an adaptive-learning curriculum — it is treated as a fresh support team, not a live headcount change.
A live classifier hub routes incoming support tickets: a confidence gate decides automation vs human review, a sentiment-driven urgency score escalates at-risk customers straight to a manager, and the rest are assigned to the least-busy matching agent.
3D · Three.js / WebGL renderer · 60 FPS target · runs fully client-side, no install