Definitely Doug 4/28/23: Now Playing Near You: Attribute-Based Selling (Part Two)

In my last installment, I covered the basics of Attribute-Based Selling (ABS) and how it could generate incremental revenue for hotels, even including (up to a point) for bookings made through Online Travel Agents (OTAs). This week will continue that theme and outline reasons why hotels might want to consider using ABS, as well as some of the operational considerations and thoughts on yield managing attributes.

Before getting into that, I want to reiterate one key point from Part One, which is that attributes are not the same as ancillaries. ABS and attributes have become marketing buzzwords that many products claim to offer, but many of them can only sell ancillaries, not attributes. Ancillaries are important, and for many hotels they will be the dominant generator of incremental revenues. But they are distinct from attributes, which offer incremental revenue to hotels independent of what ancillaries provide. A relatively small number of vendors can market attributes in a systematic, scalable way. These include the ones I mentioned in Part One and also Hotelverse, which came to my attention more recently. While there may be ones I have not found, I would view claims of ABS support from other companies with caution.

Why Sell Attributes?

Feedback from hotels and vendors who are experimenting with ABS provides a lot of insight into the benefits. It’s still the early days, and we don’t have enough industry-level data to make solid, quantitative conclusions. But we do have some strong signals.

First, ABS converts the traditional “request,” such as for a high floor, to a product for which the hotel can charge a premium – and guarantee delivery. While the most frequently requested attributes might be combined to create room types (such as a king-bed ocean view at a resort), most attributes at most hotels can only be requested in comments – and their delivery is not guaranteed.

Guests have all sorts of preferences, many of which they may be willing to pay for: high floor vs. low floor, view in a particular direction, near/far from elevator, kitchenette, balcony, fireplace, the list goes on. A few of these might get baked into the hotel’s standard room types, but you can only do that for a the most important ones, or you quickly end up with hundreds of room types. One vendor had data suggesting that 39% of guests would be willing to spend more than €5 per night to choose a specific room based on the attributes they cared about. Even if that 39% spend just €5 (and not more), that translates to €2 (about $2.18) on ADR – not trivial.

Second, guests do not understand most traditional hotel room categories. There is no clear difference between most deluxe rooms and standard rooms, and guests typically cannot tell which one they got even when they enter the room. The word “suite,” which used to imply a separate bedroom and parlor, has been misappropriated even to the point of sometimes just meaning a larger room. Very few hotel websites or booking engines show prospective guests exactly what they will get – in most cases because they can only sell generic room types. And few hotel websites explain the difference between room types other than suites, suggesting that even the hotel marketers who write the descriptions cannot distinguish a “standard” room from a “deluxe” one. Guests do, however, understand attributes. If there are specific ones that are important on a given stay, they will ask for them, and likely be willing to pay a bit extra for them.

Third, several experts who have deployed ABS commercially said that most hotels discovered that they did not really know what their guests wanted before ABS. They could see which room types were most popular, but not why. Standard room types typically combine multiple attributes (e.g., king bed, kitchenette, balcony) and as a result you cannot tell which attribute(s) were responsible for a room type’s popularity. Many solo guests may not care about the bed setup at all, yet the current model typically forces them to choose one, which can mislead hotels into thinking they care about it.

ABS enables the hotel to collect data about what guests actually want, not just what traditional products they book. It can differentiate features the guest cares about from ones they may be forced to take because of the way the hotel packaged it. It can also tell you how much they are willing to pay for a particular feature.

The data from ABS allow much better matching of the product offering to specific types of customers. Instead of defining products using words like “standard,” “deluxe,” or “suite,” the hotel can create products that address specific customer groups: the “Romantic weekend” room with a fireplace, king bed, and view of the lake; or the “Family Special” room (or perhaps even two connecting rooms) designed for two parents and two teenagers. Products can also include ancillaries to increase the appeal and spend.

Fourth, while there is much concern about potentially negative operational impacts of ABS (more about that later), there is one clear operational benefit. Hotels routinely have to put guests in a different category room than the one booked, and in most cases they do this without any knowledge of why the guest selected the room they did. This routinely results in problems like the family of four who booked a standard double-double but was “upgraded” to a deluxe room with a king bed. With ABS, the front desk need not guess what specific guests care about (or not); the guest has told them. A guest who did not request a particular attribute can safely be assigned a room with or without it – and should be happy.

Fifth, ABS (or at least the better implementations of it) enables flexible product creation. As opposed to only being able to sell standard room types, the hotel can easily and quickly create and sell packages of attributes and ancillaries to meet specific market needs. These may be seasonal, day-of-week specific, related to nearby one-time events, channel-specific, or simply creative options to generate off-peak business. Some may be targeted at specific third-party channels that appeal to guests with defined interests, such as skiing, golf, or cuisine.

