A seller in Valencia lists on Amazon.de, Leroy Merlin in France, Worten in Portugal and a Dutch marketplace. By Tuesday lunchtime the inbox contains German, French, Portuguese and Dutch, and every one of those customers expects an answer in their own language, within a day.

Machine translation has made this a solved problem in principle. In practice, customer-support translation has failure modes that a general translator never meets, because the text is full of things that must not be translated at all: order numbers, tracking codes, prices, product names, URLs. And because the answer goes to a person who will act on it.

This is what we check, and what we learned the hard way.

The two directions are not symmetric

Inbound, a customer’s message translated into the language your team reads, is low-risk. If the translation is slightly off, the agent has the original next to it and a customer’s intent is usually obvious. Speed and coverage matter more than perfection here. Automated mail, quoted history and messages already in your language do not need the model at all, and skipping them keeps the cost and the noise down.

Outbound, your reply translated into the customer’s language, is where the damage happens. The agent typically cannot read the output. If it is wrong, nobody notices until the customer does. Everything below is about outbound.

What must survive a translation unchanged

A translation of a support reply is only acceptable if the following are identical on both sides:

Order and tracking references. 403-1234567-7654321 must come out as 403-1234567-7654321. Models occasionally “correct” a digit, drop a hyphen, or, worse, produce a reference that was not in the input at all.
Prices and amounts. “29,90 €” is not “29.90 EUR” in every locale, but it had better be the same number.
Names, product names and URLs. Translating a product name makes it unfindable. Translating a URL breaks it.
The language itself. The output must be in the target language. This sounds too obvious to check. It is not.

The Bulgarian incident

The last point comes from a real afternoon. A Bulgarian customer wrote in Bulgarian. The agent replied in Spanish, the tool sent the reply to the model with “translate to Bulgarian,” and the model returned… Spanish. Fluent, polite, unchanged Spanish, with the model apparently deciding the request did not apply. The tool marked it done and sent it.

Nothing in the pipeline had asked the simplest question: is the output actually in the language we asked for?

Since then every outbound translation goes through a guard before it can be sent:

Not empty. Models sometimes return nothing, or only a fence.
Not identical to the input. If the output is near-identical to the source, nothing was translated.
Right language. A cheap language check on the output. If it does not look like the target language, fail.
References preserved. Every order- or tracking-like token in the source must appear in the output, and the output must not contain any that were not in the source.
Plausible length. A translation five times longer or five times shorter than its source is not a translation.

If the guard fails, the tool retries once with a stronger model and the target language pinned in the instructions. If it fails again, it does not send anything. It tells the agent why, and offers to send the original in the working language instead. A reply in the wrong language is worse than a reply the customer has to run through their own translator.

Review before send, always

Even with the guard, the translated text is shown to the agent before it goes, with the original next to it. Most agents cannot check the German. They can check that the order number is there, that the tone looks right, that it is not three times longer than what they wrote. And they can decide, for a delicate case, to send the original instead. The point is that a human saw it, and the tool keeps both versions, so if a customer later says “you told me X” you can see exactly what was sent and what the agent meant.

Where the customers’ messages go

There is a second, quieter question in all this: to translate a message you have to send it somewhere. A customer’s message is personal data. It can contain an address, a phone number, a complaint about a medical device.

Two things follow. First, the workspace should be able to switch translation off entirely and keep everything in-house; agents still see originals. Second, when the model is used, the provider matters. Some model providers keep prompts and use them for training; some do not. When a routing service offers a choice, ask for the providers that do not retain data. We measured this on our own traffic: the no-retention providers were not slower. In our case they were faster, because the default route had landed on a provider that was quietly producing runaway output.

A practical policy for a small team

You do not need a tool to adopt most of this:

Reply in your working language and translate at the end, not word by word as you type.
Never type an order number by hand into a translated reply. Copy it. Then check it is in the output.
If the customer’s language is one you can partly read, read the output. If it is one you cannot, at least check the numbers and the length.
Keep the original of what you meant to say. Disputes are about intent.
Decide, as a company, whether customer text may leave your systems for translation, and to whom. Write it down.

Translation is what makes selling across Europe possible for a team of two. The guard is what makes it safe.