Why Hotels Need Open Hotel Protocols

When I began my career in hospitality more than a decade ago, I accepted something almost everyone in the industry accepted without question: every hotel revolves around its Property Management System. If you want to operate a hotel, you choose a PMS, implement it, train your employees, integrate every department into it, and gradually build your operations around its capabilities. At the time, that seemed perfectly reasonable.

The PMS was where reservations were stored, rooms were assigned, bills were generated, reports were produced, and guest histories were maintained. Every department depended on it, every employee was trained to use it, and it was difficult to imagine a hotel operating without one.

After eleven years working across hotel operations, revenue management, and distribution, I no longer believe the PMS is the center of a hotel. More importantly, I no longer believe it should be.

This isn’t because today’s PMS vendors have built poor products. Many of them solve incredibly difficult problems and have helped the hospitality industry modernize over several decades. The issue is much deeper than product quality—it is architectural. The assumptions that gave birth to the Property Management System belong to another era of computing. The world around hotels has changed dramatically, but the software that operates them is still based on the same mental model.

Cloud infrastructure replaced on-premises servers. Mobile applications replaced desktop clients. APIs replaced file transfers. Artificial intelligence is now being layered onto existing workflows. Yet the architecture underneath remains largely unchanged. We keep modernizing the vehicle while keeping the same engine. The more time I spent inside hotels, the more I realized the industry was solving yesterday’s problems with yesterday’s abstractions.

The original purpose of a PMS

It is easy to criticize legacy software, but doing so misses an important point: the Property Management System was the right solution for its time. When early PMS products emerged, computing resources were expensive, networking was limited, and enterprise software existed primarily to record transactions. Organizations needed a centralized system that could track reservations, room inventory, guest accounts, payments, and operational records with accuracy and consistency. The PMS solved exactly that problem and gave hotels a reliable system of record.

As technology evolved, vendors naturally extended the system. Modules were added for housekeeping, maintenance, finance, customer relationship management, channel management, and revenue management, until these systems became comprehensive enterprise platforms. This evolution made perfect sense because enterprise software itself evolved in the same direction. Every new business function became another module, every operational need became another screen, and every department received another workflow. The software grew larger, but the underlying philosophy stayed the same: humans operated the software, and the software stored the business.

For decades, that model worked remarkably well. The question is not whether it worked—it’s whether it still represents the best way to operate a hotel in the age of artificial intelligence.

What actually runs a hotel?

One realization changed the way I think about hospitality. Hotels do not run on software. They run on knowledge.

The software records that Room 1205 has been cleaned; knowledge determines which room should have been cleaned first. The software records that a guest received a complimentary upgrade; knowledge determines whether offering that upgrade will build loyalty or quietly erode future revenue. The software records today’s room rate; knowledge determines why that rate should change tomorrow. The software records a service recovery; knowledge determines what recovery is appropriate, when exceptions should be made, and how those decisions reflect the hotel’s values.

Every successful hotel depends on thousands of decisions like these. Some are written down. Many are not. Experienced managers carry them in their heads, department heads pass them to new employees through coaching, general managers develop instincts that are difficult to explain but easy to recognize, revenue managers build mental models from years of observing market behavior, and housekeeping supervisors understand operational patterns that never appear inside the PMS. These are not software features. They are organizational knowledge.

Once I started looking at hotels this way, something became obvious: two hotels using exactly the same software can produce completely different business outcomes. If software were truly the source of competitive advantage, that should not happen. The difference lies elsewhere—in how each organization captures, applies, and continuously improves its operational knowledge.

The limits of standard operating procedures

Historically, hospitality has tried to preserve knowledge through Standard Operating Procedures, and this approach has served the industry well. Every major hotel brand has invested decades refining service standards, operational checklists, training manuals, and quality assurance programs. These documents let organizations replicate experiences across hundreds of properties around the world.

The challenge is not that SOPs are wrong. The challenge is that documents are static while businesses are dynamic. Guest expectations change constantly, distribution channels evolve every year, search algorithms shape purchasing behavior, economic conditions shift, and artificial intelligence introduces entirely new ways of working. Yet many operational procedures remain unchanged for months or years.

When the environment evolves faster than the documentation, organizations compensate through human experience. Employees develop shortcuts, managers invent new practices, revenue teams discover better pricing strategies, and individual hotels adapt to local culture in ways that never appear in official documentation. Over time, the organization accumulates two versions of knowledge: the knowledge written inside the SOP, and the knowledge that actually operates the business. These two versions slowly drift apart—and, ironically, the more experienced an organization becomes, the larger that gap often grows.

From documents to living knowledge

The question I kept asking myself was surprisingly simple. What if operational knowledge did not have to live inside documents? What if it could become part of the operating system itself?

Instead of asking employees to read a procedure and translate it into actions, what if the knowledge could be represented directly as executable protocols? A protocol could describe how housekeeping priorities are determined. Another could represent revenue optimization strategies. Another could define complaint handling, loyalty recognition, financial controls, procurement policies, or staffing rules.

