Let’s start by dissecting a multi-sided service platform using WELD. Choose your own adventure here. You can choose Angie’s List, Airbnb, Rover, or whatever you like. The main thing to remember is that all of these systems provide a few key features. 1. Matchmaking 2. Payments 3. Service listings and Ratings. 4. Search features 5. Mapping/Proximity. They may also offer insurance, loans, or other perks but those ancillary services that attract service providers or customers are not as essential for our conversation.
The essential functions of the platform we are interested in are: to serve as a trust agent, matchmaker, and payment processing service for both the service providers and the end customers. The reviews from the platform serve as an advertisement mechanism for the service providers and a guide to end customers to find the price, quality, and proximity of the providers.
Since I have none of the data I recommended reviewing before you do a customer journey,y I’ll jump right into the mapping of the data and customer journey. I’ll walk through the process of the customer journey for both the service providers and the customers and show how each of the main ingredients is affected by localization.
Service Provider
The service provider is listed on the site because it is a low-cost and medium-effort way to find viable customers.
Listing: The listing for the service provider is their advertisement. This is usually bolstered with ratings and customer testimonials.
Payments: The payment processing alleviates the service provider from having to set up their own payment processing system.
Customer acquisition: The platform allows the service provider to acquire and retain customers at little to no cost.
End Customer
Service: The end customer can go to one place to find all the necessary service providers. There is usually a phone app or other simple method for searching, communicating with, and paying providers. This will need localization and internationalization and this work will come with a lot of issues that will need to be solved.
Ratings: The ratings serve as a sorting and validation mechanism for the customer.
Payments: The app or website handles the payment process and a one-click mechanism for payments.
Platform
As the famous flywheel effect drawing above shows the matchmaker and payment processes of the platform serve as a growth engine for the multi-sided platform. The flywheel effect gathers more providers and customers as a company’s mindshare grows and if the selection, and payment process are frictionless they can grow quickly. Another way for these multi-sided platforms to go global fast is to find competitors in other regions and absorb their providers and end customers.
In the upcoming Wag! and Rover.com battle we will see this played out over the coming months. Both startups are well funded (Wag- Softbank, Rover- T.Rowe Price) and though they aren’t direct competitors now they will be. Rover’s recent acquisition secures an EU presence and a head start in Europe. The obvious move for Wag is to expand into Asia and Southeast Asia and if Rover is paying attention they will prepare a counter-move. Either of them may look to acquire service providers and end customers through purchasing Cannoba dogs from Interole in Japan, or Petbacker in Singapore to get a foothold in those markets. But either would also be taking on a lot of work to integrate these new languages into their current platform. It is something I may revisit at the end of this post.
But I digress, let me return to the flywheel. Organic growth can come from the flywheel effect, but the multi-sided platform needs to support this growth in the language of origin as well as every other language that will lead to global dominance. And to do that they need to understand what they store, display, and every interaction with the customer. In the sections that follow I will illustrate the WELD principles at work on Rover.com. I’ve chosen to use them because they will provide concrete principles of the processes I discuss. One could easily perform this process with any other multi-sided platform a stand-alone product.
The majority of the features that follow are to draw and keep service providers and end customers. However, at the end of the list will appear a set of features that don’t add value to the customer base but are essential for the livelihood of the platform itself.
Matchmaking
At their core, these multi-sided platforms provide matchmaking services through discovery, ratings, proximity, or affinity, and each of these will present challenges as you add new languages and locales. In the following sections, I’ll break down each and help you understand what needs to be done for new locales.
This examination will only look at the platform from the customer side. I won’t sign up as a service provider so I won’t be able to examine that process in depth. The process however would be very similar. I’d walk through the signup and evaluation process and identify issues that must be addressed for international expansion.
Service Listings and Rating
The listing and rating page as shown below has the introductory data about the user and serves as their marketing page. It is also a page that displays end-customer comments. So character encoding, backend databases and services, fonts, and the UI should all be evaluated for new languages. If it is a native app there will be a lot of UI localization and support built into the front-end. However, run-time content and dynamic content injected from the backend will create consistency challenges across the app. Common issues are a mixed language experience, or munged characters due to inconsistency across the app and platform.
Text: The text direction may be an issue for supporting right-to-left or double-byte languages. The UI itself may be easily mirrored but content in the app may not be as easily supported in different scripts.
Input method editor: Since this is a system that will be capturing a lot of input you may also need an input method editor for capturing Chinese, Japanese, Korean, and Indic characters.
Images: The images shouldn’t be too difficult to support, but depending on where the platform is viewed there may be geopolitical issues to contend with.
Ratings: Ratings may need explaining or there may need to be some cultural adaptation necessary. Though the star ratings are ubiquitous now, there may be a more appropriate way to display ratings depending on the locale where the product will be deployed.
Sorting and Ordering: Sorting and ordering logic are often locale-specific. So they will need to be evaluated for linguistic issues in new locales and there may be some implementation of i18n components for backend content. For example, sorting and ordering in Chinese and Japanese is done by the radical or the prevalent strokes in a character. This would be partially handled by the native app for the UI, but it would also have to be built to support content.
Character support: Front-end capture and display, as well as back-end storage and retrieval of content, should be evaluated for issues. Make sure these are all set to Unicode (UTF-8 is a good start). Any transformations of the characters performed by services should be evaluated to make sure they do not cause issues for the text.
Fonts: Font support for double-byte languages (Korean, Japanese, Chinese), and right-to-left languages (Arabic and Hebrew, Urdu. etc) should be investigated to make sure they are supported by the app or website’s chosen fonts. And that the sites are legible.
Currency, date, time: ICU and CLDR should implemented at the code level to handle currency, date, time, sorting, ordering, and locale-specific issues. This would probably be handled for some of the content by the UI, but a second implementation may be necessary. Laying an appropriate foundation for i18n will speed development and prevent development teams from creating custom solutions that will need to be revised as you decide to support more locales. Internationalization best practices will help address many issues and make your code localizable.
However, I have a specific call out from using ICU in the past. Message format sounds like a great idea to reduce localization and allow your code to handle some of the pluralization and a few other grammatical issues. I have found that it is not well supported by localization tools or localization vendors. It will introduce a series of run-time errors that you will not be able to pinpoint or be able to QA. Don’t depend on message formatting in your production releases until the format has been overhauled and it has gotten much better support from the localization industry.
Privacy: Privacy law is complex and location-based. In the US there is a vacuum that will lead to state-led privacy laws like the CCPA. In Europe, the GDPR will mandate and drive behaviors, disclosures, and consent requirements that will require configurable privacy components that can meet the demands of new legislation and new rights for users. And data residency and data localization laws will restrict where content is held, accessed, or processed.
Search
Search will be a combination of radials, drop-downs, fill-ins, checkboxes, and sliders. Each of these will require an evaluation. Does the UI need to be mirrored? Is there sorting or ordering that may be affected by the locale? Are the dates and times displaying correctly for the appropriate locale? Are the choices in the check boxes relevant to the current locale? Do there need to be new choices based on a specific culture?
Mapping
Mapping should present few if any issues. Since this is using an API from Google Maps or another mapping any localization would be handled via the mapping service. Google Maps explains it in a Google post here and there is even a demo that can be reviewed to see the choices at work.
The major call out for any service you are calling is you should have a clear idea of the parameters you need to pass to get the correct locale. You’ll need to make sure your development team is aware of how to pass those parameters and how to troubleshoot issues from these integrations.
Payment Processing
Payment processing is another one that you will probably depend on an API to handle. Most likely you’ll use Stripe which has currency support for 135 currencies. They have also teamed up with Gengo to start offering your checkout in eight languages. But you’ll need to make sure your listings pages match the translations they provide for the checkout or you will confuse your customers.
If you are using a payment provider other than Stripe to ensure your customers can pay in their preferred method you’ll want to review their documentation and make sure your listings match the payment translations you provide elsewhere in your product.
Demand Gen/ Transactional emails
Demand gen and transactional emails are the lifeblood of the platform. They are used to nudge customers to return and provide information related to their interactions with the platform. Since this is the most important and ongoing interaction with customers the quality requirements for localization here should be the highest. And of course, they represent some of the largest challenges for development.
These emails are tricky because rarely are they in a marketing system like Marketo or Magento or a CMS. They may be hard-coded in some legacy system that is no longer actively developed. And even if they are actively developed the chances are good these are owned by a development team that doesn’t actually manage the localization. So you’ll need to track down not only the team providing the localization and the development teams deploying it, but there will most likely be copywriting teams, legal, and privacy teams all involved in these emails and even the slightest change will bog down your work for weeks or months.
And of course, you should document the process and figure out how to address updates and the content life cycle process for all of this content. It will be the source of your most highly visible customer-facing mistakes so it is worth extra diligence to get these right.
Walk the site to find the issues
I recommend you walk through the process of purchasing the service or product you are selling as a method to identify the issues you need to address. I’ve done that in this example on the customer side to illustrate what I mean. But each use case and each process will require you to do this. In this particular case, I did not walk the site of being a service provider. To do that I would need to sign up as a service provider and review the full interaction and communication stream from that process. Once I’ve done that I would have a fairly comprehensive view of the customer journey and the platform’s interaction with that customer base.
The walk-the-site process from a customer journey coupled with an understanding of the data journey of collected, referenced, and rendered content will be a roadmap for your team. It will be a huge step in understanding the scope of the Whole Enterprise Localization Design you need to accomplish to make localization a sustainable and manageable activity for your product. With that process, you go from rushing to get a single localized product out the door to identifying what it takes to make a fully sustainable product or company-wide process for launching globally.
Because I’ve enjoyed this process I’ll post again looking at a Live Ops product. Live Ops is interesting because they are business-to-business platforms providing metrics, services, and storage for in-game processes and assets.
