This post may contain affiliate links. If you buy through one, we may earn a commission at no extra cost to you. See our Affiliate Disclosure for details.
A ticket lands at two in the morning, and the first line of it is in Portuguese. Nothing about the situation is dramatic — it's almost certainly a refund question, or a shipping question, or the same password question that arrives in English eleven times a week. But the ordinary move, skim it and answer it, isn't available. Paste it into a translator and you get a serviceable English version in four seconds. Then comes the part nobody warns you about: you write a reply, translate it back the other way, and send a paragraph you cannot read to a stranger who will judge your business by it.
Start by measuring, not buying. Look at the last hundred tickets and count which languages actually showed up — most solo businesses find one or two beyond their own, not twelve. If it’s a trickle, copy-paste into a general translator is genuinely fine and costs nothing. If a language appears weekly, move translation inside whatever helpdesk you already pay for so the original and the translation stay on the same ticket, and translate your ten most-repeated answers once into permanent saved replies rather than re-translating them forever. Keep a short glossary of your product’s own words so they survive the round trip. And never send machine-translated text about money, cancellations, or legal terms without a human who reads that language checking it first.
The gap isn't translation. It's the reply you can't check.
Reading an inbound message in another language is a solved problem. It has been for years, it's free, and the quality is good enough that you will understand what the customer wants roughly every time.
Sending is the asymmetric half. When you translate your own reply, you lose the ability to notice that it came out curt, or oddly formal, or subtly wrong in a way that will produce three follow-up tickets. In your own language you catch that instantly — a sentence reads cold and you soften it before hitting send. Translated, that instinct is gone and you're shipping blind.
This is why "just use a translator" advice undersells the problem and why buying a multilingual support platform oversells it. The tooling isn't the constraint. Verification is.
So the useful question isn't which translator is best. It's which parts of your support conversation can safely go through a machine unchecked, and which parts can't.
Count the languages before you spend anything
Open your inbox or helpdesk and go back through the last hundred conversations. Tally the languages.
Almost everyone doing this for the first time is surprised in the same direction. The imagined problem is a global inbox in fifteen languages. The real one is usually eight tickets in Spanish, three in German, and one in a language you've never seen before and will never see again.
That distribution matters, because it decides your whole approach. One language showing up weekly is a recurring workflow worth building. A one-off in Finnish is a copy-paste job and always will be. Building a localization system for the Finnish ticket is how solo owners spend a Saturday solving a problem they have once a year.
While you're counting, note what the non-English tickets ask about. If they cluster — and they usually do, around shipping, returns, and setup — you have a much cheaper option than translating conversations, which is covered further down.
Count which roads people actually arrive on before building for all of them. Photo via Pexels.
Three setups, roughly in order of effort
Copy and paste into a general translator
Zero setup, zero cost, and for low volume it's the correct answer rather than the lazy one. Two browser tabs and some patience.
The friction shows up in the record. Your helpdesk stores the original message; the English version you actually worked from lives nowhere. Six weeks later you reopen the ticket to check what was promised and you're translating it a second time. Minor annoyance at five tickets a month, real drag at thirty.
Worth knowing about the engines themselves: DeepL built its reputation on European language pairs and covers a narrower list of languages than the big general-purpose engines do, while Google's Cloud Translation covers far more ground. Both publish their supported language lists on their own sites. The only comparison that matters to you is the specific pair you need, tested on your own real messages — general quality rankings tell you nothing about how a tool handles your product's vocabulary.
Translation inside the helpdesk you already pay for
The upgrade isn't better translation. It's translation that lives on the ticket.
Mainstream helpdesk platforms have been adding some form of translation to the agent view — the customer's original text and a translated version side by side, with your reply translated on send. Help Scout, Intercom, and Zendesk all position themselves for multilingual teams, but which capabilities sit on which tier differs by vendor and changes without announcement, so their plan pages are the only trustworthy answer on any given day.
What you gain is continuity. Both versions stay attached to the conversation, the next person to read it — future you, at two in the morning again — sees what was actually sent, and saved replies can be stored in each language instead of regenerated each time.
That last detail is the real saving. Ten well-written stock answers, translated once and checked once, will cover most of what arrives. If you're already routing everything through one place, the same logic behind consolidating into a single shared inbox applies here — the point is that the context stops living in your head.
Answers that never become tickets
The cheapest multilingual customer support is the conversation that doesn't happen.
If your non-English tickets cluster around six recurring questions, translating those six answers into a public help page does more work than any live translation feature. It runs while you sleep, it never sends anything awkward, and each translation is checked once instead of improvised weekly.
Self-serve content is also the layer that machine translation handles best, because you can review it slowly before publishing rather than under time pressure inside a live chat. Building it out overlaps heavily with setting up a knowledge base as a solo operator, and the two projects should be one project.
The order of operations, then: translate your documentation first, your saved replies second, and live conversations last.
Where machine translation quietly goes wrong
Not with gibberish. Modern output reads fluently, which is precisely the trap — fluent and wrong looks identical to fluent and right when you can't read it.
Register drift. Languages that mark formality — German, Japanese, Korean, French, Spanish among many others — force a choice about how familiar to be, and the machine makes that choice for you without telling you. A support reply that lands as too casual reads as disrespect in some markets. You won't hear about it. The customer just stops replying.
Your own vocabulary. Product names, plan tiers, and feature names get helpfully translated into words that don't exist in your interface. Now the customer is looking for a button that isn't there.
Confident invention. Ambiguous source text gets resolved into something specific and definite. In a sentence about whether a refund covers shipping, that specificity is a promise you didn't make.
Compounding round trips. Their message is translated for you, your reply is translated for them, and their next message continues from your translation. Small distortions accumulate across a thread in a way a single-message test never reveals.
The line is easy to draw, though: anything routine and low-stakes can go through a machine. Anything touching money, cancellation, liability, or a legal term needs review by a person who reads the language — a translator you pay for one hour, not a subscription.
A glossary is the cheapest quality upgrade available
Before adding any tool, write down the twenty words your business uses that must never be translated or must always be translated the same way.
Product names. Plan names. The exact labels on your buttons. Any industry term you use in a specific sense. Set each one against the form you want in every target language, and confirm those with a human once.
Most helpdesk and translation tools can enforce a term list of this kind, and even where they can't, having the list changes what you notice — you can eyeball a translated reply for four known words without reading the language. That's a real check, not a vibe.
It takes about an hour. It removes the single most common cause of confusing translated support, which is not grammar but your own nouns quietly turning into other nouns.
Twenty words, written down once, survive every round trip after that. Photo via Pexels.
What to check on the plan page, and when you checked it
As of August 2026, this post quotes no prices, and that's deliberate — helpdesk tiers and translation quotas get restructured often enough that any number written here would be wrong before it's useful. The vendor pages linked above are the current answer. Check them the day you decide.
Three things to look for that headline pricing tends to obscure:
Which tier the multilingual features sit on. Translation and localized help center content have a habit of living one plan above where you'd expect. Confirm on the pricing page rather than on a comparison article.
How translation volume is metered. Standalone translation services meter characters; helpdesks usually fold it into a seat price. Those are different cost shapes, and neither is automatically cheaper.
Whether a free tier covers your actual volume. Eight tickets a month in one language may sit comfortably inside a free allowance. It's worth knowing before you commit to anything annual.
One thing not to buy yet: an automated bot answering in languages you can't read. That's a bigger step than it looks, for the same reason the rest of this post gives — you can't audit the output. The chatbot versus autoresponder trade-off is worth understanding in your own language first.
Run ten real tickets through it this week
Pick the language that appeared most often in your count. Find ten genuine past conversations in it — real ones, with your real product names and your real edge cases, not sample sentences.
Translate the inbound messages, write your replies as you normally would, translate those, and then do the step that actually matters: send the ten translated replies to one person who reads that language fluently and ask a single question — would this sound normal coming from a business?
An hour of a freelance translator's time answers what no feature comparison can. You'll come back with two or three specific problems, usually formality level and a couple of mangled product names, and both are fixable with the glossary above. Then you'll know whether your existing free setup is already good enough, which for a surprising number of one-person businesses it is.
저는 한국에서 직원 없이 혼자서 두 개의 소규모 사업체를 운영하고 있습니다. 견적, 회계, 마케팅, 웹사이트 관리까지 모두 제가 직접 하고 있습니다. 개발자는 아니지만, 이 사이트의 자동화 시스템은 AI 코딩 도우미를 활용하여 밤늦게까지 오랜 시간 공들여 구축했고, 모든 콘텐츠 관리 및 게시도 제가 직접 담당하고 있습니다.