In Part 1 I looked at some of the challenges of, and good practices to consider with, multi-language and multi-geography (IT) service desk operations.
In this second blog I cover some of the technology and process challenges.
Static data
Most globally-successful ITSM tools are able to cater for multiple languages, with static data such as menu options easily shown in the local language based on location, user, or choice. Bear in mind though that it's almost inevitable that some phrases in the translated versions of the tool will be quirky or even misleading. For that reason, it's important that the tool makes it quick and easy for the customer or a local partner to tweak the phrase to something with real local language meaning.
For data capture on a service desk and on an employee self-service portal it's advisable to minimize the amount of free text needed from end users and therefore the amount of real translation needed. Dynamically populated drop down options are great here.
Free text
As mentioned in Part 1, the technology will also need to translate the record's free text into English (or the corporate language) for Level 2/3 and escalation purposes. And then allow it to be updated in English by these parties (with or without translation back into the original language). Importantly, beyond the immediate utilization of records, translation will also potentially be required for trend analysis and management reporting at a global level.
ITSM tool vendors usually deal with language differences in one of two ways — either translation tables between local languages and English or the creation of shadow records that are again in English. A vendor will usually offer only one of these options.
Potential technology issues
Network performance should be proven before service desk locations and ITSM tool are agreed. As do assurances on the local availability of the technical skills required to run and tailor the solution (internal and external).
Keeping tickets in sync across geographies can also be an issue and the vendor should offer very specific advice as to how they keep both the process flow and languages in order. The tool should be able to handle time zones and the processes around time zone differences such as SLA calculations, ticket handover, etc.
Culture may also impact the technology. In the Far East, for instance, the idea of having a single ticket owner can be unacceptable. Alternatively, the ticket is owned collectively and is resolved in an "inclusive" manner. The tool needs to cater for and support this.
Process standardization and performance
While having a single, standard set of processes across geographies is great, local differences can make this nigh on impossible. Culture is highly relevant to customer interactions and management styles, but it's also relevant to processes. For instance, in some geographies we use penalty-based SLA targets where in others these are frowned upon — with SLAs far looser and advisory rather than punitive. Having said this, commonality should be pushed for wherever possible.
From a performance and metrics perspective, local norms may also mean that different individual and team targets might be applicable. Local regulations might also impact the required levels of internal control.
Looking to the future
The growth in the adoption of service catalogs, self-service, and self-help through knowledge bases offers its own language challenges. But as (IT) support and service delivery evolves to take on board new technologies and end user preferences how do companies deal with the multi-language implications of social support applications such as corporate Facebook-like walls? Maybe, as with our personal interactions, Google's translation capabilities continue to hold the answer.
