TMCnet - World's Largest Communications and Technology Community




E-Sales E-Service Feature Article
November 2000


Globalizing E-Support: Avoiding The Headaches, Reaping The Rewards


When you compare the costs between supporting customers via a call center and via the Web, it's clear why so many companies have adopted e-support strategies to slow escalating support costs. Fully loaded, it can cost your business $30, $50 or more for call center staff to answer the phone. If your customer seeks self-help by logging onto your Web site, the cost can drop significantly, to less than $5 per incident. At General Electric, where the Consumer Appliances business alone fields more than 20 million sales and support inquiries a year, CIO Gary Reiner foresees cost reductions of more than 50 percent by moving support from the phone to the Web.

But dramatic savings aren't the only driving force behind this changing mode of support. Increased customer satisfaction is key. Customers like the empowerment, the single point of contact and the opportunity for instantaneous resolution 'round-the-clock.

Until now, most companies have provided electronic support in English only. But global customers are escalating their demand for e-support in their own languages. Just as they prefer conversing in their native language when receiving support over the telephone, customers want frequently asked questions (FAQs) and knowledge base articles in their native languages as well.

Just how significant is this demand? International Data Corporation projects that by 2001 at least 60 percent of Web users will be coming from outside the United States. Studies by U.K. research firm �quip indicate that a significant portion of those Web users in European and Pacific Rim business communities will be unable to cope with the English language on the Internet. These same studies show that productivity suffers when Internet users are forced to work with untranslated information. In short, your non-U.S. customers prefer speaking, reading, using software and troubleshooting problems in languages other than English. If your market demographics indicate that a growing percentage of your customers live outside the United States, your company will need to globalize its e-support.

Tackle Globalization With Experts At Your Side
When you begin the process of globalizing your e-support site, don't let the sheer complexity of the task discourage you. Successful globalization programs start with a well-defined process. More important, do not try to do it alone. Select a business partner with the expertise in critical areas such as internationalization engineering, localization, connectivity, workflow and language management to help you make it work.

Start With The Elements Of Your E-Support Site
The globalization of your e-support site will need to be addressed at three levels: 1) the user interface (UI) to the support site; 2) e-support applications running on the site; and 3) the underlying content. Each of these three elements must be evaluated for internationalization, meaning each one's ability to handle languages other than English, especially 16-bit Asian character sets.

Any modifications you make to your site to accommodate globalization must take place at the source code level. Architecturally, you do not want to create multiple versions of source code because maintenance will become complicated and expensive.

The User Interface: Does Your User Interface Support English Only?
The ideal user interface is one that is available in the user's preferred language. While language choice will eventually be handled by content negotiation between the user's client and your server, it is still far from reliable, which is why Web sites use manual options for language selection.

The flag was initially the most commonly used symbol for language selection, but that has changed. Companies now realize that some languages (e.g., German) are spoken in many countries while in some countries (e.g., Switzerland) many languages are spoken and for purposes of e-commerce in particular, knowing where users reside is essential. There are a few options for implementing a language choice: having a language menu on the home page (probably the most common nowadays), having a language menu on all subsequent pages (if the user enters through a URL other than the home page) or using a staging page (which takes the user through an extra page to designate language choice). Of course, once language selection is defined, the UI itself must support the character sets of those preferred languages. It will do little good to implement a language menu and/or store Japanese data if there is no way to view the information properly. Similarly, the architecture of your site needs to accommodate multiple language versions of the data. Internationalization and localization is key in designing your Web site to meet the UI requirements of your global market.

The E-Support Applications: Does Your Search Engine Recognize English Strings Only?
There are a host of knowledge base platforms on the market that were originally developed to support English content. This was adequate for English-speaking customers seeking e-support, as the search engines were designed to seek out English language strings. But when you create and maintain localized versions of your knowledge base, your search engines must be adapted to recognize non-English character strings and search multiple multilingual databases. Otherwise, the results of any search will be unreliable, either returning inappropriate answers or returning no answers at all.

Regardless of the knowledge base application you're using (home-grown or off-the-shelf), make sure it supports multiple languages, including double-byte languages such as those spoken in Pacific Rim countries.

In addition, whether you exchange support information with your customers via e-mail, forums or chat applications, these functions also need to be internationalized. Many companies learn this lesson the hard way -- a customer in China may send an e-mail in Chinese requesting support. The customer waits in vain for a reply to a message for help that was never received.

Today's e-mail engines are sophisticated enough to seek keywords, search the knowledge base and recommend answers. But even if you have localized the knowledge database, if your e-mail system is not internationalized, your auto-response function will not function properly. The search will fail because it cannot process the data. All your applications must be audited for internationalization to ensure all methods of support are enabled for multilingual communication.

The Underlying Content: Do Your Data Repositories Speak Their Language?
E-support content encompasses everything from frequently asked questions to white papers, technical tips and technical articles. Data may be pulled from a single knowledge base or multiple databases throughout the enterprise. Large e-support sites -- such as those of IBM, Dell Computer or Hewlett-Packard -- typically contain 100,000 to one million pages of content and require as many as 250 daily changes. The sheer volume and velocity of new content and revisions rule out a purely manual approach to localization. Content can be addressed in two stages: 1) localizing the backlog or legacy content (you may wish to select only frequently accessed content); and 2) streaming or maintaining localization of new and changing content.

