Here are the five most important steps to transition your customer support organization from supporting customers in one language to supporting customers in many languages.

Customer support managers are often relegated to the sidelines during a product launch into a new language. The company focuses entirely on translation of the user interface, leaving customer support as an afterthought. Suddenly, it’s on you to support your product in a brand-new language or five … and this happens.

• You discover that the very basic, multilingual customer support plan documented in the early days is woefully inadequate.
• That one woman on the help desk who spoke Portuguese as a kid is in way over her head.
• You want to be a team player. So you scramble to get your help articles translated into the new language. 
• Your team furiously cuts and pastes help article translations into your CRM. You’re seeing numerous formatting errors … who knows about translation accuracy.

I’ve been a software globalization consultant for 15 years and I’ve witnessed (and participated in) most of the big mistakes companies can make as they go global. Even Forbes agrees that providing consistent and high-quality customer support is the most difficult piece of the globalization effort. Based upon my good – and especially bad – experiences, here are five, important, pre-emptive steps you can take to more smoothly globalize your support operations. 

#1 Take a Long, Hard Look at Your CRM (Client Relationship Management) Platform

I’m going to take a leap and imagine that if you are big enough to go global, you are already using a CRM to author and publish your help articles, queue up your support emails and respond to support chats. Maybe your CRM is awesome for the single-language support you have been providing so far. The question now is: how does it handle storage and retrieval of articles in other languages? Does it maintain an association between a source-language article and translations thereof? Does it have a versioning system? Do you need to purchase a language interface for each new language you must support? Does the support portal provide a means of detecting the customer’s language and passing that value into a server for retrieval of correctly translated articles? Or for the queueing of support questions to the right agent?

The answers to these questions should drive the decision of whether you stick with your current CRM or consider transitioning to a new one that better accomodates multilingual customer support. Though migration to a new CRM might sound like a crazy hassle now, imagine how difficult it will be after your support content has quintupled because you are supporting five new languages. Or ten. Now is the time to make that change if a change is in order.

At Language I/O we work extensively with two of the top CRM platforms out there: Oracle Service Cloud and Salesforce. I can tell you that both provide out-of-the-box, multi-language support but both also require that CRM administrators put some thought into multilingual workflows and how the ongoing translation process is going to be handled. Translating articles into another language is the easy part. But what happens after the initial translation when you want to just update one paragraph in a long article?

Will your translation vendor be able to run the article through translation memory so you don’t have to pay again for the part that is already translated? If you have to export the content into Word files for translation, will the HTML formatting be preserved when the translations are pushed back in? If you are sending English articles to the linguists for translation into five languages, will the linguists know how to recode links embedded in your articles so they link to the translated versions of related articles? How about links to the corporate website? Links to image files? All these require a localization strategy.

Consider a CRM that provides localization add-ins that automate that entire process of article translation, translation memory matching and link rewriting.

What about support emails and chats? Are you going to hire an entire help desk for each new language you support? What about during Chinese new year when your Chinese help desk goes on vacation or your Brazilian support desk gets the flu? There are add-ins for some CRMs that allow your English agents to read and respond to questions in any language so you can provide multilingual customer support without hiring a multilingual help desk.

#2 Don’t Let Other Departments Dictate Your CRM Content Translation Solution

Some customer support organizations have more sway within the overall company than others. Regardless of the weight you throw around as a customer support manager, I’ve seen it time and again that the product or marketing organization is driving the globalization effort and gets to pick the localization vendor. They might assume that what is good for product translation is good for the support organization. Not true.

What the product and marketing folks don’t often realize is that the knowledge base managed by you, the customer support manager, is usually the largest body of translatable content within the company. Further, the strategy for translating support content should NOT be the same as the strategy employed for the product UI or marketing collateral. Your knowledge base content is stored and updated within the CRM via an entirely different process than that employed for the product UI or marketing collateral.

Before I continue,  a bit of background on translation vendors. A company will often hire what is called a Multi-Language Vendor (MLV) to handle product translation. These are translation (also known as localization) companies that manage the translation effort across many languages. Sometimes the MLV will employ linguists directly. More often they have subcontractor relationships with numerous Single Language Vendor (SLV) companies that in turn employ linguists for a particular language. If your company has plans to go into multiple languages, the MLV route is the easiest. The MLV will initially just be focused on translating the product User Interface and marketing collateral because that is the most important thing to product. 

Is the chosen MLV the best choice for translation of your entire KB (knowledge base)? Here are some questions that usually stump them. Can the MLV at a reasonable cost:

