It’s Not Just a Room – Part 1

Most hotels today sell using a model that has changed very little for the last 50 years. The customer selects a room type and maybe a rate plan, an arrival date and number of nights, and confirms a booking. This works fine when all the guest needs, is a bed and shower. But for those looking for more, hotels are leaving money on the table.

The typical guest could not say how a deluxe room is different from a standard one or why they should pay more for it. If they ask the hotel, they probably get the classic answer, “location and view.” On the other hand, many guests have specific needs for which they would happily pay extra. For a couple on a romantic getaway this might be a king bed, a fireplace, and flowers and champagne on arrival. For a family it might be a connecting room for the kids or proximity to the pool. For a business traveler arriving on the red-eye it might be a 7am check-in. Some of these may be nice-to-haves that the guest could live without; others may be essential. Unfortunately, few hotels even try to sell these things ahead of time – even though it may mean they will lose the business to competitors that do.

If we did not already know it, the pandemic has reinforced that the room is not the main driver for many guests. In North America and Europe, COVID has shifted the business mix toward the leisure drive market. Upsell software company Oaky told me that in Europe, where many hotels have only a few parking spots, they have seen a new phenomenon where guests book several hotels, send email inquiries to each about parking, wait for the first hotel to confirm it, and then cancel the others. And many more guests are taking “staycations” where they spend most of their time socially distancing at the hotel rather than exploring the destination city. Oaky cited data showing that in-hotel spending was much higher in 2020 than in prior years. This was not just due to a change in mix from business to leisure; repeat guests from prior years were also spending more.

This column and the next one will focus on efforts by software vendors to enable the sale of “what the guest wants to buy” as opposed to the “standard double-double” or “deluxe king” that most sites are prepared to sell. Two distinct approaches are worth understanding: attribute-based selling (ABS) and non-room product selling. In the real world, these can overlap and support each other, but there is a lot of meat in each one, so I will cover ABS this week, and non-room products in my next column.

For years, many in the industry have talked about ABS. You can simply Google “hotel attribute based selling” for a good sampling. Some software providers view everything a hotel might sell as an attribute, but this is marketing-speak. Oxford Languages defines “attribute” as “a quality or feature regarded as a characteristic or inherent part of someone or something.” By this definition, guest rooms may have attributes such as bedding configuration, a particular size or layout, a fireplace, a work desk, a balcony, an ocean view, a high or low floor, or proximity to the elevator. A meal plan, a massage, flowers sent to the room, or super-fast Wi-Fi are all products that can be presold to be sure, but they are not a “characteristic or inherent part” of a room, meaning they are not attributes.

As much as you may have heard about ABS, it is still very much in its infancy in hotels. Some property management systems and distribution systems claim to support ABS because they can presell things besides rooms. To me, this is usually more a form of dynamic packaging than attribute-based selling – it still starts with selecting a traditional room type (which the guest may or may not care about) and then layers on additional items, most commonly things that need not be carefully inventoried. In true ABS, however, you need not choose a room type at all, just the attributes that matter to you.

Hotels have always understood the importance of attributes, and some do a creditable job of delivering them to guests who specifically request them. But very few actively sell them. Room types have been around since the earliest generations of property management systems and reservation systems. They were created not because customers asked for them, but to keep booking screens and inventory calculations simple enough to conform to screen and compute-power limitations of the day.

Room types are just specific combinations of attributes, such as bedding arrangements, room size, and view. However, the room-type selling model requires guests to pick a specific size, view, and bedding arrangement at the time of booking even if one, two, or all three of those things are irrelevant to them. Furthermore, the hotel has no way to know which (if any) of these things DO matter to the guest, and it thus loses the ability to move the guest into a different room type without risking a problem at check-in. More important, it fails to capture the potential revenue that some guests might pay for an attribute not captured in the room type, such as a high or low floor, proximity to the elevator, bathtub vs. shower, or a view facing a particular direction.

In theory a hotel could define a room type for every combination of attribute, but in all but the simplest hotel you would quickly get to thousands of room types, such as “large room with sitting area for three people, near the elevator, high floor, city view, king bed, balcony, no connecting door.” That is impractical for the hotel, for the guest, and for the poor user-experience designer trying to create the screen from which guests will shop and buy.

True ABS eliminates the use of room types, at least in the core reservations system. A 300-room hotel would instead describe its inventory as 300 individual rooms, each with a particular set of attributes. A booker selects the attributes important to them and is presented with options for “a room” with those attributes, perhaps with multiple prices based on refundability, advance booking or other factors. They may also see add-on prices attributes they did not request (upsell opportunities), or how much they could save by dropping one they did. When the booking is confirmed, it is for “a room” with the specific set of attributes the customer has selected. If the bed type is not important, then the customer is not forced to pick one, and the hotel need not allocate one. The hotel now has the flexibility to assign the guest a room with any bed type – as long as it has the attributes the guest selected.

The first challenge with ABS is knowing whether a particular combination of attributes can be delivered, given all the prior commitments made to other customers. With room types, this is simple: you know how many rooms you have of each type, and each new booking simply deducts from the availability of the appropriate room type. When the count reaches zero, you cannot sell any more of that room type and be confident that you can deliver it.

In small numbers, many hotels handle attribute requests or sales by blocking specific rooms for specific guests in the property management system. This works for the occasional request, but not when many or most guests buy attributes. There may be 50 rooms in a particular hotel that would satisfy the combination of attributes a prospective guest wants to book, but the question is, can we be sure that at least one of them will still available after meeting the commitments already made to previously booked guests? If the answer is yes, you can sell that combination of attributes; if it is no, then you are “sold out” of it.

