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.

 

What's in a Name? (And Why I Hate the Word "Content")

I'm feeling angsty lately, and it's not just because of my first ever Twitter debate. I am a woman of words, but I haven't found the right words for what I do with content. I've been reading Mike Monteiro's Design is a Job (one of very few books I've given five stars) and found myself feeling out of place but in the best kind of ways.

(Okay the best kind of ways really happen in Austin, where you see things like a dude walking his dog on a unicycle. Seriously, I can't make this shit up. Moving on though.)

I'm going to bring you back to your SAT days with this analogy, inspired by a man who likes Tastykakes more than your average California resident:

Designer : Artist :: BLANK : Writer

When I say "writer," I'm talking about creative writers—you know, the kind who sit around drinking absinthe and scribbling out poetry... and hanging out with painters. These are pure artists; they create art for its own sake, not deliberately intending for it to fulfill a practical purpose.

Design (once called "commercial art" long, long ago in a land far away) take elements of art and make it work for its money. Good design can delight and challenge in the same ways good art does—but it starts with an agenda. I'd argue that art with an agenda is walking the line of design.

Writing a novel with an agenda, on the other hand, is a fast way to get bitch slapped by an editor. Creative writing that trends toward intentional messaging may be a sin, but the upside is that "commercial writing" that trends toward the artistic (think storytelling rather than fact-spewing) is desirable.

That's good news for me because personally, I prefer to create things with a purpose and I prefer to do it in a way that people actually enjoy. I love art and literature, but what I want to spend my time making is something with a goal in mind. That's just the way I roll. Unfortunately, my Dad is still telling me I need to write the next Harry Potter novel to make it big with my word skillz.

So going back to my lovely analogy. I'm the BLANK and there's good reason why I'm struggling to fill it in. The problem with the label "content strategist" is that it implies strategy only, not execution. Something like "copywriter" implies the opposite (production without high-level architecture). I do both. I love both.

I'm more than a content cow, but less than a strategic saint.

In his book, Monteiro uses the phrase "information designer" (he rails against the label "information architect") which I like better than "content strategist" because anyone who understand what real design is understands that strategic thought drives what ultimately "looks pretty." I'm not a super big fan of "information," however, because it implies pure fact and structure without the seriously important nuance of tone and feelings in addition to downright useful information.

Then again, here's another confession: I don't like the word "content."

I was so relieved at BarCamp Philly this year when one of the speakers, David Dylan Thomas, said as much during a session. My beef with the word is that it's a catch-all and I almost always prefer to be specific with my word choices. (Related: I also hate the word "specialist" for the same reason.) But, as he pointed out, it seems to be a necessary evil for now.

So if I need to stick with "content" to avoid pigeonholing myself and the word "designer" accomplishes what I intend from the strategy-execution combo perspective, should I call myself a "content designer"? Somehow it doesn't feel quite right. It feels like I should know how to use Photoshop better.

I really want to know what other people think. If you're like me, what do you call yourself and are you satisfied with that label? If you're a designer, how do you feel about me calling myself a designer of words? I know what I can do matters more than what I'm called, but as a lover of words, I want to find the right ones to convey my meaning!