One support team answering customers in twelve languages without hiring for each one

A team of four, and customers in eleven languages

Say you run support for a European e-commerce brand from Lisbon. Four people work in English and cover Portuguese, Spanish and some French between them. The shop sells into Germany, Austria, Switzerland, the Netherlands, Belgium, Italy, Poland, Sweden and Denmark, and customers write in their own language, as they should.

Everything else goes through a browser tab: paste the message into a translation site, read the English, write a reply, paste it back and send whatever comes out. Mostly it works. The German customer gets du from a brand that has always said Sie, a product name that is also an ordinary word arrives translated, and now and then a number changes on the way: a 30-day window becomes 'a month'.

Nobody can check the Polish reply before it goes, and withdrawal or warranty wording is improvised each time in a language nobody on the team reads. Hiring a native speaker per market does not scale down to forty Danish tickets a week.

The fix is not a chatbot that talks to customers on its own. It is an AI integration inside the helpdesk the team already uses: the four keep writing every reply themselves, so the personal touch stays, and the parts that must not change are protected in code.

A German refund complaint, answered by someone who reads no German

The agent sees the original and the translation side by side, writes in English, and sees every check that ran before the reply can go out.

What the layer does between customer and agent

A model works in two places: translation in both directions, and the comparison behind back-translation checks. Detection, the glossary, number checks, legal wording and the decision to hold a reply are ordinary code.

The mistakes machine translation makes in support

Grammar is rarely the problem. These are, and each has its own check rather than a hope that the engine improves.

One profile per market, not one prompt for all of them

A market profile is data: the team edits it, it is versioned, and each translation records the version it used. Some of what differs:

The report that shows where each language falls behind

Translation fixes the conversation, not the reason for it. In multilingual support a common reason is that the answer exists in English but not in the customer's language, or only in an old version. The layer already knows which topics came up in which language, so once a week it compares that with the help center.

On Zendesk Guide the check is direct: the Help Center API lists the locales an article is missing, and each translation carries an outdated flag that is set when the source article changes. The report joins those with ticket counts, such as 'returns for sale items: 31 Italian tickets this month, no Italian article' or 'sizing guide: Polish version outdated since June'.

Those few articles deserve a professional or carefully reviewed translation, since a help-center page is read far more often than any single reply. The same profiles and glossary carry over to public review replies, which have the same language problem in public.

Adding a market without guessing

Each new language goes live the same way, with a test set before any customer sees a reply.

1. Collect 50 to 100 real tickets from that market, with the replies actually sent, as the test set.
2. Build the glossary: names to protect, the brand's words for refund, voucher, delivery and account, and words it never uses.
3. Set the profile: form of address, greeting and sign-off, date and currency formats, and the topics that count as high risk.
4. Have the legal snippets translated once by a professional translator or lawyer, and lock them.
5. Run the test set through the layer and have a native speaker review a sample, logging each error as meaning, tone, terminology or formality.
6. Go live with back-translation on every reply in that market, and relax it only when the error log justifies it.

The test sets are re-run whenever the glossary, a profile or the translation engine changes, before the change reaches customers; the scoring approach is covered in evaluation frameworks compared.

Is your helpdesk's built-in translation enough?

Often it is. Zendesk, Intercom and Gorgias all offer translation for agents in some form, with differences in channels and plans; Intercom, for example, lists AI auto-translation of conversations in its Copilot add-on. For a team covering two or three extra languages without strict tone rules, switching that on is the right first step. If quality in a language matters more than speed, Unbabel pairs machine translation with human review and integrates with Zendesk, Salesforce, Intercom and Freshdesk.

A custom layer earns its cost when the rules are the product: a glossary that protects your names, a form of address per market and brand, legal wording that must never be paraphrased, number checks before anything is sent, and a report of where your help center fails each language. It also wins when several helpdesks or brands need one set of rules, or when your data protection review needs to know exactly which provider sees which message.

The build leaves the helpdesk as it is: a sidebar app on the Zendesk Apps framework, or the equivalent surface in Intercom or Gorgias, plus a small webhook service that calls DeepL for translation and a language model only for tone notes and back-translation checks. If you later move to a built-in feature, the glossary, profiles, snippets and test sets stay yours.

How you would know it is working

A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.

Translations sent unedited

Share of outbound translations sent as produced, per language. A falling rate in one language points at its glossary or profile.

Blocked sends by check

Number mismatches, protected-name misses, formality and legal-snippet flags per week: a safety record and a map of where the engine struggles.

Native reviewer error rate

Errors per hundred reviewed replies in the monthly sample, by type: meaning, tone, terminology, formality.

CSAT and reopen rate by language

Compared with the languages the team speaks natively. A gap that does not close means the replies are readable but not yet good.

What a build like this costs

This is built as AI Integration, which runs $3.5K - $45K overall. A build like this one usually lands in the single AI feature tier: $3.5K - $15K, 1-3 weeks. The first working version runs on your real data well before the end of that window.

What it costs to run

DeepL's API is billed per character, and each ticket is translated in and out, plus a back-translation for risky replies. For a team handling a few thousand tickets a month that is a modest monthly line, well below the cost of one hire; tone notes and comparisons add fractions of a cent to a few cents per ticket.

What moves the price

• How many languages and markets, and how many need their own profile (German for Germany and for Switzerland are two)
• How many helpdesks and brands the layer spans
• How much legal wording needs professional translation and locking per market
• Whether the language-gap report is included, and which help center it reads

Who this is for

• E-commerce brands selling across the EU from one support team in one country
• Hotel groups whose guests write before, during and after a stay in their own language
• SaaS companies whose customers expect German, French or Dutch while the team works in English
• Teams pasting messages into a translation site and hoping nothing important changed on the way

Questions people ask about this