RMS and PMS: should Revenue Management become a simple PMS feature ?

Should you choose an RMS native to your PMS, or stay with an independent RMS? The question keeps coming up as more and more PMS vendors launch their own Revenue Management module. It is not just a matter of features: it is a choice that shapes the speed of innovation, the product vision and, ultimately, the quality of the pricing recommendations hoteliers receive. Here are the three possible scenarios, and why integration does not mean consolidation.

The return of a familiar debate in Hotel Tech

I’ve been thinking a lot about this question lately. Not because I believe PMS vendors shouldn’t develop their own Revenue Management. They should, from their point of view. And not because I think independent RMS vendors should be shielded from competition. Quite the opposite. Competition is healthy. But when I look at what is happening in Hotel Tech, I can’t help thinking that we may be replaying a story we have already lived through.

Some PMS vendors have recently announced their own Revenue Management System. And it made me pause, because the subject goes far beyond a PMS launching a new module.

For years, Hotel Tech moved in one direction: specialization. We built dedicated systems for distribution, CRM, reputation, upselling, Business Intelligence and, of course, Revenue Management. Then came the era of integration. APIs allowed all these specialists to work together.

Today, the pendulum seems to be swinging back the other way. PMS vendors are adding more and more features to their own platforms. And Revenue Management is one of the most strategic, and potentially most valuable, features to build directly into the platform.

So I keep coming back to the same question : will the RMS become a simple PMS feature?

I don’t think the answer is as simple as “yes” or “no.” Because there are three very different ways to imagine the future of Revenue Management.

Build: when the RMS becomes a PMS feature

The logic is hard to argue with. The PMS already knows what is happening in the hotel. It knows the reservations, the inventory, the occupancy, the booking pace, the room types and the channels. So why should a separate system have to retrieve all this information before making a pricing recommendation?

A native RMS can shorten the distance between data, decision and execution. For many hotels, that is a very attractive proposition. One platform. One interface. One contract. One less integration to maintain.

And there is an even more important advantage: a simple, integrated RMS can make Revenue Management accessible to hotels that would never have invested in a sophisticated standalone solution.

That is genuinely good for the industry. But there is another side to the story: a PMS has a lot of things to do. Revenue Management has one. And an RMS is not a feature you build once and then move on from.

Revenue Management is constantly evolving. Data changes. Models change. Distribution changes. Guest behavior changes. AI changes what is possible. The best RMS of tomorrow will not simply be the one with the longest feature list. It will be the one that keeps improving. We all know RMS products that were gradually pushed out of the market because they failed to innovate continuously.

That is the first question I would ask when an RMS becomes one module among many inside a PMS: will it receive the same level of attention when priorities inevitably start to compete ?

We have already seen a similar evolution with Channel Managers. And that is precisely why I think the question deserves to be asked before assuming that native is necessarily better.

Buy: when the specialist joins a group

The second model is acquisition.

Rather than building an RMS from scratch, a PMS or a larger Hotel Tech group can simply buy one. Here again, the logic is appealing. You buy technology that took years to develop. You buy expertise. You buy customers. You gain scale and distribution power. The specialist benefits from more resources. The group gets a product that has already proven itself.

Everyone can come out ahead.

But an acquisition also changes something that is easy to underestimate: who owns the product vision ?

An independent RMS can start each day with a relatively simple question: how do we make Revenue Management better ?

Once it is part of a larger portfolio, the questions become different. How does it fit with the PMS ? What should be built centrally ? Where should we invest ? Which product should carry which feature ? How far should the RMS go relative to the other products in the portfolio ?

None of these questions is necessarily bad. In fact, a larger group can give an RMS more resources and speed up its development. But the logic is different. You are no longer optimizing a single product. You are optimizing a portfolio.

And when you acquire a specialist, you don’t just acquire its technology. You also acquire its vision, its culture and the way it makes product decisions.

The real question is what happens to all of that over time.

Stay independent: but be connected everywhere

There is a third path. The RMS stays independent. Not isolated. Independent.

The nuance matters. For a long time, the main argument against specialized technologies was integration. Hotels ended up with too many systems, too many interfaces and too many vendors.

That criticism was legitimate. But I don’t think the answer is necessarily to put everything under one roof. The alternative is to make independent systems work far better together.

But there is another preconception that I think is important to challenge: independent does not mean “small.”

Funding exists. A specialist can have the means to build a solid product, invest in technology and expand internationally without belonging to a larger group.

And size does not guarantee better execution either. In some cases the relationship can even be inverse: the larger an organization becomes, the more layers, processes and dependencies it adds, and the harder it can be to move quickly.

Being independent can simply mean being focused. 100% focused on one craft. From the very first marketing message, to the way the Sales teams understand the project, and above all in deployment, Account Management and understanding how the profession is evolving.

