The problem with PMSs: how to approach choosing new hotel tech
Two hospitality tech experts break down why PMS selection is now driven by API openness and integration ecosystems, with practical guidance for independents and multi-property operators.
Photo by Mews
The property management system (PMS) has been at the center of hotel operations for decades. It survived the transition from paper ledgers to DOS terminals to Windows interfaces to the cloud.
And yet, for all that change, many hoteliers still find themselves trapped by it – locked into long contracts, constrained by aging architecture, and frustrated by systems that were never really designed around how a hotel actually runs.
A recent episode of the Matt Talks Hospitality podcast brought together two experienced voices in hospitality technology: Ira Vouk, a hotel tech adviser, speaker and author, and Simone Puorto, a consultant and head of emerging trends at Hospitality Net. They explored the history of the PMS, where it falls short, and what operators should actually be thinking about when they consider a change.
Here are the themes that matter most for GMs and owner-operators today.
The system was never designed around the job
For many hoteliers of a certain vintage, their entry into the industry involved overnight front desk shifts on DOS-based systems that required typed commands and memorized shortcuts. It was painstaking work, and the people who were good at it were good because they had mastered the software, not because they were exceptional at hospitality.
When hotels hired for system proficiency rather than guest instinct, they built a culture that prioritized technical compliance over service quality. And while cloud-native systems have largely closed that gap – with a modern platform, new staff can figure out basic functions in under a minute – the mindset hasn't always caught up.
The best technology should be like the lobby boy in The Grand Budapest Hotel: always present, never intrusive, anticipating what's needed without drawing attention to itself. In other words: not a system that requires three months of training to operate.
The fragmentation problem
Tech fragmentation is not just an inconvenience, but a structural issue that shapes how every segment of the industry operates.
The challenge is that no two hotels run the same way. Different ownership models, portfolio types and operational philosophies mean that vendors have spent decades building bespoke features for individual clients, stacking functionality on top of functionality until you have a Frankenstein system. Heavy, complex, difficult to train on and harder to leave.
For large franchise brands, the problem compounds. The franchisor, management company and owner each have different incentives, and technology investment at the property level is typically low on the list of priorities for shareholders. As a result, some of the biggest names in hospitality are running on tech debt that is now fifty or seventy years old. The window to address it, particularly with AI putting new demands on data infrastructure, is closing.
For independent operators, the barrier is different: fear. Changing PMS can feel so painful that many hoteliers who have been through it once will do almost anything to avoid doing it again. They know they will lose some data. They know retraining takes time. They know the process is disruptive. So they stay on systems that partially work rather than risk the transition – even when the systems are holding back their ability to innovate.
Yes, migration has become significantly less painful than it used to be. But perception lags reality, and that gap is part of what keeps operators stuck.
The integration question is now the decision
For a long time, PMS selection was driven by core functionality. How does it handle reservations, billing and reporting? The differences between systems at that level have largely narrowed. What separates the right choice from the wrong one today is the integration layer.
If a PMS has a closed or costly API, the operator is limited to whatever that vendor has chosen to build. Every additional system – revenue management, CRM, channel management, housekeeping – becomes a negotiation rather than a connection. At the other end of the spectrum, an open, well-documented API means a hotel can assemble a tech stack that genuinely reflects how it operates, rather than bending its operations to fit whatever the PMS allows.
This was one of the driving ideas behind Mews Marketplace: a curated ecosystem of integrations that a hotel can plug into without paying connection fees or relying on a single vendor's development roadmap. For operators evaluating a new system, the breadth and quality of that marketplace should rank alongside core functionality.
Segment shapes everything
You can't apply a single framework to an industry that contains several distinct ones operating under the same name.
An independent operator running a fifty-room property in Southern Europe has almost nothing in common, technologically, with a thirty-property portfolio company in North America or a global franchise group. The first wants one login and one bill – an end-to-end solution that doesn't require a consultant or an IT department to run. The second wants the flexibility to select best-of-breed components and assemble them around a specific way of doing business.
The vendors that try to serve everyone equally well tend to serve no one particularly well. The operators who make the best technology decisions are the ones who are honest about which category they're in before they start looking.
How to approach a PMS decision
For independent or single-property operators without a large IT budget: start with a clear list of use cases – not features. How does your hotel actually run? What does the front desk do between 11pm and 6am? Where do your reservations come from? How do you manage rates?
Build a list of fifty to one hundred parameters, schedule demos with five shortlisted systems, and ask for a live demo environment rather than a guided walkthrough. Test it yourself.
For operators managing twenty or more properties: bring in a consultant. The number of variables – integration dependencies, data migration, payment systems, staff retraining, contract terms – is high enough that the cost of getting it wrong significantly exceeds the cost of getting expert help to get it right.
In both cases, there are four questions worth asking any vendor before going further.
Is the system truly cloud-native – not migrated to the cloud, but built there from day one?
Are the APIs open and well-documented?
Does the vendor carry any significant technical debt?
Does the vendor have a credible AI roadmap, including agent and MCP integration?
The name is part of the problem
The PMS acronym is probably the worst in the industry. Property management system implies a system that manages a property. No single system does that, and the ones that claim to often do the most important things least well.
The hospitality industry is slowly moving toward a different framing – hub, connector, operating system – that better reflects what a modern hotel actually needs at its technical core. A foundation that handles the basics seamlessly, opens cleanly to the tools that sit around it, and gets out of the way of the people doing the work.
That shift in language reflects a more important shift in expectation. The PMS was once the center of hotel technology. What replaces it should be something more like infrastructure: invisible, reliable and genuinely designed around how hospitality works.
The conversation on Matt Talks Hospitality is a useful starting point for any hotelier who wants to think through what that means for their property.
Comments
Comments for this content
0 comments available