A support ticket arrives at 2:17 AM. The sender is a customer in Recife, Brazil, writing in Brazilian Portuguese. She bought a subscription last week and can't figure out why her account dashboard shows a different plan tier than what she paid for. The message is 94 words, uses informal contractions, and includes one sentence that blends Portuguese and English: "Meu plano aparece como Basic mas eu fiz upgrade para o Pro plan."
Eight seconds later, she receives a resolution in Portuguese explaining that her plan updated correctly but the dashboard cache refreshes every 15 minutes — and inviting her to reload or contact support if the issue persists in an hour.
No human touched that ticket. Here is exactly what happened in those eight seconds.
Step 1: Language Detection (under 50ms)
The first thing any multilingual pipeline must do is establish what language the ticket is in. This sounds trivial until you encounter real-world support traffic. That message from Recife isn't pure Portuguese — it contains "Pro plan" as an untranslated product term. A naive language identifier trained on clean corpora will sometimes misclassify mixed-language tickets, especially when the non-native phrase is technically longer or more prominent than the native portion.
Our language detection layer uses a character n-gram model running locally (not an API call) specifically because latency here compounds across the whole pipeline. The detection returns a confidence score alongside the language code. For that ticket: pt-BR, confidence 0.97. The mixed English product term is handled via an exclusion list of known product vocabulary that gets stripped before scoring.
When confidence falls below a threshold — typically 0.75 — the ticket enters a secondary review pass that looks at header metadata (timezone, sender locale from the account record, previous ticket history) to resolve ambiguity. This matters more than you'd expect in markets like Miami, where a single customer might write tickets in English, Spanish, and Spanglish across different interactions.
Step 2: Intent Classification (100–200ms)
Once we know the language, we classify intent. This is not "summarize what the customer is asking" — it's a structured classification into a taxonomy your team built during onboarding. For a typical SaaS support team, that taxonomy has 30–80 intent nodes: things like billing/plan-mismatch, billing/refund-request, auth/login-failure, feature/missing-from-dashboard, and so on.
The classification runs against a fine-tuned model that learned on your team's historical labeled tickets in that language. For Brazilian Portuguese, the model has seen enough ticket examples to handle informal register, slang, and abbreviated phrasing. The Recife ticket classifies to billing/plan-display-mismatch with confidence 0.91.
What this classification unlocks is the resolution path. Each intent node has one or more associated resolution templates and a policy document describing the correct resolution logic. The system doesn't need to understand Portuguese to resolve a billing question — it needs to correctly identify that this is a billing/plan-display-mismatch, then execute the resolution logic for that intent type.
Step 3: Entity Extraction and Account Lookup (200–400ms)
The resolution logic for billing/plan-display-mismatch requires checking the customer's actual account state. The pipeline extracts relevant entities from the ticket: account identifier (from the sender email), product terms mentioned ("Pro plan"), and any relevant dates or transaction references.
With those entities, the system issues a read-only call to your CRM or billing backend. In this case: confirm the customer's current plan tier, confirm the last plan change event, and retrieve any relevant cache TTL policy for the dashboard.
This is where the "AI" part is actually smaller than people assume. The resolution logic is deterministic once the intent and account state are known. The platform found: plan upgraded to Pro 6 hours ago, dashboard cache TTL is 15 minutes, no payment failure on record. This matches the expected resolution path exactly.
Step 4: Response Generation in Native Language (400–700ms)
The response template for billing/plan-display-mismatch reads: "Your [plan_name] upgrade was processed successfully on [upgrade_date]. The account dashboard refreshes every [cache_ttl_display]. If your dashboard still shows [old_plan] after [resolution_time], please contact us and we'll resolve it directly."
This template is authored and maintained in English (or your primary language), then we maintain parallel versions in all 35 supported languages. The template system is not neural MT at response time — it's localized template instantiation. Named variables are filled from the account lookup data, with locale-appropriate date and time formatting applied.
Why not just translate the generated English response? Translation at response time introduces latency and failure modes. If the translation model renders "Pro plan" as "Plan Profissional" when the customer's dashboard shows "Pro plan" in English, that inconsistency creates confusion. Localized templates with controlled vocabulary avoid this category of problem entirely.
For high-confidence intents with clean account data, this step is where the response is finalized. For tickets that fall outside template coverage — unusual phrasing, escalated sentiment, missing account data — the pipeline exits to human routing instead.
Step 5: Confidence Gating Before Send (700–800ms)
Before any response sends, a final confidence gate evaluates the full resolution chain. This isn't a single score — it's a composite of: language detection confidence, intent classification confidence, entity extraction completeness, account data freshness, and template coverage match.
The gate logic is configurable. A team might set the auto-resolve threshold at 0.85 composite confidence, with everything below going to a human queue with the AI-drafted response pre-filled for agent review. This means the system is never guessing its way through ambiguous tickets — it knows when to stop and hand off.
For the Recife ticket: all five confidence components passed. Response sent at 2:17:08 AM, eight seconds after receipt.
What This Pipeline Doesn't Do Well
We're not saying this approach handles every ticket. The pipeline described above performs well on transactional support: billing questions, account access, plan changes, order status, feature availability. It performs poorly on tickets that require nuanced human judgment: complaints with embedded emotional context, situations where the customer is technically wrong but the business relationship should be preserved, escalations involving regulatory language.
The honest number is that roughly 65–75% of support volume at a typical SaaS company falls into the transactional category. The remaining 25–35% needs a human. The value of this pipeline isn't eliminating human support — it's ensuring humans only see the tickets where their judgment actually matters, while the routine volume resolves without delay regardless of what time zone the customer is writing from.
The Language Question Specifically
The architecture above is language-agnostic in its core logic. Adding a new language to the system means: training or fine-tuning the intent classifier on labeled examples in that language, authoring localized response templates, and validating detection accuracy. It does not mean rebuilding the pipeline or adding a separate routing flow per language.
That's the practical difference between a multilingual-native system and a translated-English system. In the latter, every language is a one-off integration. In the former, the 36th language you add works the same way the first ten did. The marginal cost of language coverage should decrease as the system matures, not increase.
For the customer in Recife, none of this architecture is visible. She got an accurate answer in her language at 2 AM without waiting for a business day to start in a time zone twelve time zones away. That's the outcome the pipeline is designed to produce, consistently, at scale.