When teams first explore multilingual support automation, the obvious question is: why not just send every ticket to a large language model and ask it to reply in the customer's language? GPT-4, Claude, Gemini — they all handle multiple languages fluently. They can detect language, understand intent, and generate coherent responses across dozens of tongues. Why build anything more complicated?
We spent a lot of time thinking through exactly this question when we were architecting Queryvine. The answer is nuanced, and I want to explain it honestly — because it's not that LLMs are bad at multilingual tasks. It's that the failure modes of a generic LLM routing system are different from what most teams expect, and they tend to appear at the worst possible moments.
The Latency Problem at Real Queue Volumes
At 100 tickets per day, calling a hosted LLM for every ticket is completely workable. The response time is acceptable, the cost is negligible, and the flexibility is useful.
At 10,000 tickets per day — which is roughly 7 tickets per minute across a 24-hour period — you're making 10,000 synchronous API calls to an external service. A few things start to matter: average response latency (typically 1–4 seconds per call for a hosted frontier model at standard tier), rate limits, cost per 1K tokens multiplied across volume, and the cascading effect of any API slowdown on your queue SLAs.
More critically: queues don't arrive uniformly. If you handle e-commerce support, ticket volume on a Monday morning might be 3x the daily average because of weekend purchases and returns. Your worst-case latency scenario hits exactly when your queue is longest and your customers are most impatient.
This is why we run intent classification locally rather than via a hosted model API. The classification model is smaller, faster, and purpose-built — it doesn't need to generate text, just return a structured classification label. P95 latency for our classifier is under 150ms per ticket. The tradeoff is that it requires training data and a deployment pipeline per-language, which is real engineering work, but the performance ceiling is orders of magnitude higher than API-dependent routing.
Why "Translate, Then Classify in English" Breaks Under Dialect Variance
A common architecture pattern is: detect language, translate everything to English, classify in English, respond in English, then translate the response back to the customer's language. It sounds elegant. It avoids building per-language classifiers. It works reasonably well in demos.
The problem is translation quality variance across languages and registers. High-resource languages like Spanish, French, and German translate cleanly to English. Lower-resource languages or informal registers in higher-resource languages translate with more errors — and those translation errors compound in the classification step.
Consider a ticket written in Bengali code-switching with English (common among tech-literate customers in Bangladesh and West Bengal): "Dashboard e problem hocche, plan upgrade korar por bhi old features show korche." A translation model might render this as "Dashboard having problem, after plan upgrade old features still showing" — grammatically unusual English that a general-purpose classifier handles less reliably than a purpose-trained Bengali classifier would handle the original.
The translate-first approach also means two points of failure instead of one. If the translation is wrong, the classification is wrong. If the classification is wrong, the response is wrong. Error chains are harder to debug than single-point failures.
Intent Taxonomy Portability Across Languages
One thing we got right early: the intent taxonomy is defined once and shared across all language classifiers. We don't have a "billing questions" class for English and a different "billing queries" class for French. There is one intent class — billing/plan-mismatch — and classifiers in all 35 languages are trained to predict membership in that same class.
This sounds obvious, but it requires discipline during taxonomy development. The temptation is to let the taxonomy drift by language — to add language-specific intent nodes that don't exist in the core taxonomy because they come up frequently in that language's tickets. That drift, once it starts, creates routing inconsistencies that are hard to audit and harder to fix.
The practical rule we follow: if an intent type needs to exist, it exists for all languages or none. If a concept only surfaces in tickets from one language region, that's a signal to look at whether it's actually a regional product issue or a regional phrasing variant of an existing intent class — not a reason to add a language-specific node.
Where Generic LLMs Actually Outperform Purpose-Built Classifiers
To be direct about the tradeoffs: generic LLMs outperform purpose-built classifiers in several real scenarios.
For newly added languages where you have minimal training data — say, you're adding Tagalog support and have fewer than 500 labeled examples — a zero-shot or few-shot LLM classification will often outperform a fine-tuned model trained on too little data. The fine-tuned model needs enough examples to generalize; below that threshold, it can overfit to surface patterns rather than semantic intent.
For novel intent types — a new product feature launches and generates ticket categories that didn't exist during training — a well-prompted LLM adapts immediately. A fine-tuned classifier needs a retraining cycle that might take days or weeks depending on your pipeline.
For complex, multi-intent tickets — a customer who has a billing question and a feature complaint and an account access problem in a single message — a generative model handles the decomposition more gracefully than a single-label classifier.
Our approach is to use the classifier for the steady-state volume of well-understood intents, and to route low-confidence classifications and novel intents through an LLM fallback layer. This isn't "LLM bad, classifier good" — it's "use the right tool at each node of the pipeline."
The Routing Decision Layer
Classification is only one half of routing. After you know what the ticket is about and what language it's in, you need to decide where it goes: auto-resolve, agent queue, specific team, specific agent.
This decision layer is deterministic logic, not ML. It's a routing matrix that your CX ops team configures: billing tickets above 0.85 confidence auto-resolve; billing tickets between 0.65 and 0.85 go to agent review with the draft response pre-filled; billing tickets involving a disputed charge always escalate to billing specialists regardless of confidence score.
Language feeds into routing in a non-obvious way. If you have a Spanish-speaking agent available, Spanish tickets with confidence scores just below the auto-resolve threshold might route differently than Arabic tickets where you don't have a native-speaker agent on shift. The routing matrix has to account for agent language coverage, not just ticket intent.
When we say "language routing at scale," this is really what we mean: not just detecting what language a ticket is in, but using that information as a first-class routing dimension alongside intent, sentiment, customer tier, and agent availability. The language dimension changes the routing calculation at multiple points, and any system that only applies it at the detection stage is leaving routing efficiency on the table.
What the Architecture Looks Like in Practice
The pipeline we run for a team handling 35 languages looks like this: language detection (local model, <50ms) → entity extraction (concurrent with intent classification) → intent classification (local model, <150ms) → account state lookup (external call, 100–300ms) → routing decision (deterministic, <10ms) → resolution path (template instantiation or LLM fallback or human queue). Total P95 end-to-end under 800ms for auto-resolve paths.
The architecture is not simpler than "send everything to GPT-4." It requires per-language training data, a continuous labeling operation to keep classifiers current, a fallback pathway, and a routing matrix that someone has to maintain. But it's the architecture that holds up when the Tuesday morning queue spikes and your customers in twelve time zones are all waiting for responses at the same time.