An article for translators: We Now Have Concrete Proof: Software Quality Issues Drive International Sales

Software developers will often spend large sums on Quality Assurance (QA) and marketing for the U.S. and Canada in order to deliver a quality product with high sales potential. Product releases may be accompanied by a media blitz and promotional deals, often followed by a number of very quick minor product updates to resolve the inevitable issues that arise after a product hits the market. Most developers do a good job of making updates and patches available and of responding to customer feedback, even if they cannot resolve problems.

When you reach non-U.S. markets, however, the picture is often very different. In many instances (perhaps in the majority of cases), developers spend as little as possible to prepare their software for international markets. They may even relegate QA and functional testing to the “nice to have” category or rely on the companies that provide translation and localization services to do quick spot checks to make sure no major problems are found. When problems are found in localized versions, they may not be fixed, even in the next major release, and there is often a significant time lag between when fixes appear in the localized versions.

Who will buy products from a company that sells a software package essentially useless for its main purpose?

As one example, a large developer of publishing software experienced a major bug in the printing architecture of a major release of its flagship product that gradually slowed printing tasks to a crawl. This developer fixed this problem in the English version within a month of its discovery, but four years later had yet to provide the same fix for its Japanese language version. What message did this deliver to Japanese users about how this particular company viewed them? While the exact business impact of this bug would be difficult to quantify, it surely had an impact on Japanese customers’ perception of the software and on the company itself.

Such problems are all too common, and they can have a significant impact on customers’ perception of software products and brands, and thus, their willingness to purchase additional product licenses or to upgrade their software. Many major software developers tolerate slip-shod QA and support for international markets that would quickly kill their brand in the U.S. When over 50% of the revenue for some large international companies comes from overseas sales, such inattention to market needs seems strange indeed. What company would ignore 5% of its domestic market – much less 50%?

So why do most companies invest so little in their international markets? There are a couple of major reasons that are mainly ones of perception that impact how tasks related to local markets are approached.

The first reason is that, until recently, localization was a task usually handled by local affiliates or partners in exchange for a share of the profits. Therefore, the developer did not handle any of the development or marketing and thus received little feedback from international markets. Although this business model has increasingly fallen out of favor, it lasted long enough to engender a mentality among developers and marketers that international needs were something “someone else” takes care of. In addition, the preferred model of localization for most organizations today is an outsourced model where localization service providers handle localization fairly late in the process. These tendencies mean that international needs are often ignored until later on (when they cost more and take longer to deal with), rather than integrated into a developer’s strategic planning.

The second major reason for ignoring international market needs is that localization is often regarded as a product-specific task, a check box that needs an X before the product can be sold. This perception is especially dangerous because when something is a simple step, the natural tendency is to cut costs and simplify as much as possible. While cost-reduction is a worthy goal, it actually makes more sense to invest a little more in localization in exchange for more sales and increased customer loyalty.

It’s not about translation – it’s about globalizing your business processes.

The other danger in reducing localization to a check box is that it severs the product from other business processes that are not localized. For example, if a product is localized into Chinese, but the developer has implemented no process to deal with Chinese-language correspondence, how will the company respond to sales queries and how will the product be supported in China? Only when companies understand that localization applies to the entire business process – and they take steps to globalize their business – will they be able to fully support all of their customers.

Returning to the example of the Japanese printing bug, there was a clear disconnect between development priorities for the U.S. and Japanese markets. Yes, the developer saved money by not porting the bug fix to the Japanese version, but that cost savings (measured perhaps in the tens of thousands of dollars) was probably a net loss in terms of decreased sales and damage to the company’s brand. After all, who would buy additional products from a company that produced a software package essentially useless for its main purpose?

Clearly, companies need to invest more in their international markets than they now do, but specific guidance for what investment to make has been largely limited to anecdotal evidence about markets. Even when companies recognize that their international customers are treated as second-class citizens, they may not know how to change the situation. Although anyone within the localization industry itself will be happy to tell their customers why they should invest more in localization, such advice typically lacks the business data required to convince development and marketing managers that it is anything other than self-serving propaganda on the part of localization companies.

There is now research to prove that quality errors in localized software products have an impact on sales.

Due to this lack of hard data, LISA partnered with IBM to create the first annual Global Software Survey in February 2005. The survey gathered data from approximately 400 business users of localized software to better understand their needs and the market for localized software. Published as Taking Software to the World, the results contained some surprises, but showed conclusively that international markets are systematically treated with less responsiveness and support than domestic markets and, more importantly, that quality errors in localized software products have an impact on sales. In addition, the survey was able to identify those software application areas where localization has the greatest impact on sales and actual business use.

Taking Software to the World: Results of the LISA 2005 Global Software Survey

Among the most surprising findings was that translation errors in localized software are typically nuisances for users rather than major stumbling blocks. However, these same errors actually have a disproportionate impact on purchasing decisions when compared to their severity. This means that what seem like minor errors in how terms are used, or problems in matching standard terminology for a particular industry, can actually have as big an impact on sales as more severe problems with product functionality. At the same time, errors in translation are significantly under-reported to developers, particularly by users outside of the U.S. Although this result seems strange, users of localized software in the U.S. are much more likely to report problems than those outside of the U.S., even though U.S. users rely less on localized software in general. According to the survey results, overall resolution rates for non-trivial functional problems in localized software are approximately 56% for individuals based in English-speaking countries, but only 38% for those based elsewhere. For translation errors, the same figures drop to 25% and 15% respectively. While companies are better at fixing functional errors, neither result is good, and there is a clear lack of support for precisely those users who most need it.

The reasons for this under-reporting of errors and lack of resolution when they are reported have to do with the way companies view localization. When localization is a “bolt-on” process – not a core business function – there is no way for customers in international markets to report problems. And when they do, there is often a lack of clarity about who is responsible for resolution: should it be the developer, the local distributor and/or the localization service provider? As a result the needs of international customers often slip through the cracks, with a resultant loss of sales and market share.

The good news? It is within your power to improve your international efforts!

It is within the power of companies to improve their international efforts, however, and the good news is that companies can make a real ROI on these efforts. Considering international needs from the beginning not only helps build market share, but also reduces costs and delays to market entry. Taking Software to the World provides a very clear roadmap for software developers who want to know exactly where to spend their localization development budgets to sell more products and for end users who purchase localized software. It includes an exhaustive ranking of software applications and their localization priorities, information on how developers should invest their global product development dollars and how internal business processes affect global product purchases.

Editor’s Note: An abridged version of this article appeared in the June 2005 edition of The SLAM Report.

Reprinted by permission from the Globalization Insider,
August 2005
Copyright the Localization Industry Standards Association
(Globalization Insider: www.localization.org, LISA: www.lisa.org)
and S.M.P. Marketing Sarl (SMP) 2005