Leisure
The Quirks Of Modeling Hotel Demand
What I have learnt about hotel revenue management as a Data Scientist.
What constitutes a "product" when you want to find a place to stay while on holiday? Let's leave aside the guest experience for now, from how you are received at the door to how good the buffet is (oh no its the same breakfast as yesterday). As a potential holidaymaker, the unit of your purchase is a hotel room or a room night as it's called in the hospitality industry.
The first complication here is that your preference for this "room-night" is made up of three interlocking considerations of time.
- "When do you want to go on holiday?", better known as the stay date or stay period.
- "How long do you want to go on holiday?", also known as the length of stay.
- "When do you want to book your holiday?", which is the booking date or alternatively can be calculated as the lead time (the difference between the stay date and the booking date).
How I modeled demand
Based on this framing, moving from individual preference to modeling an entire market of tourists is no easy feat. I want to know how many bookings I can expect on a stay date in the future from bookings made in the future (I've ignored length of stay altogether here for your sanity and mine).
The model should be able to understand this booking preference for different stay dates, as well as different booking dates. The additional bookings I expect is known as my pickup. Pickup is usually measured as the difference between how many bookings I currently have on the books (OTB) vs my OTB at some prior period, which can be negative if there are a lot of cancellations. I prefer the definition I have chosen (new bookings created) because it doesn't muddy the water by introducing two different types of preferences. The preference to go on holiday, and the preference to cancel a booked holiday (This last one isn't very clear cut to model).
This last point brings me to the second complication.
How I avoided modeling cancellations
It's useful to know where your hotel will be (in terms of demand) on a given stay date ("how many bookings will I have OTB?"). It's also useful to know how you will get there. How will demand pick up as I reach the stay date? Of course you don't just get new bookings as time goes on, you also lose some to pesky cancellations.
I prefer to think of these three factors as points and edges on a triangle (bear with me). "How many bookings do I currently have", "How many total bookings will I get", and "How many bookings will I be left with" are the three vertices. The blue path in the figure is how reality unfolds. The green path is all the new bookings I will get, and the red path is all the bookings I will lose. If I measure the green and blue path and take the difference of those estimates instead, I may be able to understand the red path as a result. It is important to note that the error stemming from the random nature of cancellations is unavoidable.
I am now free to focus on how price changes affect pickup (price sensitivity) and revenue without worrying about how I factor cancellations into the picture.
How I accounted for capacity
What's really annoying is logging in to Booking.com to look for that nice hotel you stayed in last time, just to find out that it has sold out. What's doubly annoying is that because you could not book that stay, the potential booking doesn't appear in any database record (it's not measured). With many people like you failing to book that dream holiday, my bookings dataset is incomplete. This is typically called the inventory constrained demand problem and, you guessed it, needs to be modeled for as well.
How do we measure something that doesn't exist? I begin by thinking of a hotel as existing in two states (not simultaneously, sorry Schrödinger). The hotel either never reaches capacity (never constrained) or it reaches capacity (constrained). I can try to understand something about how bookings are generated over time from these never constrained stay dates and use those patterns to estimate lost bookings when there is a constraint. It's not a perfect science, but it does help me to correct for these oddities. Alternatively, I could try to understand the relationship between website traffic on my hotel's website when it is in either of these states.
Irrespective of the method, this process is known as demand un-constraining, the specifics of which I will not bore you with here (stay tuned for fun future technical blog posts).
How I understood price sensitivity
As you procrastinate on booking my holiday, hotel prices begin to rise. What once was a $200 a night room is now $300 and in this case is far above your budget. That's your price sensitivity and it measures how tourists react to price changes. The technical term here is elasticity. The price elasticity of demand to be exact.
The complication with hotel bookings is that tourists are not the only ones reacting. Hotels re-evaluate their prices in reaction to tourists as well resulting in a chicken and egg situation that is hard to separate. Bookings are expected to be high because it is a long weekend and families are making plans to travel. Prices that are typically $150 a night have been raised to $250 a night (sheesh) to eke in some extra profit capitalising on all the bookings that will be made. The result is a situation where bookings are high and the price is high breaking our previous "price sensitivity" relationship. If we modeled this directly, our takeaway would be that price increases raise people's propensity for booking a hotel room. While I have no doubt that someone out there sees a very high price as the sole authority on quality, we aren't all made out of money.
I need to account for what is called price endogeneity, and the solution is often to model common factors that affect both bookings and prices. Notice that I mentioned long weekends before. That is exactly the kind of factor I am talking about. Domestic tourism is expected to be high on a long weekend and hotel revenue management teams can raise prices to capitalise on this.
What all the fuss was for
I've looked at booking demand, cancellations, room inventory, and price sensitivity. What is clear is that the devil is in the details, as is often the case. Tackling these problems head on ideally leads to a better understanding of the components that affect hotel revenue enabling more informed decisions when adjusting pricing policies. However, there may be two things that remain mystifying.
- How does all this complaining translate to a better decision?
- What is the technical solution to solving each of these so called complications?
For now, I hope you have understood the core problems surrounding hotel revenue management. The next post in this series will begin tackling one of these problems in more detail.