What I learned from helping build my own Revenue Management tools - without being a programmer.
A few months ago, while analysing segmentation at two hotels, I noticed that something did not add up.
The group figures looked healthy. But booking behaviour did not match what I knew from day-to-day operations: unusual lead times, rates that did not make sense for their assigned segment, and pickup - the change in bookings over a given period - that did not tell the real story.
When I investigated, I found the problem: hundreds of room nights had been assigned to the wrong segment, between Series Groups and One-off Groups.
The problem reports do not reveal
Anyone who works with a PMS, the hotel’s property management system, will recognise this scenario. Segment classification can depend on manually entered fields, inherited market codes, rules that have changed over time, and teams recording bookings in different ways. The information goes into the system, and the reports still look consistent.
But a Series Group - recurring groups with a contract and predictability - and a One-off Group - a single, more volatile event - are distinct commercial realities. Their lead times, price sensitivity and strategic value can differ. Mixing them is like mixing two languages in one sentence: the message may appear to make sense, but it no longer reflects reality.
When the numbers add up, but the interpretation fails
With room nights in the wrong segment, the business mix becomes misleading, the forecast is biased, and pricing can respond to the wrong signal. We appear more dependent on a segment than we actually are. And comparing a segment’s performance over time loses value if it includes bookings that do not belong there.
The most dangerous part is that none of this needs to trigger a system error. The numbers still add up.
Technology did the work. Business knowledge defined the logic.
I am not a programmer. But I know the business, and that is what made the difference.
At these two hotels, I knew the channel field was the most reliable way to identify each booking’s actual origin. I used it as an anchor to reclassify the data, with the help of AI tools and Excel. I built a process that maps the way each hotel records information to a consistent structure.
Technology did not decide the classification. It applied, at scale, a logic defined through business knowledge. Once the data was corrected, the mix and pickup analysis matched what was happening in operations.
Four lessons I take away
- Question data that “looks normal”. The costliest anomaly may be the one nobody questions.
- Business knowledge is still the difficult part. Today’s tools make programming more accessible, but knowing which rule to apply requires context and experience.
- Every hotel has its own language. Standardising without respecting that difference can create a new error. The mapping must adapt to the hotel, not the other way round.
- Start small and document it. One concrete problem, solved and explained, is worth more than a grand “digital transformation” project that never leaves PowerPoint.
The Revenue Manager of the future: a translator
People often say the Revenue Manager of the future will be a data scientist. I think they will also be a translator: someone who understands a hotel’s day-to-day reality and can translate it into data - then translate that data back into decisions.
Mixing languages can distort the message. Knowing how to translate between them creates an advantage. Those who master that translation, with or without code, will make the difference.