While the huge volumes may seem daunting, localizing the backlog content is straightforward, requiring the appropriate language and engineering resources to do the job through batch processing. The real challenge is in localizing content on the fly when new articles are added or existing articles are amended in the knowledge base. In the case of urgent revisions or addenda -- such as product recalls, safety hazards or new viruses -- turnaround times could be needed as quickly as four hours or less.

The best strategy for coping with the demands of volume and velocity is to translate content once, from the central repository. Using language management tools, the translated text strings may then be reused, minimizing costs and maximizing the speed of maintaining a fully localized site.

Get Everyone To Buy In Before You Start
Before you can implement any globalization process, you have to lay the appropriate groundwork. First, you need to scope your existing environment: user interfaces (browsers), knowledge base applications (search engines), e-support applications (e-mail, forums, chats, etc.) and content repositories (databases). If they cannot accommodate languages other than English, you will have to internationalize the code. You may want to select a partner to assist you in architecting your site to accommodate the demands of multilingual support. The engineering work to implement the plans can proceed in parallel with the global team building required to make the ongoing process a success.

Second, you need to choose the members of your global team. Lead support personnel in each of your representative geographies should be included in this team. Their role is vital to understanding the specific requirements of the customers in the countries you plan to e-support. You may choose to include a validation cycle of the local language versions of these files before they get posted to the knowledge base. What will the process involve? Determine what elements of the support content are country- or language-specific, such as part numbers, product availability and warranties. Determine what organizational redesign is required to implement an effective global e-support strategy. To maintain worldwide brand consistency, meet turnaround demands and keep costs to a reasonable level, a more centralized approach may be the most effective option.

Third, you need to define a logical plan for systems implementation. Integrating localization processes into the pre-existing content management environment mentioned above will require systems-level expertise from your localization services provider. Selecting an experienced partner with a proven track record is an important element of success.

Fourth, you will need to localize the backlog of content. Since you most likely have localized products, documentation and Web content already, your globalization partner may be able to leverage existing content by using a translation memory strategy. Your partner will recommend establishment of glossaries and style guides to ensure optimal quality of localized content. Once the initial batch of content is localized, your maintenance strategy will take over. Identification of new and changed content will trigger the ongoing process of maintaining your globalized e-support site.

A well-planned strategy and investment in the these first four steps will minimize the headaches that might occur during piloting and going live with your multilingual e-support site.

