Why revenue management analytics are becoming outdated

Over the last several weeks, The Analytic Hospitality Executive has been exploring why we feel that today’s revenue management systems aren’t working anymore.  Today, I’m going to delve into the limitations prevalent in today’s revenue management solutions.

 Before we review the common limitations in revenue management systems, it’s important to understand what, most frequently, is the underlying cause behind these limitations.  As I discussed in my post on price optimization several weeks ago, the science behind many revenue management solutions dates back to the 1980s and ‘90s.  As a result, many of the systems that we use today were originally developed during this time.  Naturally, the speed, processing power and ability to access data that we have today is far beyond that which was available during the 1990’s.

 Unfortunately many revenue management systems have not kept up with these evolutions in technology.   While some providers have made improvements to take advantage of modern technologies, many revenue managers continue to work with solutions which are based on outdated technologies that are substantively constrained by their outdated architecture.  Specifically pertinent to our discussion here is that these system limitations frequently drove the scientists developing the analytics for revenue management solutions to make concessions in the analytic algorithms years ago as a necessary tradeoff in order to meet performance requirements.  In some cases, these underlying analytic compromises have remained, even as the user interfaces have been updated – the proverbial “lipstick on a pig”.  The original scientists that developed these analytics have moved on, and the compromises contained in their work is not understood or questioned by those who remain.

 Forecasting and Demand Modeling

 Forecasting has been a major weakness of many revenue management systems.  Every revenue manager knows that a good forecast is the foundation for optimal pricing, and studies have consistently shown that improvements in forecasting lead directly to improved revenue returns from revenue management systems.  Of course, there is a very wide variety of demand behaviors to be observed in the different segments that hospitality serves today - and these segments themselves differ from property to property and market to market.  Finally, of course, the behavior of segments changes over time.  So – there’s a near infinite variety of behavior patterns that we need our forecasting models to capture.  Fortunately, forecasting is a well-established science, and there are many different techniques available to capture these different patterns of behavior.

 Nevertheless the revenue management systems that we depend on today frequently use a small number of these available forecasting methods – and some use just one or two.  The parameter for each forecasting model is then “tuned” so that it can produce the best overall forecast for the wide variety of segments to which it is being applied.  The selection of best or optimal parameters for forecasting is known as calibration.  Frequent calibration of forecast models helps to ensure that our forecasts are able to keep up with changes in market behavior.

 Revenue management systems would benefit from having more forecasting models available to then to capture different types of behavior.  Similarly, some segment forecasts would perform better if we could calibrate them one parameter setting, while we calibrate other segments with another setting.  But these type of complexities were not designed into the revenue management systems that many of us use today – limited processing power and tight deadlines for processing drove them out long ago.

 Price Elasticity

 Pricing in today’s hospitality marketplace is more dynamic than ever.  But, as I noted in my recent post on price optimization, revenue management science was not designed to handle such a dynamic market, where pricing is constantly changing, and demand constantly influenced by these price changes.  Rather, this science was developed at a time when pricing was relatively stable – and so the influence of price on demand could be ignored.

 As a result, today’s revenue management systems have serious weaknesses in the area of price elasticity calculations.  Many of the solutions we use ignore price sensitivity altogether.  Others make broad assumptions about “upsell” or “buy down” probabilities.  Even some of the most advanced hospitality solutions available consider elasticity only at a very high level – thereby losing critical differences in price sensitivity between market segments, over time, and as market conditions vary.  Just think about the difference between corporate and leisure demand, for example.  Yet, today’s revenue management systems, if they consider price elasticity at all, consider it at a high level unsuitable for gaining true insight into the differences in willingness to pay between these two segments.  Until these types of differences are captured, revenue management systems will not be able to effectively perform price optimization or solve the issue of competitive price effects – two factors that are clearly needed in today’s market.

 Optimization

 Like forecasting, the optimization techniques utilized by modern revenue management systems was originally designed decades ago.  And these approaches were similarly compromised by the need to complete calculations within a tight window of time in order to meet users’ needs.  Of particular concern was balancing the need to account for uncertainty of demand while still integrating decisions across arrival dates to account for length of stay effects.  Airlines similarly struggled with balancing the uncertainty of their demand with the need to account for connecting and “through” passengers.

 You see, individually, each of these affects – uncertainty and length of stay – adds complexity to our revenue management optimization problem.  Accounting for uncertainty requires some form of stochastic optimization – a particularly complex branch of mathematics.  The details regarding how stochastic optimization problems are formulated and solved isn’t really relevant here – but what is relevant is that the solving a stochastic problem takes time.  Meanwhile, accounting for length of stay correctly means that we need to consider the pricing for all future arrival dates as one integrated problem.  Attempting to solve the revenue management problem while simultaneously accounting for both uncertainty and length of stay made the revenue management optimization “intractable” – i.e. larger than the available computing power and time.

 So, today’s revenue management solutions generally take one of several approaches:

  • ignore the length of stay issue altogether,
  • ignore uncertainty and use a deterministic optimization approach, or
  • use a method called decomposition to break the optimization problem down to a scale that can be readily solved

 Ignoring either uncertainty or length of stay can be significantly detrimental to the revenue value of a revenue management solution, so decomposition is generally considered “state of the art”.  But even this state of the art solution leaves money on the table as a direct compromise to processing power.

 As Kelly explained in her post last week, the market in which we operate has changed dramatically. Today, I explained how the analytics behind the systems no longer meet the demands of that market. Next week I will explore the changing role of the revenue manager, and how that role is placing even more pressure on revenue management systems.

tags: Hospitality Analytics, Revenue Management and Price Optimization

One Trackback

  1. By The importance of price elasticity on October 26, 2012 at 11:59 am

    [...] The importance of price elasticity Alex Dietz|October 26, 2012 30Tweet In my post in September on Why revenue management analytics are becoming outdated, I made note of several important limitations in the traditional revenue management approach.  [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <p> <pre lang="" line="" escaped=""> <q cite=""> <strike> <strong>