0 Basics

Odds are that if you’re reading this then you may already have an idea of what Revenue Management (RM) is. In order to ensure we’re being as thorough as possible though, let’s define the term Revenue Management, more specifically, what it means in the short term rental industry.

If you’ve been around the industry for any period of time, you’ve most likely heard the saying “Revenue Management is the art and science of selling the right product at the right price to the right customer at the right time”. This adage does a decent job of describing what Revenue Managers (RMs) do but let’s break it down in further detail.

Now, let’s address the “art and science” part of the long—winded Revenue Management definition above. 

First, the science. Revenue Managers (RMs) rely heavily on data. Specifically, current market trends, competitive set metrics, or their own key performance indicators (KPIs). Before many of the new software options were available many hours were spent on creating tools—typically in Excel, Google Sheets, Tableau, etc.—to visualize and analyze this data. Nowadays, RMs can take advantage of various products to access market data or dive into their own data. Along with working with data, RMs also approach pricing and listing restrictions (i.e., Check-In/Check-Out rules or Minimum Stay requirements) with a scientific approach to understand the impact and efficacy of their strategies.

Now, the art. Whether RMs are using a dynamic pricing solution or creating their own rate plan, the price on any given day is, simply put, an estimate. These estimates on pricing of course can be more informed than others, especially depending on the depth of the analysis done to come up with the price. As with any industry, there is an art to how you approach your job. A core responsibility of being a Revenue Manager is to develop creative solutions to accomplish peak performance for their properties.

Revenue Management is a complex and dynamic field that requires a blend of analytical skills, market knowledge, and strategic thinking. By effectively leveraging data and market insights, revenue managers can significantly impact a property's financial performance and competitive position in the market.

You'll want to segment your portfolio into groups. These groups should be groups of "similar" properties, properties you can expect to extrapolate demand between, and may also be hierarchical moving from a larger group to a smaller group. For example, if you only manage listings within one market then a natural way to segment properties would be by bedroom count but if you're managing multiple markets you would choose market and then bedroom count.

These will form the basis for later reporting and processes to investigate trends and performance. 

Seasonality is a fundamental concept in Revenue Management that describes the cyclical patterns of demand in a market for travel and accommodation. It's a crucial factor that drives key data points for revenue managers.

Revenue Managers reference seasonality for nearly every aspect of their activities. For Example:

• Setting rates according to demand
• Calculating booking windows according to demand
• Forecasting revenue according to demand

Classifying Seasonality is primarily an internal activity for the Revenue Manager as it informs Revenue Management decision making, reporting, and forecasting for their team. However, it is helpful to know the general market Seasonality so the RM can easily identify where their portfolio may operate differently than those around them.

Categorization of Seasonality is not a “hard science” nor is it completely standardized. Most others in our industry will understand what you mean if you utilize the language above. Some Revenue Managers will simplify this even further and only refer to High Season and Low Season. On the other end of the spectrum users may define additional seasons to further differentiate their seasonality.

Finally, specific dates and time periods may deviate from the general seasonality the Revenue Manager has determined. In this case the Revenue Manager may consider that an exception while still referring to the baseline seasonality overall.

Generally speaking, seasonality does not change year over year and if it does it will tend to be in small shifts over time. This assumption is foundational which is why it is important to identify exceptions in market trends that are not considered the seasonality itself. Seasonality has changed in some markets and it is up to the Revenue Manager to determine if these changes are likely to be recurring and thus truly changing the seasonality or are more temporally based. 

Temporal Change to Seasonality: 

• Post Covid-19 boom in traditionally “shoulder” seasons in many markets
• Hurricane Season Arriving early or Late

Permanent Change to Seasonality:

• Changes to “back to school” schedules
• A mountain market which keeps receiving less and less snow limiting the ski season

Example of a Monthly Demand Curve as seen in the Seasonality setting of Wheelhouse:

Green: High, Orange: Shoulder, Red: Low, Blue: Example of Date with high demand within a Low Month

When we use the term Booking Window we mean the time frame in which you can expect or observed a significant (more below on what "significant" means) number of consumers searching and booking for a specific date or range of dates (events or seasons).

For example, you may expect many guests to book for your summer high season months (e.g., June to August) roughly 3-4 months out so your Booking Window for your summer high season would roughly be February to April.

Often times you will hear people use the term Booking Window and Lead Time interchangeably. While these terms may be similar and in some regards mean the same thing, we like to think of Booking Window as a more general term for the aggregated Lead Times for individual reservations within either a market or your own portfolio.

Watch this video by John deRoulet as he walks through a live analysis of Charleston's Booking Window heuristics. Below is an image from the Wheelhouse Markets page for Seattle, WA which shows the distribution chart for Lead Times for August 2024. The median lead time for August is right around 50 days, based on this chart. I could use this as my heuristic but it is worth noting that I don't want to simply wait until 50 days before August to start making any sort of rate changes. Monitoring my booking pace (more on this later) and making the call to adjust pricing earlier than 50 days will need to happen.

Practically speaking, Booking windows are not always exact measurements and as you saw above can be determined in a number of ways. Using them as tools for your team's frameworks on decision making (more on this in the Intervene chapter) for consideration of pricing and availability decisions is a standard practice but new events or changes in market or your own bookings should always be considered in real time. For example, if you say "May's average booking window is roughly 60 days for my market" and use this as justification to only start looking at metrics for May within 60 days then you may miss bookings and opportunities that happen outside of this timeframe for a new concert you weren't aware of.