That yes-or-no answer requires a lot of computational power, which until recent years was impractical for most hotels and software providers. While there are different ways to solve the problem computationally, perhaps the simplest way for non-technical readers to understand it is to view the computer as maintaining a “tape chart,” with rooms “soft blocked” to ensure that each commitment can be met. For readers unfamiliar with front-office lingo, a tape chart is a calendar matrix (originally on the wall, now usually on a computer screen) with room numbers down the side and dates across the top. A strip of colored tape – or colored pixels – marks each reservation for a room and some number of nights that corresponds to the length of the strip. A soft block means that a reservation has been assigned to a specific room, but only for planning purposes; the guest does not know or care, and the hotel can move them to a different room if needed.

To determine availability for a particular combination of attributes, the system would first look at non-blocked rooms to see if any of them has all the requested attributes. If so, it can confirm the sale. If not, then it starts shuffling the tape chart, moving guests around (while still honoring the attributes committed to each one). The goal is to see there is a set of room assignments for all the prior reservations that will free up a room with the requested attributes and length of stay needed.

Sometimes this shuffle may yield a quick solution, for example freeing up a room by simply moving one guest to another room that meets that guest’s requirements but not those of the one it is trying to confirm. Other times prior commitments may mean that there is simply no set of room assignments that would yield up a free room with the requested attributes. In that case it cannot be sold with any assurance that the requests can be met.

But to know if that is the case, the computer has to explore every possible combination of room assignments that meets the attribute requirements of the associated bookings. And because some bookings are for multiple nights into the future, moving someone for one night can have cascading effects on the ability to meet the attribute requirements of future bookings. The system may need to consider room assignments for days, weeks, or even months into the future just to determine whether it can sell a single two-night stay for tonight with a specific set of attributes.

ABS is also challenging because most distribution intermediaries provide little or no support for attributes. Of course, this can be an incentive for guests to book direct, which is one of the reasons many major brands have it on their roadmaps. And implementing ABS in your reservation system need not prevent you from selling through third parties; you can still group commonly bundled sets of attributes into room types to publish them to non-ABS channels. Further, the insights that you get from direct attribute-based sales can help you better identify what combinations of attributes contribute to a room-type that is most likely to sell. And there is nothing to stop an ABS-capable hotel reservation system from reaching out to guests who book through third parties after the initial booking. A web link could allow them to modify their initial reservations so the hotel can find out which attributes matter to them, and/or try to upsell ones that they could not book through the third party.

ABS will create operational challenges, but it should also deliver the technology to address them. A guest who has confirmed a room with several specific attributes may show up at 9 am wanting to check in, when no room with those attributes is yet ready for occupancy. The system will need to help the front desk agent identify the best options based on rooms that are ready now, expected soon, or able to be cleaned quickly. Since “best” is dependent on which attributes matter to the guest, and since each guest may have a different tolerance for waiting, this means the front desk needs a screen showing rooms that are the closest match to the guest’s confirmed attributes, which attributes are missing, whether they are ready now, or if not, then by what time they can be made ready. They can then offer the guest a set of relevant choices: wait for a room that has every confirmed attribute or accept something less (or different) that can be available sooner. The system may also need to take action to ensure that housekeeping prioritizes a room for which a guest is waiting.

ABS is still in its infancy. To my knowledge the only significant reservation system that has eliminated room types is the new Amadeus Central Reservation System, and it is only partway through its journey towards full ABS; pricing is still done by room type. ABS is on Oracle’s 12-month roadmap for OPERA as well; an earlier deliverable will be to support selling by time increments other than a full night, such as hourly (another important break with the historical model). OPERA and some other property management systems already have extensive capabilities to sell and deliver non-room products, and hotels can often use these features to capture additional revenue in the same way as ABS.

I will have more to say on that in my next installment. This week I will keep the focus on the shift from room type to attributes, which is important because any reservation system that still uses room types (in other words almost all of them) will inevitably commit to deliver a guest something that they do not want or need, and the hotel will often have no way of knowing what is – or is not – important to any particular guest.

The inventory and operational aspects of ABS are the first step, but there are two other parts that matter. They are even earlier in the development cycle. While I have had conversations with vendors and seen some proof-of-concept implementations, it is still too early to cite proven implementations.

The first is the actual sales process, which needs to be rearchitected away from room types and focus on deriving as much revenue as possible from attributes. Amadeus’ customers are experimenting with various ideas now. One concept is to use tick-boxes like those on the left-hand margin on sites like Expedia or Booking.com that filter hotels based on attributes, but in this case each box represents one attribute for a room. If you tick a box labeled “king bed,” for example, then the list of available products is immediately updated to eliminate any that do not include a king bed. There is also much discussion about what the default list of products should be for a given sale opportunity. It will likely be influenced by the guest history or profile for a known guest, or by things such as country of origin, party size, day of week, and length of stay for an anonymous one.

The second aspect is revenue management, which today is based mostly on the assumption that it is room types, not attributes, for which inventory needs to be managed. A few revenue management providers like IDeaS are reportedly working on yielding attributes, but with so few companies using attribute-based reservation systems, it is still too early for real-life implementations. What is clear is that it will be challenging for hotels to manage pricing manually in an attribute-based world; there are simply too many combinations.

Beyond the question of how to price attributes (individually or in combination) is the one of how to manage oversales. The assumption that you can always overbook lower-rated room types based on the availability of higher ones may not hold in the attribute-based world. While guests are generally happy to get a room upgrade, this may not be the case if the “better” room lacks an attribute that was important to them (and for which they may have paid extra).

Attribute-based selling is an idea whose time has come. While most hotels will need to wait for the software to mature, now is the time to start thinking about how it can be used and planning for the future. The early movers will be the first to capture the revenue.

‍