Hotel CRS 2.0 White Paper

We have had CRS in the hotel industry for a long time, these are considered V1.

Now we look what V2 looks like and how to achieve this goal.

What is V1 Hotel CRS?

A system is considered a CRS if they have all bookings from a property on their system. CRS = Central Reservation System.

Where do reservations come from?

• Online Travel Agents like Booking & Expedia
• Booking Engines
• Hotel PMS
• CRO (Central Reservation Office) app

Current CRS don’t take the bookings created from the PMS.

Any chain or group wishing all bookings in the CRS would ban the reservation staff from putting bookings into the PMS direct and instead use the CRO tool.

Also note that any bookings modified in the PMS doesn’t update the CRS.

A good example would be if the guest stayed an extra night.

How Apps and other 3rd Party Integrations with CRS V1

Some apps work in a mostly acceptable way with the current CRS data, they understand some edge cases like extended bookings wont show. But for a CRM this is just a small inconvenience.

Other apps cannot deal with not seeing the full picture, they might need PMS specific information like what rooms that booking is currently residing since it needs to make a key.

These apps are now connecting direct to the PMS as they get all required data, Mews is a great example of a PMS with a fully open API and a great app eco system.

But there is still a need for a CRS as properties may want to use different PMS depending on their needs by size or region.

App Stores + App Exchanges

Recently there have been some companies that claim the ability to extract information from PMS to provide a CRS style app connectivity experience.

These companies come in different flavours but essentially they work in one of two ways

• PMS has to push all bookings to exchange partner and keep updated
• Partner pulls all bookings from pms and keeps updated.

As you imaging it depends which partner has most power as to who does the integration work.

Issue with these app stores and exchanges is that it is a considerable amount of effort required to maintain the booking sync.

Hapi Cloud is a great example of company in this field and they work with the big PMS like Opera, SAP and Infor.

CRS 2.0 Specifications

The idea of the CRS is still powerful, even for independent hotels. Mostly for now CRS v1 is aimed at only groups, chains and big independent hotels.

CRS v2 should be aimed at all sizes.

Think of it as a mix between the exchange platforms and CRS v1

PMS involvement in CRS v2 will be much bigger

Visual of CRS 2.0

Why CRS should take data from PMS

Before we go deeper on ways to grab information of bookings from the PMS, we should look at why it is so important. We will look why it is a big deal for the masses of hotels in the world.

Some key points:

• Most hotels use the PMS to create bookings
• Most CRO tools are expensive and complicated
• Most apps cant work well without full details, including PMS specific information like Room Numbers
• With so many PMS it is difficult to find apps unless your using a popular PMS

How to achieve the goal for all bookings from all sources into the CRS

There is a reason this has not been done before in a complete way, the original specifications were built for groups and chains and apps were not a thing back then either.

The hard part of all this is the get data from the PMS

Method 1 — Separated Mode

This is similar method to the app exchange, actually it’s nearly identical!

The PMS pushes all bookings to the CRS which stores them separately from bookings that have come from the OTA or booking engine etc.

Pros

• CRS does not need to worry about inventory changes (bookings data not affect to count of booked rooms and etc.)
• All bookings have one source (PMS) we can’t catch new bookings from other sources

Cons

• CRS will have duplications of bookings
• ALL logic about booking modifications and merge changes is handled by the PMS
• CRS should implement some separation logic to keep bookings in “separate” way

For the CRS this is the simplest method, all the hard work is dealt with by the PMS and any issues are theirs to deal with.

Apps might need some logic to see what bookings they should look at since there will be duplications.

Method 2 — Mixed Mode

Instead of keeping a separate set of bookings, all the bookings are managed centrally together.

So in the case of an OTA booking flowing from the CRS to the PMS, the PMS will send data back to the CRS to update the booking with some extra information.

Pros

• All bookings are stored in same place
• No duplications (each booking represented only once)
• Transparent history of changes for each booking (revision logic)
• Full bookings info in real state (if room type was changed and etc.)

Cons