ABS, when used for post-sale upselling of third-party bookings, can provide insights into the types of products each channel’s customers want. With the right ABS solution, if you find out from upselling that parties of two adults who book through Booking.com on weekends tend to like mountain-facing rooms with a fireplace and kitchenette, you can create a product for Booking.com that combines those attributes (and popular ancillaries) for a “Couples Getaway Weekend Room.” As long as your ABS software can correctly track inventory for these “virtual room types,” you can sell them through most OTAs.

I asked some of the vendors which hotels seem to get the most benefit from ABS, and they identified two types – one I expected and one I did not. Not surprisingly, hotels with many different types and configurations of rooms benefit, because ABS makes it easier to monetize the differences. Less intuitively, hotels with undifferentiated rooms can benefit, because ABS enables at least some degree of differentiation. Even if every room is identical inside, they all have distinctive views, are located on different floors, and have different proximity to the elevator, pool, parking lot, or other hotel features. Many guests may not pay more for these points of difference, but some will.

Operational Considerations

Inventory Control. ABS requires something that did not exist until recent years, and that many systems still lack, which is a single, unified view of inventory that is shared by sales (distribution) and operations. To know whether you can sell a particular combination of room attributes, you need to know whether that sale can be operationally delivered by the hotel, given all the prior commitments made to guests (whether for standard room types or attribute combinations). This is mathematically complex, because while some bookings (such as run-of-house) can be placed anywhere, and many bookings can be upgraded, there may only be a limited number of rooms (or even just one) that will meet a particular guest’s desired combination of attributes. Some or even all of those rooms may be needed to fulfill commitments made with other, prior bookings (not necessarily for the same exact combination of attributes). And having one room with specific attributes available for all nights of a multi-night stay is insufficient: it needs to be the same room each night. Legacy reservation systems are unable to handle this complexity.

Because of the need for a unified view of sales and operational inventory, ABS is most practical in cloud-hosted booking systems. Inventory (and often even room status) is maintained at the room-number level, and attributes are attached to each room. Some of the newer combined reservations/operations systems mentioned in Part One use the same cloud inventory for both reservations and operations. For these, a booking made on the website, a room move initiated at the front desk, or a change in a room’s housekeeping status will all update the same master database.

Add-on ABS products such as Expect Me, Gauvendi, Hotelverse, and Roomdex offer ABS selling capabilities to legacy property management systems (PMSs). They accomplish unified inventory by essentially mirroring the PMS room status in their own system, where they add attributes to each room and assign room allocations. When they assign a room in their system, they typically also block the same room in the PMS, which enables guaranteed delivery. Rooms can be hard-blocked (where only one room fulfills all of the sales requirements), soft-blocked (where only a limited number will do so), or booked into a virtual inventory bucket that maps to several similar rooms.  Some systems reoptimize soft-blocked room assignments on a periodic basis to (for example) reduce the occurrence of one-night gaps between a departing guest and the next arriving guest assigned to the same room, at a hotel where most guests stay multiple nights.  If either party’s blocked room can be satisfied by a different room offering the same attributes, moving it can free up a room for a longer stay, resulting in less lost revenue.

Cloud deployment of both the PMS and the ABS add-on product are needed to limit situations where room status could get out of sync, a common issue with premise-based PMSs because of communications issues, downtime for night audit or maintenance, or inability to keep up with a constant flow of external messages. Even aside from the need for real-time synchronization, most premise-based PMSs do not support blocking of specific rooms via a third-party application programming interface (API), which is necessary for an add-on ABS system to work reliably.

Periodic reoptimization of blocked rooms, as discussed above, becomes important when enough bookings are made with attributes. It is not too important if only 10% are, but becomes essential when the proportion is larger or at hotels with longer lengths of stay. Based on what I have seen, I would want reoptimization at a typical business hotel if more than 20-25% of guests specify attributes, but this could be 10% at a beach resort or 95% at an airport hotel that has mostly one-night stays. Not all of the solutions on the market currently offer reoptimization, although most recognize they may need to do it when the volume of attribute-based bookings increases.

Reoptimization ensures that rooms that have specific attributes are used as efficiently as possible. For example, if a guest has booked three attributes but the assigned room has three other attributes that appear to be in high demand, the optimization will try to move that guest to another room that also has the three promised attributes but that lacks some of the high-demand ones.

