Room

• This term defines a physical room in a property
• Each room is uniquely identified by a room ID
• Other parameters include the Room Type, uniquely identified by a Room Type ID
• Room Type is a unique list of room names used on Booking.com (examples include Standard Room and Queen Room)
• The Room Type is what is shown on the front end
• Each room has a maximum number of adults and children defined, which we call the Maximum Room Occupancy

Rate

• Rate Plans are labels used to categorise or name a price (examples include Best Available Rate and Non-Refundable Rate)
• Each rate is uniquely identified by a Rate ID
• Sometimes a property can set up rates with parent-child relationships (for example Non-Refundable Rate is a child rate of Best Available Rate)

Room-rate/product

• A Room-rate or a product is what we actually ultimately show to travellers on our platform
• Various attributes are assigned to a Rate Plan to make it a product, including a room ID, prepayment and cancellation policy, meal plan and channel (the channel defines which segment of users can see the product on our platform, such as Genius users, Business Bookers and mobile users)

Updating rooms, rates and products on Booking.com

• Every property needs to create a shell of rooms, rates and Room-rates in order to be listed on our platform
• Rates and Rate Plans are not the same as prices
• Rates are never deleted – only products are

As a Connectivity Partner, you can use the Room and Rate Management APIs to set up rooms, rates and Room-rates on our platform

Inventory

• Inventory is a count of the physical rooms that the property wants to sell on Booking.com
• Inventory is always defined at the room level (although in the past we offered rate-level inventory)
• The value used is Rooms to Sell
• Rooms to Sell are defined for a certain date range and for a certain room ID

Room Level Inventory (RLI)

In the above example, we can sell 10 rooms at both the Standard Rate and the Last minute Rate.

Restrictions

Restrictions define the conditions at which a room can be sold at a certain price – this essentially defines when the room becomes bookable by travellers. On our platform, all restrictions are defined based on the length of stay.

Connectivity supports more restriction types than the extranet, and the most popular restriction is minimum length of stay. Others include:

• Minimum/maximum length of stay: this sets the lowest or highest number of nights travellers can book a property or room for
• Minimum/maximum advance reservation: this sets the shortest or longest period in advance when travellers can book a property or room
• Minimum/maximum length of stay from arrival: this sets the lowest or highest number of nights a traveller can book for
• Exact stay: this sets an exact number of nights travellers can book a property or room for
• No arrivals/departures: this closes the property or room for arrivals or departures on particular dates. Travellers can’t book stays that start or end on those dates, but they can still book a longer stay that includes those dates.
• Full pattern length of stay: this sets restrictions based on a pattern the accommodation partner or Connectivity partner provides

Restrictions can be defined using a combination of room, rate and Room-rate:

• The Rates & Availability API and the ’Calendar’ and ‘Rate plans’ pages in the extranet allow you to define restrictions based on a room ID
• The Room-rate Management APIs and the ‘Rate plans’ page in the extranet allow you to define restrictions based on a rate ID
• The Promotions API and the ‘Promotions’ page in the extranet allow you to define restrictions based on specific promotions
• Where there are restrictions across the room, rate and promotion levels, travellers can only book the most restrictive length of stay

Prices

• The price is the value at which a room night is sold
• A price is always for a Room-rate or a product
• Two factors are involved in defining a price: how many people the price applies to (the occupancy) and how long a stay the price is valid for (the occupancy)
• Pricing models are used to define these factors, and each API request supports a certain pricing model

On the Booking.com platform, the traveller enters the property or destination name, check-in and check-out dates and occupancy.

Image

Image

Properties with any Room-rate combination that matches the criteria below show up on the search results page. Various factors influence the ranking of the properties on the search results page, including filters the traveller selects.

• A non-zero price 
• Active rooms, rates and Room-rates
• Prepayment and cancellation policies assigned
• Rate relationships (parent and child rate mapping)
• Occupancy (influenced by pricing types)