• Potential problem with inventory (when we should update Inventory, when not), this is additional logic for the CRS
• We should solve override problem (I will describe this later)
• We should have additional logic to manage bookings where room type was changed at PMS/app level

As I mentioned earlier on the surface the separation of PMS bookings looks simpler but this passes a lot of burden onto the PMS.

Override Issue

We have the issue if there are multiple people updating a booking, what data should we keep and what data is discarded.

Overrides Problem

Apps, CRS and PMS all share the centralised booking data from the CRS. But some services or channels would not know about any changes.

The OTA would be considered a “blind” channel in regards to booking modifications.

If the OTA like booking.com sent only 1 message with new booking or maybe a cancellation it is not an issue.

If an app or the PMS have changed some fundamental details in the booking there will be some issues of what data should be used or not in latest version of the booking.

Example #1:

1. We receive a booking from Booking.com

{ customer: { name: "Evan", surname: "Davies", email: "eva.1231231@booking.com" } }

2. A Self-Checkin app collects info about the customer and pushes an update for booking customer info

{ customer: { name: "Evan", surname: "Davies", nationality: "British", ID: "12312313", phone: "+44236960561", email: "evan@channex.io" } }

3. The customer makes a change at Booking.com and we receive a booking modification message with initial data about customer

{ customer: { name: "Evan", surname: "Davies", email: "edav.1231231@booking.com" } }

Problem: What should we do with the customer data in this case?

1. Should we merge changes?
2. What should we do with the email address?

Example #2:

1. We receive a booking from Booking.com (for Standard Room)
2. Up-sell app upgrades the booking to an Executive Double
3. We receive an update from Booking.com with date changes (from 1 night to 2 nights) the room type in the message is changed back to Standard Double.

Problems:

1. What room type should update at ARI?
2. Should we change Executive Double to Standard or keep as Executive?
3. The OTA would have opened a standard room back to sale for 1 night since it was modified from 2 to 1. How should we manage this?

CRS 2.0 to take the logic and make life for PMS systems simpler

While it may look difficult to discern what data to keep and not keep, it isn’t an impossible scenario.

Let’s take an example edge case scenario with a upsell tool doing a room upgrade.

Booking Flow:

1. Booking Created from Booking.com for $100 for 1 night in a Standard Room
2. Upsell app sends email to convince the guest to upgrade to a better room
3. Upsell app updates booking with $120 and Executive Room ($20 fee to upgrade)
4. Booking.com sends modification as guest might have changed their name as it was not spelled correctly as example

Merge Logic

We would consider the OTA channel to be a “blind” updater, this means they will update a booking and not know anything regarding previous changes from other sources.

Example of Logic to deal with this scenario above.

1. What data fields have been changed since the first OTA message
2. If no change then current field value will be used from latest version of booking
3. If a field has changed, we use that value when merging

This scenario is quite a typical edge case that will happen on occasion, this can be easily dealt with with some good rules.

This logic must be done by either the PMS or the CRS, depending if we use the mixed mode or separated booking mode.

What about prices, who controls that?

Allowing PMS to create bookings leaves a small problem if we want to add a Yield Management or Revenue Management app into the CRS. These apps change prices often.

Problem:

1. RM app changes prices in CRS
2. CRS updates all channels (Except PMS)
3. PMS has out of date prices

Solution:

The CRS and PMS work together to take any changes in pricing back to the PMS so all locations have the correct data.

The Revenue Manager can work in the CRS and manage prices and the PMS will receive all updated prices. If anyone changes prices in the PMS it is also synced to the CRS.

Conclusion & Thoughts

I am not saying that app stores, CRS v1 or app exchanges are dead, but the CRS v2 could combine all of this into a simple package and saves a lot of headache for the PMS system connected.

Apps would find connecting to a handful of CRS v2 applications a much less stressful issue than the 1,000 PMS available today.

The PMS still has work to do here, they still need to keep all bookings updated with correct data, but by taking all the pain of the merging logic into the CRS the PMS can leave worrying about helping apps connect their systems and instead go about improving their core software.