Why and how we built a Messaging API Product for Partners
Booking.com is a two-sided marketplace, where suppliers of inventory aka partners (hotels, homes, flights, cars, attractions, restaurants) are matched with their demand from travellers. Many product teams in Booking.com operate within this two-sided setup continuously striving to deliver great value to both travellers and partners simultaneously.
This article investigates the journey of solving the messaging needs of partners enabling seamless communication with travellers pre and post-trip on a platform of their choice.
Understanding the Partner Landscape
Booking.com’s accommodation business is driven by a large number of properties ranging from large global hotel chains such as Hilton and Accor (providing tens of thousands of rooms) to family run homes that are put up for rent just for a few days every year. These properties conduct their businesses - inventory management, pricing, housekeeping, customer relations, billing etc on or more of the following applications:
- Custom applications that are built by an in-house or outsourced development team for the specific property or property group
- Commercial B2B applications (channel managers, property managers) where properties use some or all of the standard functionalities provided
- Booking.com’s Extranet application — an administrative dashboard for properties to manage all their business with Booking.com
These custom built applications (1) and the commercial B2B applications (2) integrate systematically with Booking.com over the Connectivity API suite. They also often have similar integrations with other demand sources to aggregate business onto one interface.
The problem — Partners did not always have an effective mechanism to communicate with travellers
Booking’s Connectivity Suite provides a slew of API endpoints that allow these applications to exchange catalog, inventory, pricing and reservation data seamlessly. However, partners faced significant challenges in communicating with travellers effectively over these applications:
- The Connectivity Suite did not provide a mechanism for message exchange, so communications from travellers never reached their applications systematically
- Partners would then have to open Extranet just for messaging. Switching between their applications and Extranet could be laborious and time consuming
- The other channel then was email exchanges, however that is inherently slower and a much more formal (and often impersonal) method of communication
Without an effective mechanism to exchange messages over their preferred application, it was challenging for partners to communicate effectively with travellers. This resulted in lost opportunities of building trust and helping travellers make the most of their stay.
My team then set out to solve this specific problem with the Messaging API product.
Setting the product goal and tenets
With the problem identified, the product’s goal was then to:
Enable partners to seamlessly & effectively communicate with Booking.com customers & agents on their preferred platforms.
Along with the goals, it is also important to define key tenets — a set of guiding principles that defines the core philosophy behind the product. Aligning on these tenets across stakeholders — product, research, marketing and engineering — ensures positive feedback loops through the product life cycle leading to better products, higher adoption and increased delivery velocity.
Consumers and Users, and Their Needs
For the messaging product, while the property owners are the eventual users, the real consumers are the developers of the partner applications. While users would drive up usage, the adoption is primarily driven by the consumers. Also, most of the cost of the adoption (time and dev resources) are also borne by the consumers. This distinction and separation between users and consumers is important as it drives most, if not all, product decisions and Go-To-Market plans.
Interviews and focus groups with partners from various cohorts revealed the following primary needs:
A few interesting findings:
- The basic functional needs of various partners were similar — irrespective of what applications they used
- Partners explicitly called out the need for simplicity often referring to a Whatsapp like experience — indicating the stickiness and recall a product can achieve by solving a problem extremely well
- While most users prefer an API solution, some small users prefer an iFrame that can be easily integrated into their existing applications
The API solution was expected to have higher adoption & usage and was in line with Booking’s messaging strategy. The MVP was then defined as a simple yet robust messaging API suite that empowers seamless traveller to partner text communications. The iFrame solution would be picked up only after the API product becomes mature enough.
Defining user journeys for an API product
As for any product, product discovery starts at defining the user journeys. To clearly draw out the interactions between Booking, the intermediaries and the end user (the partner), I prefer to use a tweaked version of the service blueprint model. Starting from the partner’s experience and progressively detailing out the service/user interactions, the model gives a clear view of actions of each actor (whether human or machine) and the flow of information. The example below shows a simplified journey for when a partner using a property management service (PMS) tries to read a conversation with a traveller.
Doing this for each user journey starts shaping up the core capabilities that are needed in the overall product. Each user journey can then be further detailed with comprehensive requirements covering all happy and unhappy scenarios for development & testing.
Going live with a solid GTM plan
A fresh new API product requires significant investment from the users in terms of integrations, hence requiring continuous handholding and incentives to drive the initial adoption. A few key things to consider:
- Evangelise well & early - The business benefit of the product needs to be evangelised and emphasised in every communication. Key Account Managers, when available, are the best people to reach out directly to managed partners.
- MVP needs to be highly lovable - Consumers will not accept half-baked products. The MVP itself has to be rather comprehensive and very stable before partners start integrating with it.
- Adhere to timelines - With constrained dev resources, partners need to plan integrations long in advance. Hence communicating and adherence to timelines is of paramount importance.
- Identify business incentives - Often the company might provide various financial and operational incentives to partners to integrate with API products. If such an option exists, it should be part of the GTM plan.
- Hand-holding during initial days - Setting up onboarding support & comms channels early on helped us pre-empt product market fit while also boosting confidence in users and consumers about the potential benefits of this new product.
Unlike traveller facing products, such partner facing products cannot be launched by the flick of a button as an A/B experiment. Only by evangelising, convincing and handholding users and building a product that has a strong PMF at launch can adoption and usage be driven up.
What’s next for the messaging API
The messaging API went online recently. The detailed specs and documentation is accessible at this link. While the near term focus is on driving adoption and making the product even better at what it does, the team is equally busy figuring out what’s next for the product.
Booking.com has an ambitious goal for delivering a truly connected trip to travellers and the messaging API could play a significant role in the overall traveller experience by connecting messaging across hotels, attractions, car rentals and more on a single platform.
Another potential area is enabling process management over APIs so that partners can provide travellers the support they need (modifications, special requests and more) seamlessly.
Given the value of the product, it is also likely that an ecosystem of third party applications are built on top of the messaging API, collectively delivering greater value to the partner ecosystem.
As always, the team is continuously looking at feedback and suggestions from partners to make their businesses more efficient and will continue to improve upon this product to deliver a truly connected trip for partners & travellers alike.
Join us! We are Hiring..
Would you like to positively impact the way users experience the world today? Does this and the other product areas within Booking.com excite you? We would love to have you onboard. Please check out current openings on our careers site and start your applications.