Before jumping into the guide you'll want to make sure you understand the basic calculations for the most used metrics in our industry. For a more robust exploration please visit Wheelhouse's Lexicon page. Note that the nomenclature in our industry is not always consistent and even at Wheelhouse we use certain terms interchangeably, which we've tried to note below.

The first step is to understand the tech stack and how your rate gets between the various systems you are using. In many cases, there are 2-3 systems involved, and can be as many as 4 or more involved in pricing and making a reservation. Often these will be:

This is where the daily prices are created and begin. These include Wheelhouse, Beyond Pricing, Pricelabs, and others.

This is where property attributes, guest info, fee info, etc. are stored. Often times a PMS will also include Channel Management or listing distribution. Examples of popular PMS options include Streamline, Guesty, and Track. See a full list of who Wheelhouse integrates with here.

Most PMS options include channel management but one CM that people often use in our space is Rentals United.

This includes all Online Travel Agencies (OTAs) like Airbnb, VRBO, or Booking.com and includes your direct booking website.

Some of you may not be using a RMS and some may have their channel manager included in their PMS. You may also see a situation where some channels go through a channel manager and some direct from the PMS. For the sake of the conversation let's assume we are using all 4 components as many of these tips will be applicable if you are using less. 

Rates/Restrictions to Channel

Now that we know what systems may be involved it is important to understand what components these systems are dealing with and where they might originate (i.e., the source of truth for that component). Keep In Mind: Where this originates will depend on your own tech stack.

• Originates in RMS/Pricing System
• Rates
• Minimum Length of Stay
• CTA/CTD Restrictions
• Originates in PMS
• Availability
• CTA/CTD Restrictions
• Fees
• Taxes
• Originates in the Channel
• Reservations

Each one of these can be a breakpoint and they can be a breakpoint at any point where they pass from one system to another. If one of these breaks you may find that a reservation comes in differently than what you thought was going out. 

Below is a diagram that shows how rates flow out starting from the RMS.

This seems very simple. Rates flow originate in the RMS system, flow to the PMS and are posted there, flow from the PMS to the Channel Manager and are posted there then are finally posted on the channel. What is important to note here though is this tells you where you can start to look for breakpoints.

For Example:

If you are receiving reservations and the rate is wrong the first place to look is in the RMS because that is where the rates originate from. Did you post the correct rate? If that is correct you move down the chain. Compare the rate in the RMS and the PMS. Usually just the rack rate in the tape chart. Does this match? If it does then the breakpoint is probably not between the RMS and the PMS. Next, you check the PMS and the Channel Manager. If that rate matches then move on to the Channel Manager and the Channel.

By identifying where the breakpoint is occurring you significantly reduce the amount of variables of potential issues that may be occurring. You also know exactly what vendors and partners to go to to seek assistance.

Reservation Back to System

Now, this goes a bit further because sometimes you have checked all of the breakpoints feeding data outward and they seem correct but at the end of the day the reservation is still wrong. This may indicate 2 potential things:

1. The reservation data is getting split up incorrectly on its way back through the system
2. A different component is broken

In some cases, it is both. In our space fees can be very complex and not always operating the way we think they should. By first checking if the rates/MLOS/Restrictions are feeding accurately we rule out a significant amount of potential breakpoints and can then focus on reservation-specific things.

By using the reservation itself as the point-of-truth we can compare each of the connections for differences to find the breakpoint by going down the chain of the reservation passing between the systems. 

Like in the situation where the RMS was the originator of the Rate, the channel itself is the originator of the reservation. Because of this, look at the specific channel-side breakdown of rental revenue, fees, etc. and check that against what you posted into the system. (ie: does the reservation breakdown match what rates/restrictions are actually on the channel’s front end or back end.)  Next, check the reservation in the channel manager. Do the breakdowns and totals for the reservation match? 

This step in the Channel Manager and again in the PMS is especially important. While rates going outward originate in a single source and should simply be mirrored when they post to other sources, fees sometimes feed from other systems and sometimes are set up independently in each system. This is further complicated by the fact that fees on each channel may be displayed or read out differently. You may not always be able to track each fee as a line item but this is why you also want to check the rental and grand totals between each source to ensure that the fees and rates you are expecting are being broken out correctly in the reservation. 

Again, the goal of this process is to identify where the data is mismatched between two systems in the chain. This tells you where exactly you need to troubleshoot your problem and whom to involve.

Re-Cap

• Identify the component of the reservation you think is incorrect. 
• For Example:
• Rental or Total Booking Amount Incorrect likely Rates, Fees or Taxes
• Trace that component from the point it originates at through each system it passes through looking for discrepancies. (ie: From RMS to Channel)
• Trace the Reservation backward through the chain using the booked Reservation Values as the source of truth looking for discrepancies
• Pay particular attention to both the Gross Total and the Room Rental Total because individual fee line items may not align but they all should be accounted for in the Gross Total
• Upon identification of the breakpoint get the vendors involved in that breakpoint and investigate setup in both software systems to resolve the issue. Be sure to include the following information to expedite help from vendors:
• Screenshot of Component in each system
• Example: Screenshot of rates in RMS and Rates in PMS Tape Chart
• Reservation ID and Dates
• Description of what does not match between the two systems.