6 Tips for Scaling Support Content Globally

One of the most uncomfortable moments in a breakout session any time I attend a U.S. content-focused conference is when some brave soul asks the question, "So how do you scale this outside the U.S.?"

The answer is very often, "We don't."

But when it comes to support content in particular, your localized help center is very often one of the lowest cost options for entering a new/emerging market with your product or service. And if done well, it can be extremely effective for establishing your brand, understanding your users, and creating a great self-service support foundation.

This blog post assumes you'll be using third-party translation vendors, as most larger companies do. I'll be writing a follow-up post about how to determine if this is the right path for your company and content.

 

1. Leverage local teams.

Marketing teams are often the first boots on the ground—they're there to drum up excitement, build relationships with customers, and learn what will work in this specific locale. That makes them a phenomenal resource for figuring out what your self-service customers will need first.

Connect with those teams early to set yourself up for translation success:

  • Ask for a review of your localized voice and tone guide as well as your translated glossary of terms. These are the kinds of resources your translation vendors will use when they start working with your content.
  • Request a review of translated content. Using a structured rubric is key here—you'll want to ask about distinct areas like grammar/punctuation, product accuracy, localized brand voice and tone, and terminology. You might have a translator nailing it with voice and tone but being inconsistent with terminology—you want to make sure to get structured feedback to correct the specific shortfalls.
  • Find out what content local customers need most. Your customers outside the U.S. are likely to have many of the same support needs as your domestic customers, especially in sister markets like Canada. But there will also be features that are uniquely important (or don't apply at all) that deserve special attention—think anything related to payments, taxes, and privacy to start with. Your local teams can give you more insight on specific functionality their markets want so you can focus on that support content first.

 

2. Copy and paste common phrases.

Consistency is key when it comes to keeping translations high-quality, low-cost, and with quick turnaround.

On top of that, having a glossary of frequently used instructional phrases makes creating new source content easier internally because you won't have to recreate the wheel each time you write an article. (Check out TextExpander to create a shared database of phases you can call into content with keyboard shortcuts.)

For example, on the Eventbrite help center, this is one of our most commonly used first steps:

After logging in and creating an event, click or tap on your event from the Manage Events page, then select "Manage."

Prior to standardizing how we wrote this instruction, there were lots of variations of it, like:

Click on your event on the manage page.

Go to your event in the manage tab. 

Click Manage Events and find your event.

All of these phrases convey the same intent, but do so in completely different ways. If we used all four phrases across four different articles, we'd pay for each string's translation and end up with four distinct ways of saying the very same thing.

Keep it simple: spend time figuring out the best possible phrase, then stick with it.

Consistency pays off for customers beyond just localization—when you're creating support content, patterns help your users skip the irrelevant steps more confidently and focus on just what they need. Your goal isn't to have them read each precious word you've written—it's getting them their answer quickly and painlessly.

 

3. Borrow from similar languages.

Not all English languages are created equal—but the content might be 98% equal, and it's hard to justify keeping up half a dozen different versions of English help centers for the difference in "flavor" versus "flavour." The same issue comes up for any country that colonized around the world—European Spanish and Central/South America, European Portuguese and Brasil, etc.

Rather than giving yourself a content maintenance nightmare, use some simple find-and-replace logic. How you implement this will depend on what content management system you're using (and how much control you have over it), but essentially these are the steps:

  1. Determine your master language. For English, ours was U.S. English. Since Eventbrite has offices in Argentina, we're also using Argentinian Spanish as the master Spanish.
    • Canadian French is an exception to this practice—it's significantly different from European French, so we treat it as its own locale.
  2. Set up your other countries' help centers to pull the master language unless something has been published for that locale. For example:
    • The article "How much does it cost for organizers to use Eventbrite?" has a version published in U.S. English and U.K. English. That's because the detailed answer to this question varies a lot between the two locales (our fees are different and currency varies as well).
    • The article "How to set up discount codes" has a version published in U.S. English. The feature works the same everywhere, so the U.K. help center simply pulls the U.S. article since we didn't create a unique version for the U.K.
  3. Important! Build out exceptions to the rules and do so mindfully. This allows the source content to appear localized by top-level domain (TLD) without all the extra work of creating individual articles. For example:
    • Set up your find-and-replace logic to find words like "organizer" and change it to "organiser" for the U.K. locale. 
    • Be careful with words like "cheque"—as a noun, the find-and-replace logic works fine for the U.K. locale. But as a verb, you don't want users to see "cheque your inbox."

 

4. Use segmentation in Google Analytics.

If you're working on content in a locale you already serve, the segmentation feature in Google Analytics is your friend (you do have Google Analytics installed, right? If not, go do that immediately—more on why that's super duper important at the end of this article).