And this matters particularly in Revenue Management, because the technology cannot stand still. Innovation is not a one-off event. It is a permanent necessity. Many of the mechanisms described by economic theories of innovation point in the same direction: specialization, focus and the ability to experiment can be powerful drivers of innovation.

For an RMS, this ability to stay close to the profession may ultimately matter more than the size of the company behind it.

The PMS remains the operational system. The RMS remains the Revenue intelligence layer. The Channel Manager remains the distribution layer. And data flows between them

Hoteliers shouldn’t have to wonder which company owns which technology building block. They should simply ask whether the technology works. Does the data arrive in the right place? Are recommendations available at the right time? Are decisions pushed back into the operational systems? And, increasingly, can actions be automated?

The goal is not to have more software. The goal is to have less friction.

Integration is not consolidation

This is probably the most important distinction in this whole discussion.

People often confuse integration and consolidation. They are not the same thing.

Consolidation means bringing products, companies or features together under the same ownership. Integration means making different systems work together. You can have a single vendor with five products that remain poorly connected. And you can have several specialized vendors that operate as a single ecosystem.

So maybe the right question for hotels is not: how many vendors do I have ?

But rather: how much friction do I have ?

That changes the discussion completely.

Because if a specialized RMS is deeply integrated with the PMS, if data flows automatically and if decisions can be executed without unnecessary steps, does it really matter that the two products belong to different companies?

I don’t think so.

Revenue Management is a special case

This question is particularly important for the RMS because Revenue Management is a discipline that cannot afford to stand still. I have spent enough time around Revenue Management to know that the profession is constantly evolving. What worked five years ago is not necessarily enough today. And what works today will probably not be enough in five years.

But at its core, we are always trying to answer the same question: for this date and this unit, do I need Volume or ADR ?

nd if the designer, the publisher of the RMS, isn’t even asking this question properly, then you can add all the data you want, multiply integrations or embed the RMS natively in a PMS: you still won’t allow the user to benefit from the full intelligence of your platform.

AI does not change how we do our analysis. Math is still math. What it does change is our ability to scale and automate.

Revenue teams expect more transparency. Hotels want more automation, but they also want to understand why a decision was made.

For an independent RMS, this pressure is intense. But there is something healthy about it. An independent RMS has a very clear reason to exist: to make Revenue Management better.

If it stops doing that, hotels have very little reason to keep using it. This creates a very strong incentive to keep investing, experimenting and evolving.

To me, this is one of the strongest arguments in favor of specialization. Not because a specialist is automatically better. But because its survival depends on its ability to stay at the cutting edge of its profession.

And then comes the next layer of integration

For the last ten years, we have mostly talked about APIs. APIs changed Hotel Tech. They made it possible to build an ecosystem rather than one giant piece of software. But a new layer is now beginning to emerge.

AI agents and protocols like MCP could change the way software interacts with other software.

The challenge is no longer simply to move a piece of data from A to B. It is about giving a system access to the right context, the right expertise and the right actions.

Imagine an AI agent analyzing a hotel’s current situation. It can access operational context from the PMS. It can ask the RMS why demand has changed. It can understand the recommendation. It can explain it to the Revenue Manager. And, when authorized, it can execute the decision.

You have just imagined Revbell today and tomorrow.

In this world, the RMS does not need to become the PMS. It needs to be extremely good at Revenue Management and able to make that expertise available to the rest of the ecosystem. It is a very different vision of integration.

So, will the RMS become a simple PMS feature?

For some hotels, perhaps.

A native RMS can make Revenue Management simpler, more accessible and easier to use. That is real value. But it does not mean that every RMS should become a PMS feature.

There will always be hotels for which Revenue Management is too strategic, too complex and too dynamic to be treated as a simple checkbox. And I think that is where the market is heading toward an interesting balance.

The PMS can manage the operational workflow. The RMS can manage Revenue intelligence. The Channel Manager can manage distribution.

Specialists can remain specialists. And technology can make the whole thing feel like a single platform.

This is the model we believe in at Revbell

At Revbell, we have chosen to remain a specialist. Not because we think hotels need more systems. Quite the opposite.

We believe Revenue Management deserves a company whose attention is entirely devoted to Revenue Management.

But being a specialist does not mean being disconnected. Our RMS is, and must remain, deeply connected to the PMS. It must automatically retrieve the right data. It must send decisions straight back into the operational workflow.

And it must keep evolving at the pace of the profession.

For us, independence is not about staying apart from the ecosystem. It is about having the freedom to keep moving a profession forward.

Independent by design. Integrated by default.

Perhaps that is, in the end, the future of Hotel Tech. Not one platform that does everything. Not a collection of disconnected specialists. But an ecosystem in which every component can be excellent in its own field, while giving hoteliers the feeling of using one coherent technology stack.

And for Revenue Management, I think this distinction is going to matter more and more.