Answering email in the language it arrived in
A support team that answers in two languages and receives mail in nine has a coverage problem that costs real money: the Finnish customer waits three days for someone who speaks Finnish, or gets an English reply and works it out. An agent removes that gap almost for free, which makes multilingual support one of the strongest arguments for putting one on the inbox at all.
5 min read
It is also where an agent can produce a confidently wrong sentence in a language nobody on your team can check.
The default rule
Reply in the language the customer wrote in. Not the language of your company, not the language of the last message in the thread if the customer switched, and not English because it is easier to review.
Two refinements that matter more than they sound.
Match the variant. Brazilian and European Portuguese are different enough that getting it wrong reads as carelessness. So does answering a British customer in American spelling on a formal complaint.
Match the register. Many languages encode formality grammatically, and getting it wrong is worse than an awkward phrase. German Sie and du, French vous and tu, Japanese politeness levels: mirror what the customer used, and default to the formal register when uncertain.
What to never translate
Some strings must survive intact, and a model that helpfully localises them creates a support ticket rather than resolving one.
| Never translate | Why |
|---|---|
| Order and invoice numbers, references | They must match your systems exactly |
| Product names and SKUs | The customer will search for the localised name and find nothing |
| Error codes and technical identifiers | They are lookup keys, not words |
| Legal and contractual language | Only the authoritative version binds anyone |
| Names, addresses, URLs | Obvious, and it happens anyway |
The failure to picture: an agent translating a product name into fluent Spanish, the customer searching your site for it, finding nothing, and writing back more annoyed than before. Pin these in the prompt as literal strings to carry through unchanged, and prefer a tool that returns them rather than a model that remembers them.
Where quality actually varies
Model quality by language is uneven, and it is uneven in a way you cannot see from the inside. Fluent output in a language you do not read is indistinguishable from correct output.
Practical approach: rank your inbound languages by volume, and treat the top few as covered, the middle as covered with a check, and the long tail as escalate. Getting the tiers right needs someone who speaks the language to read a sample, which is a small piece of work that most teams skip and then regret.
Two specific hazards worth knowing. Idiom and politeness collapse first, so a technically correct reply can still read as brusque. And languages with less training data produce fluent-sounding output with more factual drift, which is the dangerous combination.
Escalating without dumping
Escalation gets harder in a multilingual setup, because the human it goes to may not read the language either. Two things make it workable.
The agent should escalate with a summary in your team's working language, alongside the original thread untouched. A colleague can then decide what to do without translating anything themselves, and the original is right there when it matters.
And escalation should trigger on the same things as anywhere else, plus one: when the agent's own confidence in the language is low. That is not a feeling, it is a rule you can encode, and it is the multilingual version of "cannot cite a source, so escalate" from the system prompt.
The operational details people miss
Encoding. Non-Latin scripts and emoji need to survive the whole path. Bodies are markdown delivered as text plus HTML, and modern mail handles UTF-8 fine, but test with real Japanese, Arabic, and Polish content rather than assuming.
Right-to-left. Arabic and Hebrew replies need correct direction, and a quoted history that mixes directions renders badly. Keep replies short and let the thread carry the history rather than quoting inline, per how email threading works.
Time and dates. Write dates unambiguously and name the timezone. This matters everywhere and doubles in importance across languages, per the scheduling rules in appointment reminders.
Contact memory. Record the language and register a customer uses on their contact record, so the second conversation starts right without re-detecting, per giving an email agent memory.
Search. Your internal documentation is probably in one language while the question arrives in another, so retrieval has to bridge that. The usual fix is retrieving in your documentation language and answering in theirs, rather than translating your knowledge base and maintaining nine copies of it.
What it buys
Response time collapses for every language outside your team's coverage, which is usually where the worst numbers live. Nobody waits for the one colleague who speaks Italian to come back from holiday.
The second effect is quieter: you find out how much mail you were receiving in languages you do not support, because previously it went to a queue nobody worked and some of those customers simply left.
Questions
- Should an AI email agent reply in the customer's language?
- Yes, matching both the language and the variant they used, and mirroring formality where the language encodes it. Defaulting to the formal register when uncertain is safer than guessing informal.
- What should never be translated?
- Order and invoice numbers, product names and SKUs, error codes, legal language, and anything the customer will search for in your systems. Carry those through unchanged.
- How do I know if quality is good enough in a language?
- Have someone who reads it review a sample. Fluent output in a language you cannot read is indistinguishable from correct output, so tier your languages by evidence rather than by impression.
- How should it escalate a thread in a language my team does not read?
- With a summary in your working language plus the original thread untouched, so a colleague can decide without translating anything first.
- Do I need to translate my knowledge base?
- Usually not. Retrieve in the language your documentation is written in and answer in the customer's, rather than maintaining nine copies that drift apart.
- What about right-to-left languages?
- Keep replies short and let the thread carry history rather than quoting inline, since mixed-direction quoted text renders badly in many clients.
Give your agent an address it can answer from.
Create an inbox