One of the most common dysfunctions in support operations is tickets going to the wrong team. A billing question lands in a tier-2 engineering queue because the keyword "API" appeared in the message. A routine password reset gets flagged as high-priority because the customer marked it "urgent." A product complaint in Spanish sits unassigned because no Spanish-speaker is in the default queue.
Routing logic is the system that decides, for each incoming ticket, where it goes and who handles it. Get it right and agents handle tickets they're equipped for, response times drop, and customers stop re-submitting because their first contact went nowhere. Get it wrong and you're managing a permanent triage backlog on top of your actual support workload.
This article explains how routing decisions are structured in Queryvine and why the logic is multidimensional rather than keyword-based.
The Routing Matrix: What It Is and How It's Structured
The routing matrix is a configuration layer that maps ticket characteristics to routing destinations. It's not a neural network — it's deterministic logic that runs after the ML classification steps (language detection, intent classification, sentiment scoring) have produced structured outputs.
The matrix has two types of entries: auto-resolve rules and escalation rules.
Auto-resolve rules specify: for this intent category, at this confidence level, with these account conditions, send this template response and close the ticket. These are the cases where no human needs to be involved.
Escalation rules specify: for this intent category, at this confidence level, with these conditions, route to this queue or this agent group, with this priority level and this context summary attached.
The matrix is evaluated in priority order. Higher-priority rules are checked first, lower-priority rules are fallbacks. A ticket that matches a high-priority escalation rule (e.g., "any ticket with 'cancel account' intent and account tier = Enterprise") gets routed per that rule even if it would also match a lower-priority auto-resolve rule for the same intent category at standard account tier.
The Five Routing Dimensions
Routing decisions in Queryvine draw on five independent dimensions. Each can narrow or redirect the routing destination independently.
Intent category: the primary classification output. Billing/plan-mismatch, auth/login-failure, product/feature-request — these are the first filter. Each intent category has a default routing destination in the matrix.
Language and dialect: language determines which agent pools are eligible to handle the ticket. A French ticket can only route to agents with French language coverage. If no French-capable agent is available in the immediate queue, the routing system either holds the ticket until one is available or escalates to a cross-functional queue that covers language gaps — depending on how the customer's SLA tier is configured.
Confidence score: the model's confidence in its intent classification. High-confidence classifications follow their default routing destination. Low-confidence classifications (say, 0.65–0.80) may route to a human review queue rather than auto-resolving, even for intent categories that would normally auto-resolve at higher confidence.
Customer account attributes: plan tier, account age, payment history, prior escalation history. These modify routing decisions without changing the intent classification. A billing dispute from a month-old account at standard tier routes differently than a billing dispute from a two-year account at the highest plan tier. The intent is the same; the routing is different because the relationship stakes are different.
Operational state signals: queue depth, agent availability, time of day, active incidents. These dynamic signals adjust routing in real time. If your billing queue has a 4-hour backlog, tickets that would normally route there might temporarily redirect to a general queue with a priority flag. If it's 2 AM and no billing specialists are online, billing disputes above a certain dollar threshold may trigger an out-of-hours escalation protocol.
Why Keyword Routing Fails
The predecessor to intent-based routing is keyword routing: if the ticket contains "API," send to engineering; if it contains "invoice," send to billing; if it contains "refund," send to billing with high priority. Many helpdesk platforms offer this natively.
Keyword routing fails because keywords are present in many contexts that don't match their typical intent. "API" appears in billing tickets when a customer is asking why their API usage is showing on an invoice unexpectedly — that's a billing question that needs billing team knowledge, not API engineering expertise. "Refund" appears in tickets where the customer is confirming a refund they already received — that's a low-priority informational confirmation, not a refund request.
Intent classification at the semantic level fixes this. The model reads the full ticket content and infers the underlying request, not just which words appear. "I can see my API usage on my invoice but the amount doesn't match what I was quoted" classifies to billing/invoice-discrepancy, not to engineering/api-support. The word "API" doesn't determine the routing — the intent does.
Language × Queue Depth: The Hard Scheduling Problem
The intersection of language routing and real-time queue management is where routing logic gets genuinely complex. Consider a team handling support across four languages with agent coverage that isn't uniform:
It's 10 AM Tuesday. The English queue has 45 tickets and 6 agents available. The Spanish queue has 82 tickets and 3 agents available. The Japanese queue has 12 tickets and 1 agent available. A Japanese-language billing dispute arrives at high priority.
Simple language routing sends that Japanese ticket to the Japanese queue. But the single available Japanese agent is already handling a high-priority account access case. The billing dispute will wait behind that case and whatever else is in the queue.
A more sophisticated routing system can consider whether there are agents in the general queue who have Japanese as a secondary language skill, even if it's not their primary queue assignment. It can flag the billing dispute for expedited handling once the current case resolves. It can trigger an SLA alert if wait time exceeds a threshold.
We don't want to oversell the sophistication here — this is essentially a scheduling optimization problem with multiple constraints, and the right solution depends on your team structure, SLA tiers, and what "fair" looks like for customers in different language segments. The point is that language routing is not just a first-hop filter; it interacts with the whole queue management system in ways that matter for service equity across language groups.
Building and Maintaining the Matrix
The routing matrix is configured by your CX ops team during onboarding and requires ongoing maintenance. New product features create new intent categories that need routing rules. Team restructuring changes which queues exist and which agents cover which languages. Policy changes affect which ticket types get escalated versus auto-resolved.
The practical cadence we've seen work: a full matrix review quarterly, with ad-hoc updates triggered by specific events. A quarterly review catches intent categories whose routing rules no longer fit current team structure. Ad-hoc updates catch the immediate effects of a product launch or a billing system change that suddenly generates a new ticket type your current matrix doesn't handle well.
The signal that a routing rule needs attention is consistently high follow-up rates for a specific ticket category — tickets that route one place, get handled, and then generate a second ticket from the same customer. That pattern usually means either the routing destination was wrong (the wrong team handled it) or the auto-resolve template was wrong (the customer got a bad answer). Distinguishing between these two causes is a key part of the maintenance process.
One Pattern Worth Calling Out
The most common routing problem we see in teams that are new to intent-based routing is over-investing in the ML classification layer and under-investing in the routing matrix configuration. A highly accurate intent classifier routing to a poorly-configured matrix still produces bad ticket distribution. The classifier tells you what the ticket is — the matrix is what decides what to do with it.
Both need to be right. Classification accuracy without thoughtful routing rules means accurate labels on misrouted tickets. The whole value of knowing what a ticket is about comes from using that knowledge to send it to the right place, at the right priority, with the right context for whoever picks it up.