Google Analytics is like an angel sent from prioritization-based-on-data heaven. You'll quickly be able to understand how much of your user base is domestic and how much isn't—and proportion your resources accordingly:

All you need to do to generate this report is pick a timeframe and go to Behavior>Site Content>All Pages. Then add a segment (detailed instructions here, straight from the fine folks at Google's support team). That's it: you'll see countries compared against one another to understand relative priority (more on that below).

Important Note: These segments are based on where a user is located when they access your content—not which TLD or language they chose to access. We definitely see users in Germany access English help center articles. But in general, this is great directional data.

Bonus: This report is especially nice to run when a language spans multiple countries. For example, when we want to understand German language content needs, we pull in Germany, Austria, Switzerland, Luxembourg, and Belgium.

 

5. Give your global users a feedback channel.

I've written about the importance of collecting article feedback before, and the same principles apply across a multi-language system. Since your non-U.S. audiences are likely to be smaller (for U.S.-based companies), paying attention to what's getting the most user feedback is especially important.

You can use Google Translate to get a rough idea of any article feedback provided in languages you don't speak (for example, maybe a customer is just reporting that an image or link is broken—you can probably fix this without speaking a word of Dutch).

I'd also strongly suggest using a "request this translation" feature if you aren't translating 100% of your English source content. You can allow users to access the URL for their TLD with a message letting them know you're providing the English content because their requested locale isn't available—but they can ask for the translation.

At Eventbrite, this is a simple email request system—an email template clarifying the content title and requested language is sent to an alias for our content team to handle. Receiving messages like this helps us understand what content is in demand in a particular locale. 

Since we translate most content, we don't get these emails too often and therefore we haven't built out a more robust request system—but if you want to take a conservative approach on what you'll translate, a system like this can really help you know what to focus on.

 

6. Prioritize what gets worked on.

If you care about customer experience outside your primary U.S. market (and I'm assuming you do since you're reading this), one of the hard truths to swallow is that your secondary markets simply won't get the same amount of resourcing as your primary market.

The ideal might be to get these locales to "U.S. quality," but if the market represents 2% of your help center user base, it's hard to justify spending the same amount of time or money on that content.

All of these tips are meant to help you stretch your resources further for your customers around the world—but at the end of the day, the best way to make sure you're doing the best possible job is to make sure you have a solid way of prioritizing what gets attention. At Eventbrite, we consider:

  • Issue sensitivity. Any content that covers topics like money or legal issues floats to the top of our hit list. You do not want to mess that up.
  • Pageviews. We look at global performance of our articles to determine the top articles our customers need. At one point I looked at the top articles across all of our locales and there was so much overlap in what trended as important that just 20 total articles covered every country's top 5 articles.
  • Customer feedback. If you're getting a lot of article votes and/or feedback, bump that content higher on your priority list.
  • Content age. The older an article gets, the more likely it's in need of an update. You'll have to judge "how old is too old" based on how much your product or service has changed.

Prioritization is even more important if you're thinking about localizing screenshots, which can be a massive amount of work if you don't have an automated system for it. One way my team mitigates this is by ensuring that our screenshots are always as focused as possible—we don't show the entire user interface if we're only referring to a third of what's on that page. We show enough context to be clear while restricting what's shown as much as possible since the product changes constantly. And we reuse screenshots as much as instructional phrases to ensure upkeep is manageable across the board.

 

Localization is a balancing game, and the most important thing is having an equally strong sense of global customer experience standards combined with a strong sense of what's logistically viable. Without the former, your customers end up feeling deliberately second-rate and without the latter, you'll never stop throwing money at a problem. Fight for both and you can win the world over.

 

Make User Feedback a Real Conversation

Embracing a healthy user feedback community as you develop a product says you're serious about meeting user needs, and it can hands-down make the difference between a flourishing product and a mediocre one.

Ever since I beta tested GatherContent's system, I've been enamored with trying out new products and giving user feedback to the companies behind those creations. With GatherContent, I've basically become the definition of a brand champion.

The product is great (and it just keeps getting better all the time), but what really got me invested—what keeps it top of mind as something I regularly advocate for among other content strategists and designers—is that the team embraced me as a valuable contributor to their development.

Did they implement all of my ideas? Of course not. Hell, at some point I probably asked for a unicorn to dance across the screen.

What they did do is acknowledge all of them, giving me insight into how the product is being developed and why. I was invested and I loved it. I happily became a paying customer when they transitioned to a subscription model.

This month, I've been trying out another web app, Sprintly, for agile project management, and it's showing a lot of promise (besides being the best looking PM tool I've seen to date). And after my experience with GatherContent, the presence of a customer feedback community was part of my decision to try it out. While the app itself has a lot going for it, their user feedback community has left a lot to be desired.

 

Not all feedback engines are created equal.

First, let me say that having a customer community at all is a huge improvement over more traditional methods of customer service. That said, building a community around improving user experience should itself be a solid user experience.

GatherContent used Get Satisfaction as their customer feedback community, and while it’s not a perfect tool, it provided the features necessary to facilitate our productive dialog. Giving feedback comes in four forms:

  • Ask a question
  • Share an idea
  • Report a problem
  • Give praise

These are the most common ways I want to interact with a product I'm using, and keeping it all in one community—where employees and customers alike can respond and discuss items—is beautifully simple and effective.

I've never been a fan of being forced to search community-supported forums for answers because they're usually bloated and difficult to parse, but Get Satisfaction has provided thoughtful paths for getting exactly what I need out of an interaction.

UserVoice, on the other hand, differentiates between types of interactions, creating a disparate community in the process:

  • Contact support submits an email (moving a conversation about problems to individual inboxes instead of the community, where everyone could learn from a single conversation)
  • Give feedback is a way to submit ideas within the format of "I suggest you..." Most people ignore the prompt.
  • The Knowledge Base provides topics and FAQs that help you get up and running and troubleshoot. Unfortunately, several of these articles are repetitious (e.g., the categories FAQs and Getting Started cover many of the same issues in separate and slightly different documentation articles).
  • There's no encouragement to provide praise. Sad. There are lots of good things to be said about Sprintly so far!

 

Let your customers help you.

I first realized that my ability to communicate in Sprintly's UserVoice community was limited when I noticed that there wasn't a way to comment on documentation articles. These items allow only two responses: "This article was helpful" or "Flag this article as inaccurate." What I was reading was helpful and accurate, but most of the time I had more questions or knew I could add information that would be helpful to other users.

After several tweets, UserVoice eventually told me that clicking "flag this article as inaccurate" would allow me to provide feedback to the company (I tried this out and it did what I'd originally expected: marked it "flagged" but didn't provide a way to give more details. Oops.).

They also said that these options made dealing with comments easier to sort through on the support side (fair enough). But flagging has the connotation that you're sounding the alarm, so why would I anticipate using this to give comments (even if it did work)? Forcing a user to say something is inaccurate in order to add depth to the information seems completely counterintuitive.

Instead, providing a way to capture and embrace the knowledge, experience and time of your enthusiastic users is the best way to develop a vibrant and useful community (and customer base!).

 

Know exactly what to sell your customers, without even asking.

One day in Sprintly, I was adding new stories and trying out features, finding answers to my questions and happily voting for and creating ideas in the community… when I was cut off.

With UserVoice, participants have 10 points they can use to vote on existing ideas or add new ones. After you use them up, all you can do is view information and add written comments to existing items. Essentially it restricts users' voices to a certain volume, which makes me wonder if a volume knob would've been a better glyph than their megaphone.

But I get it. I can be overly talkative. I have a lot of thoughts, and they're not all diamonds. There's a need for balance in understanding what your user base wants as a whole. But really, you're completely cutting me off from adding ideas to the pool? Ideas that the builders behind this app might really want to tap into? You know, when I'm telling you exactly what to sell me?

I'm all for prioritizing the highest-value features before spending resources to create something that might just be a crazy idea that totally fails, so limiting how many votes a user can cast is fine by me.

But limiting user feedback, particularly if it has to do with new ideas, only serves to mute the conversation.

User feedback is a rich (and free) brainstorm that can make the difference between a decent product struggling to figure out how to improve and a fantastic product that gives users exactly what they want and need.

When all is (hopefully) said and done, companies are more than capable of prioritizing this feedback themselves, letting the weak ideas fall by the wayside and building upon the strong ones. Asking users in your feedback community to cull the pool is cutting potential off at the knees.

 

The outspoken will always find an outlet.

Before social media, customer service was primarily about managing angry customers, if not in person then by phone or possibly email. And to be fair, complaining on Twitter may be the fastest way to get resolution from a company.

But this doesn't have to be the whole conversation anymore, and we shouldn't limit ourselves to managing problems.

Stubborn vocalists like me will turn to mediums outside of the immediate customer community to connect to the people behind the product. I've been tweeting at Sprintly's founder since I was cut off by UserVoice, and to his credit, he's been super responsive. But he shouldn't have to manage feedback in so many places—it's not efficient and it's not collaborative.

I recently discovered that I could even work the system and create another user profile from which to start all over with points, but I don't want to hack it. I want it to be better. UserVoice may be more than a helpdesk, but it's less than a community.

The bottom line is that, as with anything, everyone will have opinions. The question is what you do with them. Your perspective on how to handle user feedback (and which user feedback community to choose) could be the difference between your product being loved by many or tolerated by few.