How to Route Support Tickets Automatically Based on Intent
Stop manually sorting tickets. Set up intent-based routing so the right person sees the right message every time.
The Problem With Manual Triage
In a manual support system, someone reads every incoming message and decides where it goes. Bug report? Forward to engineering. Billing question? Handle it yourself. Feature request? Add it to the backlog. Refund request? Forward to the person who handles refunds.
This works when you get 5 messages per day. At 20 per day, it is a part-time job. At 50 per day, it is a full-time job. And the person doing it adds no value; they are just a human router.
Intent-Based Routing
Intent-based routing automates the decision of "who should handle this?" by classifying every message by what the customer wants.
The flow:
1. Customer sends a message 2. Classification model identifies the intent (e.g., bug_report, refund_request, pricing_inquiry) 3. Routing rules match the intent to an action 4. The action fires automatically (send to Slack channel, create ticket, auto-reply)
No human in the routing loop. The first person to see the message is the person who should handle it.
Setting Up Your Routes
Start by listing your intents and their destinations:
Then create a rule for each:
Each rule has four parts:
1. Trigger: Which intent activates this rule 2. Confidence threshold: Minimum confidence to fire (default: 80%) 3. Action: What to do (auto-reply, create ticket, notify, etc.) 4. Escalation: What happens if confidence is below the threshold
Confidence Thresholds: Where to Set Them
The confidence threshold is the single most important setting in your routing system. It determines how aggressive your automation is.
Conservative (90%+): Only auto-act when the model is very confident. More messages go to human review. Lower risk of wrong actions. Good for starting out.
Balanced (80%): The default. Works well for most intents. Roughly 70% of messages will be auto-routed, 30% will need human review.
Aggressive (70%): More automation, more risk. Good for low-stakes intents like feature requests where a misroute is not a big deal. Not recommended for billing or account actions.
Per-intent thresholds: The best approach. Set high thresholds (90%) for actions with consequences (refunds, account deletion) and lower thresholds (75%) for informational auto-replies (pricing, FAQ links).
Handling Multi-Intent Messages
Sometimes a customer asks two things at once: "I need a refund and also my password is not working."
The classifier picks the primary intent based on what seems most important. In this case, it would likely classify as refund_request since that is the more actionable item.
For these cases, your routing rule can handle the primary intent while a human reviews the full message for secondary issues. The auto-reply addresses the refund; the human follows up about the password.
Routing to External Tools
The real power of intent-based routing is connecting to the tools your team already uses:
Slack: Post to specific channels so the right team sees the message GitHub/Linear/Jira: Create issues or tasks directly from bug reports and feature requests Email: Send auto-replies or internal notifications Zendesk/Intercom: Create tickets if you use those as your primary help desk Webhooks: Connect to any tool with an API
Each integration takes 2 to 5 minutes to configure. The setup is one-time; the routing runs forever after.
Measuring Success
After running intent-based routing for a week, check:
1. Automation rate: What percentage of messages were auto-routed vs needing human triage? 2. Accuracy: Review a sample of auto-routed messages. Were they sent to the right place? 3. Response time: How fast are auto-routed messages getting addressed compared to before? 4. Escalation rate: What percentage of messages fall below confidence thresholds?
If your automation rate is above 60% and accuracy is above 90%, your routing is working well.