By Konstantin Artemyev

September 24, 2026

There is a recurring problem with automation in business: the larger and more complex the function being automated, the more dangerous it is to buy the technology before the company understands how that function is supposed to work. Revenue Management is a good example. A hotel may buy a Revenue Management System, or RMS, even though Revenue Management has never really existed as a separate function inside the business. There may be no one systematically responsible for forecasting, pickup, booking window, segments, groups, restrictions and distribution. There may be no defined working cycle and, in some cases, not even a clear understanding of which decisions the system is supposed to support. The software still gets installed, and after some time management may quite honestly conclude that Revenue Management did not really deliver much. In reality, what the hotel tested was not Revenue Management. It automated a process that had never been properly built.

I have been in hospitality long enough to remember when revenue managers in large hotel companies did much of the analytical work manually in Excel. It took more time, required discipline and created plenty of routine work, but it worked. The methodology of hotel revenue management does not depend on having an RMS. At its core, Revenue Management is a repeated sequence of actions, and each stage should produce a clear analytical result.

The revenue manager first needs a current picture of the hotel. How many rooms are already on the books for future dates? What pickup has occurred since the previous review? How many reservations have been cancelled? What ADR is already forming? Which groups are in the system? How much inventory remains? Which rates and restrictions are open? Historical data, known events and other market information are added to the same picture. The result is not simply today’s occupancy but a useful snapshot of where the hotel currently stands.

That picture then needs to be broken down. Individual demand and group demand behave differently. Different segments have different booking windows. Channels produce different types of business, while room categories often sell at different speeds. Looking only at total occupancy therefore tells very little. Booking pace and pickup need to be compared with the way demand normally develops for the same period so that the hotel can understand whether the current situation is actually unusual or simply normal for this point in the booking cycle.

The next step is the forecast. The question is no longer how many rooms have been sold today, but how many are likely to be sold by the arrival date and what the final demand may look like. Only then is there a reasonable basis for making commercial decisions. This is where the part most people associate with Revenue Management finally begins: rates, availability, restrictions, promotions, channels, groups and contracts. Should BAR be changed? Should a particular rate be closed? Is a minimum stay needed? Does a promotion still make sense? How much inventory should remain available for higher-rated demand? Should a group be accepted, and what business could it displace? The result of this stage is no longer analysis alone. It is a set of commercial decisions.

A few days later, the whole process begins again. New pickup arrives, a group changes, cancellations appear, an event turns out to be stronger or weaker than expected, or demand develops faster or slower than the forecast. The revenue manager looks at what happened after the previous decision, checks how accurate the forecast was and decides what should now be adjusted. Seen this way, the role of an RMS becomes much easier to understand.

None of these stages fundamentally requires one. The hotel needs data, spreadsheets or another analytical tool, discipline and a person who understands what they are trying to find out. Revenue Management worked this way for many years before modern RMS platforms became widely available. What an RMS can do is remove a significant amount of mechanical work. It can collect data automatically, calculate pickup, build booking curves, identify deviations, support forecasting and recommend changes to rates or restrictions. In a large hotel, the amount of time saved can be substantial, and I see no reason to romanticise manual work where technology can do it faster. But good automation does not replace competence.

There is also a technical side that is often underestimated. Implementing an RMS is a project in itself. Even with a modern cloud product, someone has to understand where the data will come from, whether it is complete and reliable, which integrations already exist and what still needs to be configured. Sometimes the PMS and RMS have a ready-made connector. In other cases, data may have to move through APIs, additional integrations, exports or intermediate tools. Modern cloud systems have certainly made this easier than it once was with large legacy hotel systems, but easier does not mean automatic.

In a small independent hotel, IT is often outsourced. The PMS comes from one provider, the RMS from another, the commercial director is busy with sales and the general manager with operations. Someone still has to coordinate access, integrations, data mapping and testing, and then verify that the system is receiving the information it actually needs. Once the technical implementation is finished, the work is only beginning, because someone must regularly review the forecast and pickup, understand why the system is recommending a rate change, evaluate groups, recognise when one large booking is distorting the picture, watch what is happening with channels and segments, and decide whether a recommendation fits the hotel’s wider commercial policy.

Without that person, an RMS can easily become an expensive interface that the commercial director opens occasionally between meetings. This is why I would not start an RMS implementation with software selection. I would start by describing the Revenue Management process itself: who is responsible for it, which data is used, what is reviewed daily, weekly and monthly, which decisions this person makes, which systems need to exchange information, who is responsible for data quality, which tasks are still manual and which ones are actually worth automating. Until those questions have reasonably clear answers, buying an RMS feels premature to me.

There is another trap as well. Some products described as Revenue Management tools are, in practice, closer to dynamic pricing modules. The system sees that only a few rooms remain and recommends a higher rate. It sees that many rooms remain and recommends a lower one. There may be a few additional rules, but the underlying logic can still be quite simple. There is nothing wrong with dynamic pricing as a tool, and it can be useful, but dynamic pricing is not the same as Revenue Management.

If a system does not meaningfully consider booking pace, booking window, segments, groups, events, historical demand, channel structure and other relevant factors, then it is automating only a narrow part of the process. Low remaining inventory does not always mean strong demand; a large group may already occupy much of the hotel. High availability a month before arrival does not automatically mean a problem either if most demand for that period normally arrives during the final ten days. A simple rule of “few rooms left, increase the rate; many rooms left, decrease it” may create the impression that the hotel has implemented Revenue Management when it has really implemented an automated reaction to inventory.

This brings the discussion back to the person responsible for the function. Even with a very good RMS, there should be an experienced specialist for whom Revenue Management is the main responsibility. That person does not necessarily need to be employed full-time. For a smaller independent hotel, a part-time revenue manager or an external specialist working with several properties may be perfectly reasonable. What matters is that Revenue Management is not simply added to sales, groups, events, marketing and OTA management as one more responsibility among many.

The process needs regular attention because it never really stops. Today’s forecast becomes the basis for a decision, new pickup appears a few days later, the demand mix changes, a group arrives, an event is announced and the picture has to be reviewed again. If someone only opens the RMS occasionally between unrelated tasks, the problem is no longer the quality of the system.

I am therefore quite comfortable with hotel revenue management without an RMS. It may be more labour-intensive and less convenient, especially in a larger property, but there is nothing unusual about it methodologically. What is much harder to imagine is effective Revenue Management without a revenue manager. By revenue manager, I do not necessarily mean a job title on the organisational chart. I mean a person who understands the process, is responsible for it and has enough time to do the work properly.

In that sense, an RMS remains what good automation should be: a tool that makes a competent specialist faster and more effective. If a hotel cannot clearly answer who is responsible for Revenue Management and what that person actually does on a regular basis, I would solve that problem first and choose the system afterwards.