1. Automate the export your entire KB for translation, preserving proper HTML formatting?
2. Create a easy process for content authors to request the translation of updates to help articles and export the article in question from your CRM for translation?
3. Run the exported HTML files through translation memory so you’re not charged for parts that were already translated?
4. Automate the process of rewriting the links in your translated articles so the translated articles link to other articles, images and videos of the correct language?
5. Provide a rapid-turnaround human or machine translation solution inside of your CRM for support question translation?

Because I have a good handle on both the localization and CRM industries, the answer is very likely no to most of these. Language I/O provides add-ins to both Salesforce and Oracle Service Cloud that handle all of the above for you, using linguists best-suited for translation of support content. 

The product and marketing organizations might throw up resistance to using a translation solution other than the one they came up with. However in today’s world, use of glossaries and portable translation memory is standard with any MLV and allows different organizations in the same company to use their own translation services while still maintaining a consistent vocabulary and tone across languages.

#3 Hire an Objective, Third-Party Linguistic Reviewer for Each Language You Support

What is a third-party, linguistic reviewer? First let me tell you what the linguistic reviewer is not. This is not a linguist employed by your MLV. It is not the woman on the support desk who spoke Portuguese as a kid. It is not even a customer who will be using the product.

The linguistic reviewer is someone you pay – usually just part time – and who can be pulled in on short notice to review translated content provided by the MLV. Note that the reviewer can be shared across a company’s departments. This is also a person who is a native speaker, currently lives in the country you are targeting and who has a good business sense for your product.

Respectable MLVs will have their linguists working within translation workflow tools that provide a “review” step. Once their translators are done translating content, the content can be assigned to a reviewer who is defined within the platform and receives notifications when it is their turn to review the translations. This reviewer should not be someone employed by the MLV as any vendor reviewing their own translations might not be completely objective.

A customer who speaks the language at first sounds like a great idea for a reviewer, but there are two problems with customers. First, they can’t be relied upon to review translations in a timely fashion because you don’t pay them … in fact they pay you so you’re kind of at their mercy. If the translation is for whatever reason a poor-quality translation, this could damage your customer relationship because they might think that you don’t know what you are doing. 

Your own, part-time, third-party reviewer needs to jump into the MLV’s translation work-flow tools and review everything that is translated before it is exported from the MLV tools and imported back into your system.

Next, the reviewer needs to review the translations within the context that your customers will be viewing the content. If we’re talking about KB articles, once the translated articles are imported back into your CRM, give the reviewer access to the translated articles in your support portal before the customer has access to them. The reviewer will find contextual errors, formatting errors, etc and you can get them fixed by your MLV before the articles are published for the public. The reviewer doesn’t need to do this for smaller updates, but it is critical when you are pushing a large number of translated articles live for the first time.

#4 Share a Translated Glossary of Key Terms Across the Company

A glossary of key product terminology is the first thing that you translate in any new localization effort. The glossary often starts as an excel spreadsheet that just contains all of the English terms that are product- and vertical-specific and which might not be immediately understood by translators. Often, it is a term that is part of the product’s UI. If it is not translated using exactly the same term in the support article as in the UI, you will receive lots of expensive support emails and calls.

Let’s say your product offers some kind of subscription service and you have a product that in English is called the Annual Pass. The glossary will contain both the English term and the French-Canadian translation Accès annuel. If the translator translating a support articles translates Annual Pass as Accès annuel but the product UI doesn’t employ the glossary and translates Annual Pass as Passe annuel, chaos ensues. The support article will tell customers to click on the link entitled Accès annuel, which they don’t see in the product UI. They will then likely reach out via the more expensive email or phone support routes.  

#5 Share Translation Memory Across the Company

In addition to a glossary, a translation memory database shared across your company will ensure that your translations are not only less-expensive, but also consistent. The first time a support article is translated, the translation between English and the other languages is stored in a database. When a content editor changes a paragraph in that article and it is sent again for translation, your MLV will run the HTML content through its translation memory and notice that you already have matching translations for this English article, save that one new paragraph. 

The MLV’s translation work-flow tools will only push that new English paragraph in front of the linguists for translation, saving both time and money. Later, if that same paragraph is translated in the UI, it will be translated exactly the same way in the UI as it is in the support article, maintaining consistency across an organization. 

An MLV’s translation memory (TM) should always be exportable in an XML format that any other MLV can then import. So if product and the customer support organization use two different translation services, as long as they share the glossary and TM, the translations of the product and the customer support content will be consistent.