Property management systems (PMSs) fundamentally have changed very little since the 1980s. And many hotels still use systems that were built in the eighties, nineties, or aughts. Since then, massive technology changes have occurred: the mobile revolution, cloud computing, distributed ledgers, AI-based large language models, Web 3.0, and other innovations have fundamentally changed both the technological capabilities of software, the way it is designed and built, and expectations for user experience.

And yet, most PMSs still do the same things they did in the 1980s, and mostly in the same way. They support hotel staff in managing rates, allocating rooms, tracking housekeeping status, checking guests in and out, managing folios, and providing daily financial and operating summaries. Some may include light- or medium-weight functionality for point-of-sale, housekeeping, group sales, revenue management, or other hotel departments. Many include guest profile management capabilities, although these are limited compared with true Customer Relationship Management (CRM) systems. Most PMSs of all ages interface with guest-facing systems such as door locks, televisions, telephones, and thermostats; in recent years, some have added captive Wi-Fi portals and mobile apps to the list.

The only significant change in PMSs from the 1990s is that most have added support for various elements of electronic distribution, such as central reservation systems, web booking engines and channel managers.

PMSs support hotel staff through various user interfaces (UIs) designed for the front desk, reservations, back office, and other functions. In more recent years, many PMSs have opened up Application Programming Interfaces (APIs) to enable guests to interact via web or mobile apps, but only for limited purposes and often with significant restrictions.

It the above describes your PMS, it is obsolete. And PMSs are only just starting to change, in fits and starts.

‍Is Your PMS Obsolete?

‍To be sure, many newer PMSs follow the software design principles of MACH architecture, which is considered state-of-the-art. For these, it is not the architecture that is obsolete; it is the application itself.

In our mobile-enabled world, more and more guests want self-service options. Some (notably many millennials) may prefer self-service every time; most people want the option at least sometimes. Many hotels, particularly in the economy segment, also want to embrace self-service because it can reduce labor requirements.

The back-end business processes of a PMS are mostly the same whether they are initiated by a hotel staff member or by a guest using self-service. The UI cannot be the same, however; guests’ needs for simplicity and clarity are greater than those of hotel staff, and we do not want guests overriding hotel policies without staff approval. Security settings will also differ; guests using mobile check-in need to be prevented from actions like upgrading themselves to a suite or comping their stay, which staff may sometimes need to do.

Certain steps might need to be added in the guest-facing version, such as verifying identification at check-in (something handled manually in staff-assisted check-ins). But these kinds of variations are easily handled by modern software design; the underlying process (verify payment, select and assign a room, create a folio, encode a room key, and activate in-room devices) is the same in the self-service vs. colleague-assisted cases.

Despite the common underlying business processes, very few PMSs support guest-facing interfaces directly. There are many exceptions for booking engines, but otherwise, most PMSs leave it to third parties (such as mobile app developers) to provide guest-facing capabilities via APIs.

This works to a degree, but often fails with edge use cases that the API was not designed to handle, that the mobile app developer did not contemplate, or where the compromises were dictated by the mobile app’s need to maintain a single code base while interfacing to multiple PMSs with different underlying data models and business processes.

Additionally, APIs (especially those for cloud-native systems) can break when one of the connected systems undergoes a version upgrade. This is rarely a problem when the API and both connected systems come from the same vendor and upgrades are coordinated. But it is unfortunately too common when multiple vendors are involved.

Virtually all modern software maintains the code that controls UIs separately from code that manages business logic, data storage, connectivity, and other functions. And it is common for PMSs to provide different UIs for different staff roles or tasks. Yet despite this, and even with the massive shift towards self-service, few PMSs provide even a single guest-facing UI beyond the booking engine.

The right design for today’s need is a core set of underlying functionalities, but with separate UIs and (where needed) workflow variations for staff vs. guests. These should be optimized for the appropriate devices, from PCs at the front desk to tablets for roving staff to mobile phones and kiosks for guests. With this design, the process can be seamless even as a guest moves from one mode to another: perhaps starting their check-in via mobile, getting sidetracked and finishing the process at a kiosk or with a hotel colleague at the front desk. There should be no need, ever, to re-enter information previously provided, even if a transaction is only half-completed in one environment and then picked up in another. And changes made anywhere should be reflected instantly everywhere.

None of this is rocket science.

‍Who Represents the Next Generation of PMS?

‍I looked through the websites of about twenty of the leading PMS platforms, including all the commercial ones used by major brands, to see which of them highlighted native (not third-party) guest-facing as well as staff-facing functionality (other than a booking engine, which most modern PMSs now support). These could include self-service check-in and check-out, upselling, room controls, food and beverage ordering, activity scheduling, guest requests, surveys, chat, and other functions.  While websites do not cover every capability of these systems, one can assume that the functionality highlighted on the website generally correlates to the underlying product design (or if it doesn’t, it should!).

A few of the websites mentioned one or two native guest-facing capabilities, such as self check-in and check-out via a kiosk, or a mobile food and beverage ordering module. Most, however, focused exclusively on staff-facing functionality, except for the booking engine.

Only four products (three younger companies – Mews, Shiji, and Stayntouch, plus one more established one – Maestro PMS) stood out as having rethought the process to recognize the growing importance of fully integrated self-service for all or most hotel functions. I cannot say for sure that their underlying code follows the principles as completely as the websites suggest; there are always compromises. But if I were in the market for a PMS today, I would be looking for a company that has fully internalized self-service. Not many meet this criterion today; I hope to see many more in the coming months and years.

I only reviewed the websites of the larger PMS companies. There are at least 1000 PMS products in the market globally, more than anyone can look at in detail. Among all of these are certainly others that share this design. Some of these products are quite good and are viable for certain hotels now. But they typically support only limited geographic regions or market segments, and consequently have not achieved the scale that would make them a credible solution for mainstream companies with multiple hotels scattered across multiple locations. There are undoubtedly a few undiscovered diamonds in the rough, but unfortunately the number is small.

‍Conclusion

‍As an industry, we talk about the need to embrace the digital guest, but that does not simply mean putting an app on their phone that communicates (often imperfectly or erratically) with your PMS via APIs. A truly connected experience requires a truly connected architecture, where the staff and guest use the same underlying systems and logic, just with different UIs and security parameters. As you start to think about YOUR next PMS, try looking at it from the guest standpoint, not just your staff’s.