Unlike documentation, these protocols would not simply describe how work should be performed—they would actively participate in the work itself. Humans could understand them, software could execute them, AI agents could reason about them, and organizations could continuously improve them as new knowledge emerges. At that moment, knowledge stops being an archive and becomes infrastructure. That realization became the foundation for Open Hotel Protocols.

Introducing Open Hotel Protocols

Open Hotel Protocols, or OHP, is not another Property Management System. It is an open specification for representing hospitality knowledge as executable operational protocols. The distinction may seem subtle, but it changes the role of software completely. Traditional enterprise systems place the application at the center of the business; OHP places operational knowledge at the center instead.

Every capability within a hotel becomes a protocol rather than a feature: checking in a guest, preparing a VIP arrival, forecasting demand, scheduling housekeeping, managing maintenance, closing the financial period, responding to guest complaints, coordinating food and beverage operations. Each protocol defines not only the data involved but also the reasoning behind the work. Business rules, service philosophy, regulatory requirements, organizational policies, and decision logic become first-class components of the operating model.

The protocol becomes the authoritative description of how the organization functions, and applications become just one possible way of interacting with that knowledge.

The agentic era changes everything

Artificial intelligence introduces something fundamentally different from previous generations of software. For the first time, enterprise systems are no longer used exclusively by humans. AI agents are becoming active participants in business operations—they can interpret intent, retrieve information, execute workflows, collaborate with other systems, and learn from previous interactions.

This shift has enormous architectural implications. If software will increasingly be consumed by AI agents rather than people, then graphical interfaces should no longer be considered the primary way of accessing enterprise capabilities. Instead, software should expose those capabilities through well-defined protocols. This is one reason I believe standards such as the Model Context Protocol are so important: they let AI agents interact with complex business systems through structured interfaces rather than screen automation or brittle integrations. In an agentic world, the protocol matters more than the dashboard.

Every person deserves different software

Enterprise software has traditionally assumed that everyone inside an organization should use essentially the same application. The receptionist sees one menu, the revenue manager sees another, the finance department sees another. Permissions change, but the application stays largely identical.

I suspect this assumption will disappear over the next decade. Different people think differently, ask different questions, and solve different problems. There is little reason why a housekeeper, restaurant manager, hotel owner, accountant, and engineer should all navigate the same interface simply because they belong to the same organization.

If operational knowledge exists independently through Open Hotel Protocols, then every interface becomes replaceable. Some employees may prefer a mobile application, others may prefer voice, some may work entirely through an AI assistant, and others may build lightweight applications tailored specifically to their daily responsibilities. Using an SDK together with the Model Context Protocol, organizations should be free to design experiences around people instead of forcing people to adapt to enterprise software. The remarkable part is that none of these interfaces need to sacrifice capability—they all interact with exactly the same operational protocols.

Why Urbanerve exists

Urbanerve was born from this vision. It is not intended to become another proprietary PMS competing on feature lists. Instead, Urbanerve is the first complete implementation of Open Hotel Protocols, built to demonstrate what becomes possible when a hotel is designed around executable knowledge rather than transactional software.

I deliberately describe Urbanerve as a reference implementation because I do not believe a protocol should belong to a single company. The internet succeeded because HTTP was open. Linux transformed computing because thousands of organizations could build upon it. The Model Context Protocol is accelerating AI interoperability because it provides a common language between models and applications. Hospitality deserves an equally open foundation.

If Open Hotel Protocols succeeds, I hope other companies build products on top of it, consultants publish protocols based on decades of operational expertise, hotel groups encode their own philosophies while remaining interoperable with the broader ecosystem, and developers create specialized AI agents that solve problems I have not even imagined. Urbanerve does not need to own every part of that future. It simply needs to help make that future possible.

Looking forward

Recently, Y Combinator published several Requests for Startups describing the kinds of companies they hope founders will build. What caught my attention was not a particular technology but a shift in philosophy: they argued that the next generation of AI companies should move beyond wrappers and incremental SaaS improvements. Instead of simply helping people use existing software more efficiently, they encouraged founders to rethink how services themselves could be delivered in an AI-native world. Reading those ideas was reassuring, because they echoed many of the questions that had been forming in my own mind while working in hospitality.

What happens when AI becomes an active participant in hotel operations? What happens when knowledge becomes executable instead of documented? What happens when software is designed equally for humans and intelligent agents? I do not claim to know all the answers. What I do believe is that the Property Management System, as an architectural concept, is approaching the end of its natural evolution.

Hospitality will continue to evolve, just as every other industry has evolved alongside advances in computing. The next generation of hotel operations will likely be shaped less by larger applications and more by shared knowledge, interoperable protocols, and intelligent agents capable of executing that knowledge on behalf of people. Open Hotel Protocols is my proposal for that future—and Urbanerve is simply where I have chosen to begin.