If any of these values are missing from a Room-rate, that Room-rate isn’t shown to the traveller. If there aren’t any Room-rate combinations that meet these conditions, the property won’t show up on the search results page.

There are a few more things to keep in mind:

• Only Room-rates and products are shown on our front end, not Rate Plans
• We only display the room type
• The criteria described above aren’t exhaustive, but they cover high-level use cases

1. No prices

What’s happening: some properties aren’t visible to guests looking for a length of stay above eight nights.

Why it’s important: the Coronavirus (COVID-19) outbreak has significantly changed the distribution of net stayed commission over the length of stay. In 2019, only a limited percentage of net stay commission came from reservations with a length of stay above eight nights. According to data covering the period from March to June 2020, that number is growing significantly.

Why it happens: analysis of the properties showed that these are usually properties on a length of stay pricing model, which means that we don’t receive prices from these properties for lengths of stay above eight nights.

2. Active and inactive rooms, rates and Room-rates

What’s happening: some Room-rate combinations are not visible to travellers, as the rooms or rates are inactive on our system.

Why it’s important: the setup of Room and Rate IDs is the foundation of the setup of all inventory and prices on our platform. Why it happens: properties commonly configure their Room-rate setup in the extranet. After they’ve set it up for the first time, properties often ask us to make certain rooms, rates and Room-rates inactive. This means that, even if the property has prices and rooms uploaded and the rest of their setup is still correct, these rooms still can’t be sold on our platform.

3. Genius What’s happening: an incorrect Genius Room-rate setup results in a broken experience for Genius users.

Why it’s important: Some properties have an incorrect Genius Room-rate setup, where the Genius user making a reservation for a Genius room or property isn’t eligible for a Genius discount. Genius users are more loyal and generate on average 18% more bookings than non-Genius users, so losing out on these reservations is significant.

Why it happens: on further analysis, we identified that the two main reasons for this incorrect setup are the Genius room being inactive on our platform, and all the rates mapped to the Genius room being inactive or closed.

4. Missing policies

What’s happening: multiple Rates don’t receive the correct Room-rate assignment.

Why it’s important: without a rate or policy assignment, the rooms don’t show up on the front end.

Why it happens: a common scenario for this happening is where the Connectivity partner has implemented the Room and Rate Management APIs, which are part of the Content API. The OTA_HotelRatePlanNotif and OTA_HotelInvNotif endpoints allow for the creation, activation and deactivation of Rate Plans and rooms. The Connectivity partner  then needs to use the OTA_HotelProductNotif to assign a policy and a room to each Rate Plan. Depending on how Connectivity partners work, it’s possible for them to miss this step. This often goes unnoticed, since the Connectivity partner is still able to update inventory, restrictions and prices through the Rates and Availability API, as only the policy is unassigned and the room and rate have been mapped. In this scenario, the Room-rate won’t show up for travellers on our platform.

5. Missing occupancy

What‘s happening: we have a legacy functionality called rate level occupancy. Properties using rate level occupancy have two definitions of occupancy: one is the maximum occupancy of a room and the second is the occupancy defined at the rate level. If occupancy isn’t in fact defined at the rate level, the property can’t set derived prices. That means prices for those levels of occupancy are missing on our platform.

Why it’s important: a significant percentage of searches on our platform come from solo travellers and groups. Past experiments have shown that not having dedicated prices for these traveller segments results in a drop in conversion.

Why it happens: Because of our late release of the Occupancy Based Pricing feature, properties have had to keep using rate level occupancy, which lets them define a specific occupancy per pate and therefore a price for each different occupancy. But this setup is complex, and if properties don’t set up occupancy for a specific rate then the Room-rate for it doesn’t show up on the front end.

6. Restrictions We cover the impact on restrictions on the supply flow in more detail in lesson 3.

Make sure to take the test, so we can reward you with programme points.

Take the quiz