The honest starting point
Visitors will write to you in their language regardless of what your team speaks — the only question is whether the experience is planned or improvised. A small team cannot staff five languages; it CAN localize the surfaces, run translation-assisted conversations with candor, and let the data show which language deserves real investment.
The launcher label, pre-chat form, and system messages are the first impression, and they are static strings — translating them is a settings task, not a staffing one. A widget that greets in the visitor's language and then says, honestly, "our team replies in English" outperforms one that pretends: expectations set beat expectations broken.
Layer 2: translation-assisted conversations, with candor
Machine translation is now good enough for support logistics — order status, how-tos, policy questions — and still risky for nuance, anger, and legal precision. The workable pattern: translate to read, reply simply, and be candid ("I'm using translation — tell me if anything reads wrong"). Short sentences, no idioms, no sarcasm; the same discipline that makes good chat writing also makes it translate cleanly.
Layer 3: translate the knowledge base by demand, not ambition
Do not translate 200 articles into four languages; translate the top ten into ONE — the language your transcripts and visitor locations actually show. Ten well-translated articles absorb most of that audience's repetitive tier (and give an AI assistant trained on them a real corpus to answer from). Expand only when the next language's demand shows up in the same data.
Layer 4: schedule the bilinguals you have
One bilingual teammate is a scheduling asset, not a translation department. Route their language's conversations to them when online (departments or routing rules do this mechanically), and let the offline form set honest expectations the rest of the day: "Spanish support replies within one business day." Protect them from becoming the permanent translator for every colleague — that road burns out your only speaker.
When to actually hire for a language
The trigger is in your transcripts: a language whose volume keeps growing, whose conversations convert or churn measurably worse than your primary language, and whose top questions are already translated — meaning the remaining gap IS the human. That is a hiring case a founder can read from the transcript history, not a guess.
Measure the gap you cannot see
The silent number: visitors from non-primary-language countries who open the widget and never type. Watch chat starts by visitor country before and after localizing the widget strings — the delta is the audience you were turning away at the door.
Time zones arrive with the languages
A second language almost always brings a second working day with it, and teams plan for the
translation while ignoring the clock. The result is a language you technically support during hours
when nobody who speaks it is awake.
Check the arrival pattern before deciding anything. If most Spanish-language chats arrive at seven in
the morning your time, the useful investment is a well-written offline path and a fast morning reply,
not a bilingual agent sitting available all afternoon.
Where the overlap is genuinely poor, say so on the widget in that language. A visitor told in their
own language when someone will answer is far better served than one who finds a live widget, writes at
length, and waits nine hours for a reply.
When nobody on shift speaks it
This is the normal case for a small team, and it needs a prepared answer rather than an improvised
one. Have a short passage written in each language you regularly receive, saying plainly that the person
answering does not speak it, offering to continue in a shared language, and offering a follow-up from
someone who does.
Candour beats a machine-translated performance of fluency. If you use translation tools to help, say
that you are doing so; visitors are far more tolerant of an imperfect translated answer they were warned
about than of a confident one that turns out to be wrong. Be especially careful with anything involving
money, safety or a commitment, where a translation error is expensive.
Keep the fallback promise realistic. Offering a bilingual follow-up you cannot staff is worse than
offering none, because it converts a language limitation into a broken promise.
What to measure
Count chats by language even for the languages you do not support. That count is the entire business
case for whether to invest, and most teams have never looked because the conversations end quickly and
leave little trace.
Watch the abandonment rate in each language separately. A high abandonment rate in one language
usually means the widget itself is not understood, which is a localisation problem you can fix cheaply,
rather than a staffing problem you cannot.
Track outcomes, not just volume. If chats in a second language convert or resolve at a much lower
rate than your main one, the honest reading is that you are half-serving that audience, and half-serving
is often worse for reputation than clearly not serving at all.
One practical note before you plan around it: the agent dashboard itself ships in ten languages, but the picker reaches only part of the product — which parts of your dashboard change language sets out what your team will actually see.