Automate A Logical Workflow For Localization
As changes occur in the source repositories, tools to monitor the dynamic flux of information can automate the identification and extraction of the new and changed content. There are tools available that can read the meta data associated with the content elements, flagging those they identify as having new and/or changed content. Agents look at the parameters of those files identifying turnaround times and language requirements and then transmit the data to the appropriate localization workflow -- platforms which automatically route the files through the appropriate localization process. The system first searches its translation memory database for identical text strings and reuses them in the new context. If no such strings exist, the new text strings are routed to pre-selected human translators; translated and reviewed for quality assurance, legal and marketing ramifications (or whatever criteria you've designated); validated for technical accuracy; and then re-inserted into the multilingual knowledge bases.

Pilot Before You Launch Full Scale
No transition is flawless. Start the globalization process by piloting a subset of content and a subset of languages. Work out the bugs that are likely to occur: like a glitch in the code that displays all the articles in Japanese, but displays the titles in English. Once you've ironed out the problems during the pilot phase, you can begin to roll out the full-scale multilingual e-support site.

Most companies find that as soon as they announce localized e-support in a core set of languages, the rest of their global customer base demands parity. If your company is truly focused on customer satisfaction, globalizing e-support has to be an integral part of the equation.

Reap The Rewards Of Globalizing E-Support
Statistics show that support is the number one reason a person uses the Web today. Since e-support is often your customer's first experience on your Web site, it is important to ensure they have a positive, personalized experience. Local language provides a draw and is proven to increase the likelihood of buying additional products and services. It also increases the chances your customers will return to your site as the primary source for technical assistance, freeing your call center support staff to devote more time to handling complex problems that require live assistance.

Katrina Teague is vice president, Multilingual eSupport and eLearning Solutions, for Lionbridge Technologies, Inc.

[ Return To The November 2000 Table Of Contents ]

Second-Generation Technology Will Unleash The Global Potential For Business-To-Business E-Commerce


With so much hype focused on the potential of the Internet to transform commercial relationships in the past year, it's easy to forget that the business-to-business (b-to-b) e-commerce transformation has yet to become a reality.

This is especially true in the world of global business-to-business buying and selling, where the Internet's technological capabilities remain largely untapped. Current solutions ignore these facts: roughly 80 percent of commercial purchases are for strategic goods and services central to a company's core mission, and very little of this activity is taking place online. That's because such purchases typically require a series of negotiations spanning several months, with considerable give-and-take over such matters as quality, reliability, service, shipping, performance incentives and, particularly on international sales, payment terms.

These first-generation solutions were designed for trading in office supplies and other nonstrategic MRO (maintenance, repair and operation) commodity goods, since price and availability are the key issues in such purchases and domestic suppliers are readily available. But the Internet is an incredible engine for facilitating information exchange, and using it only to automate auctions and execute real-time price matching is not where the real value is added in b-to-b e-commerce.

These parameters cannot be accommodated by the data management capabilities of first-generation e-commerce systems. Analysts at the Aberdeen Group refer to this inability to facilitate complex purchasing activities as the "pain point for Net markets," a glaring inadequacy that "limits the usefulness of the Web as a tool to design and manage efficient supply chains."

Yet for the future of b-to-b e-commerce, strategic buying and selling is where the action is. In terms of dollars, the market is four times the size of MRO sales. Equally important, the Internet promises to provide the means to develop more dynamic commercial relationships -- and do it on a global scale. To support ongoing, sustainable commercial customer relationships, b-to-b e-commerce solutions must be able to store and manage a wealth of complex information for both sides of the transaction. Anyone who has been involved in negotiating the purchases of strategic goods and services knows that this is an incredibly data-rich environment.

What the market needs (and will soon emerge) is a second generation of b-to-b e-commerce systems, technology that is built from the ground up to put Internet capabilities in service of the complex commercial relationships and artful dealings involved in the purchase and sale of strategic goods and services around the world.

Second-generation systems will feature powerful data management and data sharing tools that will allow companies to conduct virtual negotiations, however complicated, with commercial partners anywhere across the globe.

Some fundamental requirements of second-generation systems include:

  • Malleable technology that conforms to the individual company's business model, rather than imposing one of its own, and which accommodates all of the rules and parameters of a given purchasing activity,
  • Architectures based on a shared-data model, where all of the information relevant to commercial relationship management, including each iteration of a negotiation process, is captured in a master database accessible to all authorized parties,
  • Security features included as part of the system's original design so that access is tightly controlled and specific categories of data can be tagged for automated delivery to authorized individuals as negotiations evolve, and
  • Instant generation and review of common, legally binding commercial documents, including sales terms, master purchase agreements and, for international sales, standard international trade terms and payment methods.

If second-generation systems can meet these criteria, businesses will be eager to evolve commerce to e-commerce. That's because such technology would expedite the often cumbersome conventional negotiation process without requiring any fundamental change of business principles or methods.

The problems that beset conventional negotiations are rooted in data management and communications issues that leave them vulnerable to delays caused by human error, misunderstandings or outright deception. For example, they rely heavily on face-to-face meetings in which issues under negotiation are usually set out on a piece of paper, or several hundred (or even several thousand) pieces of paper, and communications between sessions routinely involve an unmanageable m�lange of faxes, phone calls and e-mail messages.

Consider just a few of the advantages of a system in which negotiating parties can have access to whatever data they need literally at their fingertips -- before, during and after a negotiation process.

The data could include:

  • Product information, including everything from "form, fit and function" requirements and sample availability, to ISO standards and other specification information,
  • Availability information, such as lead time, volume requirements and schedule changes,
  • Shipping information, including standard and optional delivery terms and domestic and international "terms of trade,"
  • Domestic and international payment methods, including credit arrangements, wire transfers, letters of credit and partial payment schedules, and
  • Service requirements, along with repair and replacement warranties.

All of these data would be automatically updated by the technology at every stage of the process and then distributed to the negotiating parties, with the system preserving each iteration for instant review and resolution of disagreements.

Without such a system, everything is done on paper...somewhere. All that history resides either on paper or in people's heads. All too often on the day an agreement is signed, the volume requirements are either too low or too high. Going back and trying to make changes against these unstructured data is hugely inefficient and leads to lots of problems with performance because it's so difficult.

With such a system, rather than ending up with a static document requiring lengthy and tedious manual modification, the resulting contract becomes a live, working manifestation of the relationship, a framework for guiding daily interactions among commercial trading partners, with its data easily fed into internal systems to monitor contract performance and management. For example, the system could be directed to automatically detect when purchase quantities have reached the threshold that activates a volume discount negotiated in the contract.

These are just a few examples of how second-generation solutions can turn the vast potential of b-to-b e-commerce into a reality.

It's pretty clear that what we've seen so far is only the beginning. The real promise of b-to-b e-commerce solutions is just now gaining momentum. The opportunities to deploy new e-commerce technology to enhance commercial customer relationships on a worldwide scale are as vast and varied as the businesses this technology will transform.

Jeff Conklin, founder and CEO of TradeAccess, is the inventor of TradeAccess' negotiation platform for which numerous U.S. and international patents are now pending. TradeAccess develops negotiation technologies that enable buyers and sellers to conduct negotiated global transactions online at reduced cost and in less time.

[ Return To The November 2000 Table Of Contents ]

Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].


© 2024 Technology Marketing Corporation. All rights reserved | Privacy Policy