In-House, Outsourced or Automated: Choosing Multilingual Support
There are exactly three ways to answer a customer who writes in a language your team does not staff: you automate it, you outsource it, or you hire for it. Every vendor page on this topic will tell you their route is the modern one. The useful thing about a vendor comparison is that it usually tabulates the tradeoffs honestly, even when the conclusion is self-serving. A recent roundup of multilingual support strategies does exactly that, and its summary table is more useful than its recommendations.
The table assigns each strategy a cost profile, a quality profile, and a control profile. AI tooling lands on low cost per resolution with high throughput and no staffing commitment. Global outsourcing partners sit at medium-to-high cost depending on location, and are marked as having limited control over support quality and inconsistent brand tone. An internal multilingual team is marked high cost, with the note that recruiting multilingual talent is difficult and expensive. Read those three rows as a description of where the risk sits in each model rather than as a verdict.
The question that actually decides it
Not which is cheaper and not which is faster. The deciding question is who holds the quality risk when the reply is wrong.
Under an AI route, the risk sits with you, visibly, on every conversation. The customer sees a fluent reply and judges it immediately. There is no intermediary between the error and the brand.
Under an outsourced route, the risk is shared but diffused. The customer experiences the same interface and cannot tell who wrote the reply. That buys you a genuine benefit — you can absorb errors in languages where you have no reviewer — and it costs you the thing that matters most in a chat product: the ability to correct a systematic tone or terminology problem quickly, because the correction has to travel through a partner.
Under an in-house route, the risk is expensive but controllable. You pay for it in salary and recruiting, and you get direct editorial authority over every reply.
Most teams that get this wrong do it by optimising the cost column and discovering the control problem eighteen months later. If you want to see what that control problem looks like in practice, the piece on tone in live translation is about exactly the failure that neither an outsource partner nor a raw engine will fix for you.
The vendor numbers in these pages are not evidence
Strategy roundups are also catalogues of vendor claims, and the claims are specific enough to be worth naming as claims. The page cited here states that one platform resolves queries with up to 99.8% accuracy across more than fifty languages and starts at 1.25 US dollars per resolution. Another, elsewhere in the same category, promises native-level multilingual fluency from an automated agent.
These are marketing positions. They may or may not be true for a narrow definition of resolution. They are not usable in a planning document, and if you put one into a business case, the first serious reviewer will ask what was measured, on which traffic, by whom, and over what period. None of those answers is available publicly.
The defensible version of the same argument is structural: automated handling is the only route whose cost scales with resolution count rather than with headcount, and it is the only route whose failure mode is uniformly fluent output that can be systematically wrong. Plan for the second property, because it is the one that actually happens.
A workable staging order
The three routes are usually presented as alternatives. In practice they stage, and the order that survives contact with an operations team is automation first, outsourcing for the long tail, humans for the exceptions.
Stage one is automated handling on the languages where the traffic is predictable and the intent is narrow: order status, returns, password resets, shipping windows. This is the volume that makes human coverage unaffordable and the volume that is least damaged by a wrong answer, because the customer can verify it.
Stage two is outsourcing or a partner for languages where demand is real but not steady enough to justify a hire. This is where a written quality bar earns its keep, because you cannot supervise every reply directly.
Stage three is in-house bilingual capacity for the languages where the conversation is commercially decisive. Not the highest volume — the highest consequence. A pricing dispute, a retention conversation, a complaint that will be quoted back to you in public.
Each stage needs the same three supporting pieces regardless of route, and they are the same three that the quality metrics piece argues for: a per-language review quota, an agreed vocabulary, and a measurement that reflects what the customer perceived rather than what you purchased.
What to decide before you buy
Write down three numbers before you talk to any vendor. First, what proportion of conversations are in a language nobody on your team speaks. Second, what your current cost per resolution actually is, including the conversations that go unanswered. Third, which languages are commercially decisive rather than merely high-volume.
Vendors will optimise for the first number, because it is the one that makes their per-resolution pricing look attractive. The third number is the one that should decide the model, because it is the only one that reflects consequence. A team that answers that question first tends to end up with a smaller automation surface and a much better outcome than a team that tried to automate everything.
If you want the mechanical side — detection thresholds, latency budgets, and what happens when the queue is empty — that is covered in the piece on the real-time pipeline and the piece on queue routing by language.