Getting Started. A significant obstacle to ABS implementation is the need to build the master table of guest rooms and attributes. Perhaps surprisingly, many hotels have to literally inspect each room to determine what attributes it has, and each one needs to be built in either the ABS-capable PMS or the ABS add-on software. Some basic attributes, such as bedding type and room size, can usually be determined from the existing PMS room table; others, such as high/low floor, are obvious enough. But some attributes may be less consistent and require a physical inspection. For example, some rooms may lack space for a mini-fridge or coffee maker that is otherwise standard, but there may be no up-to-date list of which rooms lack one or both. Still others, such as view of a specific building or monument, can require physical inspection to determine whether obstacles such as buildings or trees block the view from a particular room.

Hotel Staff Processes. Several of the vendors emphasized the need to make ABS essentially invisible to hotel front-desk and other staff. Since most hotels already hard-block some rooms in advance, and many block a significant number of rooms on or just before the day of arrival, the products I saw all used this feature so that blocked rooms appeared the same to the front desk agent regardless of whether it was the ABS system or someone on the hotel staff that blocked them. Still, there is a cultural barrier in many hotels, where the General Manager or Rooms Division Manager may manage room assignments personally from the daily arrivals report.  One system required the hotel to approve hard blocks manually. While this practice may reduce the revenue potential, it may provide hotel executives with a greater comfort level.

With ABS, more rooms may be pre-blocked by the system. However, each blocked room should represent incremental revenue from attribute sales, and early experience suggests that well under half of rooms, and usually less than 20%, will typically be pre-blocked (at least until ABS becomes more common across the industry). Most of the ABS solutions do still allow hotels to block rooms in the PMS independently of ABS or to move guests from a blocked room to another, but unless ABS is handled within the PMS, it will generally not be possible to warn the hotel that doing so might lead to one or multiple guests not being able to get what they purchased – so it must be handled by training instead.

When and if ABS starts to account for a significant volume of sales, additional automation may be needed to support the operation. For example, if a guest arrives early and no room with the selected attributes is ready, the hotel will want to offer options other than waiting, such as a room that is available immediately but is missing one of the attributes. There may also be a need for enhanced optimization of housekeeping assignments; for example, if a guest who has booked specific attributes is expected at 3pm, it will be important to have a room with those attributes cleaned by that time.

Training. While ABS should not require significant changes to front desk processes, it will be critical to provide awareness training. ABS changes what the customer is buying, from “a room” to “a room with specific features.” The customer will generally know what they have bought, so the hotel staff that greet them need to know as well. Some retraining with respect to last-minute room moves may also be in order. For example, if a room has been taken out of order, and the guest bought specific attributes, the colleague will need to know how to identify other rooms with the same attributes, or how to offer the best alternative if there are no others.

The Brand Challenge. For an individual hotel, implementing ABS can be challenging, but properly resourced, it is generally achievable without too much pain. For brands, however, there is another layer of complexity, which several vendors cited as a significant barrier. Brands want standard approaches that can be deployed across all their hotels. But what attributes should be standard? Should hotels with unique room features be able to define their own attributes? What standard products (attribute/ancillary/policy combinations) should be offered through the brand website or other channels? These were difficult discussions even in the days of generic product descriptions, and are likely to become much more complex with ABS. There will be tradeoffs between delivering a consistent booking and stay experience across the brand and allowing hotels to market their unique features.

Search and Metasearch. Being able to sell unique room attributes is great, but you also must consider how prospective guests who value those attributes will find your hotel. You can now sell rooms with an unobstructed view of The Washington Monument, but will your target market find them? ABS will in many cases force a recalibration of keyword marketing, metasearch management, and even social media marketing.

Revenue Management Considerations

Much has been written about the potential to yield attributes to maximize revenue, but very little has been done to date. The main reason is that yield models need lots of data, and there isn’t a whole lot of that for attributes yet because not many hotels are selling attributes. That is changing, but slowly; one expert thinks that at least one hotel group will have enough data to start to yield attributes within the next 1-2 years. As usage expands, it should be possible to yield (a) popular product combinations that are defined in part or whole by attributes; (b) popular attributes, whether sold as add-ons or incorporated into a product that carries a price premium; and (c) popular combinations of attributes.

Conclusion

Attribute-based selling is on the roadmap of most major hotel brands and several core system vendors, and is available as a third-party add-on today for many cloud-based PMS. There is little doubt it can have a significant impact on the bottom line of most hotels. And whereas a couple of years ago ABS was more theory than reality, it is time for independent hotels and small groups to evaluate it – now, if they already have a cloud PMS, or as part of the migration project if they will be moving to the cloud soon. The major brands cannot move as fast; they will likely lean on their current or planned core-system vendors and timelines will have to be determined jointly, but they will also need to decide how best to balance simplicity for guests, with enabling individual properties to differentiate themselves.

‍