Support technique multilingue
My hovercraft is full of eels
Once your customer base gets large enough, you’re going to have some folks reaching out for support who do not have English as a first language. (If your startup isn’t based in an English-speaking country, this time will probably come a lot faster!) And at some point, you’ll have to decide: should I be building a multilingual support operation? This week let’s look at the pros and cons, then I’ll talk about the practical considerations, should you determine that it’s important for your team to provide multilingual support to your customer base.
Side note: Anglocentricism
I’m American and my audience consists mostly of native English speakers. Most of the startup ecosystem I’m familiar with is conducted mostly, if not entirely, in English. But if you’re in an environment where you’re primarily doing business in another language, the following considerations probably still apply for the most part, mutatis mutandis.
Point: it’s not worth doing
On one support team I ran, my boss was fond of saying: in this field (infrastructure-as-code), everyone speaks English. They have to. All the docs are in English, all the existing expertise is in English. So we can be confident that anyone we’re dealing with will be speaking English too. And while I didn’t entirely buy that argument, I have to admit that my boss was right. We never once ran into a customer or prospect who had trouble with our English-only support.
Hiring new team members is always expensive, and finding folks with the right skillset can be difficult. Add to that the requirement that they speak language X (in addition to English, since you still have to be able to communicate with them) and it gets more difficult still. Unless it’s absolutely necessary, there’s no reason to handicap your hiring process like that. If you’re able to hire a support engineer with competence in other languages, fantastic—but that shouldn’t be a job requirement.
Beyond that, which languages do you want to support? Until your customer base is large enough to have significant populations of any given language, you’ll be relying on pure speculation about where your company is likely to have the most growth in the next 6-12 months. Are you willing to bet that you’ll have enough, say, Spanish-speaking customers by then that it makes sense to hire someone who can provide support in that language specifically?
Another issue is that for many languages, you’re probably going to have more luck looking internationally for bilingual support engineers. That will immediately cause you issues around time zones, effective team management, and the general business and tax headaches that come from hiring international employees or contractors. Is your need for multilingual support so great that it can overcome these downsides?
Finally, as LLMs (large language models) have gotten more and more qualified to translate from one language to another, does it even make sense to build expertise in multiple languages when you can just click a button to render your English into reasonable Italian, or Czech, or Mandarin? Even heavy use of LLM translation is going to be a lot cheaper than hiring polyglot support engineers, especially as the list of distinct customer languages grows.
Counterpoint: maybe it is actually worth doing
With respect to my old boss I quoted above, I don’t think it can be universally assumed that highly technical software users have at least some English. Maybe it’s still true in some specific fields, but not as a general rule. And even if the folks you’re interacting with can speak English, that doesn’t mean they particularly want to. In my most recent team, I saw this firsthand: while we officially did all of our business in English, we had a number of German-speaking customers who were significantly more comfortable discussing our product, its deployment, and troubleshooting in German rather than in English. When they worked directly with our German-speaking team, without having to mentally translate everything into English for others’ (i.e. my) benefit, those sessions were noticeably more productive.
Machine translation would be useless to provide that sort of experience. For one, an English-speaking support engineer wouldn’t be able to provide an interactive troubleshooting experience conducted entirely in German. While LLMs may be getting increasingly good at realtime translation, there is always going to be a disconnect both temporal (as even immediate translation takes time) and cultural (no American is going to be able to build rapport as quickly as an actual German-speaker).
The point about not having a critical mass of customers with a given (non-English) language makes more sense when you’re in an American or other Anglophone startup. A company based in Germany, as in my anecdote above, is naturally going to have an immediate preponderance of German speakers. It doesn’t make any sense to ignore that reality when building your team. Besides, you’ll naturally be building your initial team through talent available locally, which means your initial hires are most likely going to be German speakers anyway.
Even for American startups, what if you land an enormous corporate deal with a Japanese (or Saudi, or German, or…) conglomerate? You’re going to have to hire additional support engineers anyway in that case, so it only makes sense to have at least some of them be fluent Japanese speakers. If the customer is big enough—and the contract long enough—it may even make sense to hire an entire team in Japan, at which point you don’t even need all of them to be able to speak English. As long as team leadership can communicate directly with you, and you trust them to lead their team effectively, that will be sufficient.
Practical considerations
Enough of the pros and cons—if you’re not going to go multilingual, there’s no more to say, until conditions change and you’re ready to do it. If you are going to, let’s talk practical details. If I had to set up a multilingual technical support team today, this is what I’d be thinking about.
How good does it need to be? Are you dealing with customers who are expecting native or near-native support in their own language? What contractual commitments have you made? How much of a handicap will your support agents be under if they can’t communicate with customers in their own native language? The answers to these questions will be different for every support team, and not all of them can be answered within your team. Coordinate with Sales, Customer Success, and senior leadership before unilaterally deciding how you’re going to provide support in languages other than English.
Once you’ve determined the expected quality level, the next step is to figure out how you’re going to implement multilingual support. From cheapest to most expensive (and, not coincidentally, in order of quality) they are:
Machine translation: running the gamut from existing autotranslation software to the swiftly improving state of the art of LLM translation, this is a good place to start. The downsides here are around guaranteeing support quality (see below for more on that point) since you’re at the mercy of your translation tools. Real-time communication and troubleshooting remains cumbersome with the current state of the art of translation software.
Multilingual agents: finding people who can speak the language at a fluent or native level may be difficult, but will pay dividends in improving your support quality for customers who’d prefer to interact in that language. Cost-wise, they may not be more expensive than your monolingual English speakers, and in fact they may actually be less expensive depending on local salary expectations. But adding additional heads to the team is almost always going to cost more than just buying software, as above.
Full support localization: one step beyond adding multilingual support engineers to your team is building an entire team around providing support in another language. Typically these teams are located somewhere that language is spoken natively, and individual engineers on that team may have limited or no English. Their entire purpose is to provide support in that specific language, and will not be as much help filling in for your Anglophone team members. This is clearly going to be the most expensive option since you’re talking about setting up a whole team, but will provide the highest quality support options for customers who aren’t willing or able to conduct technical troubleshooting in English.
Finally, consider how you’re going to monitor the quality of support for these languages that you probably don’t speak yourself. This is going to be the most difficult if you choose the machine translation option above since you’re never going to be able to judge how well your messages have been translated, or how accurately the tool translates customer messages into English. About all you can do is to periodically check with bilingual customers that the machine translations are sufficiently good. With bilingual support engineers it’s important to regularly work with them to ensure they’re not having any issues working with your customers, and keep a close eye on CSAT scores for that engineer’s issues. With a full support team dedicated to support in another language, the most important thing is to trust the manager of that team, and to regularly meet with them to iron out any ongoing issues that may be giving them trouble: interacting with the rest of your team, working with Engineering, and other places where the language barrier might be impeding a fast and accurate support process.
Thanks for reading Andy's Support Notes 💻💥📝!