It’s all the rage. With the arrival of Big Data, many dream merchants are predicting that the future of Revenue Management will involve the inevitable enrichment of data: customer data, price comparisons, global event databases, weather data, etc.
Let’s start by pointing out that the problem is obviously badly framed: we’re starting with technology, Big Data, and we’re wondering what we could put in there to supplement the data from Yield. Instead, we should be doing the opposite, asking ourselves what Yield levers we don’t yet cover, or don’t cover well enough, and only then asking ourselves what technology we might use to migrate to Big Data if the current technology isn’t sufficient.
But let’s look at the most fashionable case of the moment, the weather.
The impact of the weather
Listening to them, you’d think that Revenue Management never really existed before. And that thanks to this incredible news, we were finally going to get round to it: « all the serious studies show that a rainy weekend has a decisive impact on sales. People stay at home and take advantage of the bad weather to prepare their holidays ». Until today, we didn’t take this into account. So we didn’t know how to do Revenue Management. Thank you for enlightening us.
The idea would of course be to increase prices at that time, taking advantage of the greater propensity of customers to book in bad weather. What a shame!
The 3 reasons for the scandal:
1. The price is not a toy
So if it’s raining, we raise prices, if it’s sunny, we lower them? And we play with the customer in a purely opportunistic way, as others do with IP tracking? Maybe I’ve become an old RM fart, but all the same: price is not a game, it’s a lever that needs to be handled with care, by taking responsibility for your pricing policy and being able to justify the price to the customer. Who is capable of saying to a customer: « Dear Madam, it’s raining, we’ve fooled you, we’ve raised our prices » ?
2. The impact is minimal
On a rainy weekend, a customer’s booking process (which takes 3 to 4 weeks on average) may be speeded up, with the decision-making process possibly being brought forward as friends and family get more involved in the holiday. There’s no denying this effect. But there’s no reason why there should be more customers in the end. At worst, it’s the shape of the ramp-up that will be slightly impacted. What’s more, the rainy weekend is a booking period. But the price is set according to the date of stay. On a rainy weekend in April, would a hotel chain have to raise all the prices for all stays in July and August, at all its hotels? And then lower them as soon as the sun comes back out?
What’s more, the weather is never the same from one year to the next, to the day. Yet many of today’s forecasting models are robust and reliable. Some hoteliers can even make do with models based on N-1, given the regularity of their business and the superimposability of load curves from one year to the next. The weather impact is therefore actually very minimal.
3. It’s raining, so what?
I’ve even heard outlandish remarks like: « It rains the first week of July in Brittany, so let’s lower the prices for last minute bookings ». As if lowering the price by 10% would bring back the sun. As if a customer, disappointed with the weather in Brittany in the first few days of summer, were prepared to say: « gosh, it’s raining. But it doesn’t matter, we’re going anyway because the prices have gone down: we’re going to be able to walk in the rain for cheap, great! » You’ll have to introduce me to that customer.
So I’d urge the few Big Data experts who want to revolutionise Revenue Management to be a little more modest and moderate. There are enough great ideas ahead of us without polluting them with irrelevancies. For example, integrating ancillary revenues into the forecasting and optimisation process. You have a great card to play here. But please, spare us the weather effects and other nonsense. Be patient, your time will come…
Keywords: Yield Management, Revenue Management, weather, forecast, Big Data
