March 15, 2010
Speaking of software localisations, one of the pain points in the process is capturing localized images of the software (dialog boxes, menus, etc) for use in the documentation. To capture these screens, you first must have the user interface text strings localised into a number of non-native languages, and then incorporate these new languages in the software. Then ‘someone’ must go through the documentation and capture screens of the software in each of the languages. It is often assumed that the someone should be a member of the development team that built the software; but this isn’t always the case. Localisation vendors offer this service if you can provide them with the software and a script for creating the correct scenarios. The decision, of course, should be based on economics. Here are a few things that feed into the costs.
- Can a build of the software be easily installed at the translation vendor?
If it takes day to install and configure your software appropriately for capturing screens with dongles, license keys, etc, you’d better quantify this cost.
- Is it easy to change languages in the software?
Typically the answer is yes, but if No this could be costly with a vendor doing the work.
- Does the software need a localized operating system to display the translated user interface correctly?
Often Asian languages don’t display properly in software that isn’t running under a localized operating system. In my experience, most development teams don’t run localized operating systems for viewing and testing translations.
- Can you create a simple script and provide sample files to produce the desired results?
A translation vendor needs a script and sample files so they can properly capture the screens. It takes time to create this. Estimate how much and calculate the cost.
- Who will capture the screens on your development team?
Typically this will be a technical writer, tester, or developer. Calculate the cost of their time.
As you might have already guessed, keeping screen captures in documentation to an absolute minimum will have a significant effect on your translation costs.
March 3, 2010
I had an information interview with a colleague at a local software company the other day to discuss managing social media channels for technical support. When we first setup the meeting, he wrote me about a ‘channel management problem’:
“We used to put all of our documentation in user guides for each
product. FAQs and troubleshooting guides would be included in these
and updated with each release. If a user had a problem they would
contact us via email for support.”
“Now we have several channels for support and documentation. People can still consult the product documentation, but will often find other useful information (some not covered in the product user guide) in online forums, blog posts, wikis, email lists etc.”
“We’re now finding a lot of people asking for support (indirectly) in
blog posts, blog comments and tweets. This is really hard to manage.”
“For example, we constantly monitor Twitter for @company messages and tweets that mention us or our products. Once or twice a day we’ll find that someone has asked a question about one of our products or complained about it. This can difficult because the answer may be too lengthy for a tweet, or too awkward (e.g. a bug has been found) to respond to publicly. For those cases, we try to direct the tweeter to our product forums or email support.”
When we met, he mentioned that they’ve recently started using a twitter productivity tool that helps them manage tweets from various users at the company. But some challenges remain:
- How do you respond to tweets in other languages?
- How do you use a URL shortener (like bit.ly) to track traffic to a support resource?
- Is it useful to monitor traffic from social media channels separately?
- Is it worthwhile to implement a redditt/digg mechanisim on the support portal to get crowds to identify popular support posts?
- What do analytics reveal about documentation usage on the support site?
I’ve certainly used web analytics software on support sites to get a general sense of what topics/areas of the product are causing issues. And capturing most popular search terms can certainly tell you where users struggle.
March 3, 2010
For most software product managers I know, localisation can be a four-letter word. Localisation is the process of adapting software for non-native environments, usually other nations and cultures. Localisations take a long time and require significant development effort, but they are usually necessary if you want to sell into foreign language-speaking markets. Typically the localisations are of the software user interface, and the documentation and training materials.
While working in product development, I occasionally hear the suggestion that we can have one of the developers or field engineers that speaks the local language localise the product. Although this seems like an efficient solution, there are many reasons to avoid it; here are a few:
- Inconsistencies. Localisation vendors use a database, called a Translation Memory (TM). If you don’t have an existing TM, the localization is likely to be inconsistant. If you do have an existing TM, the developer wouldn’t likely have access, which requires the purchase of a license, their translation may be inconsistent with what already exists. Also if your company does have an existing TM, there is a cost to update the TM with the internal localisation.
- Overhead of coordinating internal localisation. Most people with experience know that this is a non-trivial task; the localisations need to be reviewed and corrected, and this all takes time.
- Opportunity cost of paying engineers to localise rather than code.
- Lack of local knowledge. The developer may not be familiar with regional variations/style.
If you are only looking at a few sentences and are in a screaming hurry, localising internally and then updating the TM is an option, but for the reasons outlined above, you may find it’s less efficient than planned.
February 26, 2010
Brian Solis’s ebook on customer service provides some good examples of organizations using social media to reach out for customer service.
From the book:
“You can bet that for every inbound customer inquiry, that there is a significant
percentage of existing and potential customers actively discussing the same
topic out in the open, simply looking for guidance, feedback, acknowledgment,
and/or information. And usually, these discussions transpire without company
participation, leaving people to resolve issues and questions on their own.”
Some organizations mentioned: Southwest, Freshbooks, ACDSee
February 11, 2010
The goal of customer experience management (CEM) is to move customers from satisfied to loyal and then from loyal to advocate. When you match customer advocacy with a social media channel such as an online community, you can end up with the customer as the service, where advocates answer questions and provide solutions to other customers’ issues. As noted in Shel Israel’s post about the SAP mentors initiative: “When customers defend a company, it has greater influence than anything a company spokesperson could hope to accomplish.” This can definitely relive some of the burden on your technical support team, but they’ll still need to listen to the conversation, even if they don’t always participate.
February 9, 2010
It’s difficult to do any research about online customer service without coming across Zappos, the online (primarily shoe) retailer with a deserved reputation for outstanding customer service. According to a recent New Yorker article, the company was sold to Amazon last summer for just under one billion (in stock). Although much of Zappos service occurs on the phone — they have no call time limits and according to the article, the record call length was five hours and twenty five minutes — the company encourages transparency, especially for employees using social media channels. Some more background on their social media efforts here: http://mashable.com/2009/04/26/zappos/ and the company here: http://multichannelmerchant.com/news/zappos_08072007/