Your Hotel’s Innovation Ceiling May Be Hidden in the PMS

The first sign that a PMS is holding a hotel back rarely appears as a major failure. The system remains up, reservations come in, Front Desk completes check-ins, charges are posted and the night audit is completed, hopefully before breakfast begins. From a strictly functional perspective, everything appears to be under control. Yet every time the hotel attempts to change an experience, connect a new service, automate a task or better understand its guests, it begins a pilgrimage of queries, development work, files, permissions and explanations that turns a reasonable idea into a small engineering project.

It took me quite some time to understand that this friction was not an inevitable consequence of hotel complexity. For years, I myself accepted that certain initiatives required months because they affected the PMS, as though mentioning those three letters ended any discussion. We learned to design processes around the system’s limitations, ask the team to enter the same information in several places and call any overnight file exchange that arrived complete on most days an integration. Most concerning of all, we ended up considering normal what was merely common.

A PMS can be stable, familiar to the team and reasonably cost-effective, yet still act as an innovation ceiling. The problem arises when the system can represent only part of the business, forces operations to adapt to its internal structure or makes it difficult for other processes to use data with the necessary speed and context. The hotel then begins to innovate only within what the PMS allows. Ideas that fit move forward; those requiring different logic are postponed, simplified or abandoned before they are ever tested.

This situation affects far more than the IT department. It shapes hotel marketing, because it limits segmentation and data activation; it affects hotel revenue management, because it reduces the quality or timeliness of information; it complicates the guest experience in hotels, because preferences and commitments do not always reach those who must deliver on them; and it increases operating costs, because too many connections depend on manual tasks. The PMS ends up quietly influencing strategy, although it almost never has a seat in the meeting where that strategy is approved.

My view of this issue is critical, but also optimistic. Today, there are more options for separating hotel direction from the limitations of a single system, provided we stop asking what features a PMS comes with and start defining which capabilities the business needs to retain. That change may seem semantic, but it completely transforms the conversation. The objective is no longer to buy a more modern programme, but to build a hotel that can learn, connect, test and change without requiring technological permission for every relevant decision.

The PMS does not merely record the hotel; it also defines which hotel can exist

In many organisations, the PMS is presented as the hotel’s central system. The expression seems reasonable, although it contains an important ambiguity. It is one thing for the PMS to maintain essential records of reservations, stays, rooms, charges and profiles. It is quite another to turn it into the complete intellectual model through which we interpret the business. When those two functions are confused, the system stops being a tool and begins to behave like an operating constitution.

Every piece of software embodies a particular way of understanding the hotel. It decides which entities exist, how they relate to one another, which fields are mandatory, which events trigger an update and which permissions a person needs in order to act. If the system understands a room perfectly but barely grasps the context of a guest relationship, the hotel will end up managing inventory better than hospitality. If it recognises a reservation but not the operational commitments that reservation activates, we will see availability where there may already be overload. If it stores a preference without distinguishing its validity, source or permission for use, we will accumulate data without building genuine knowledge.

The most dangerous limitation is not the one the PMS displays, but the one that makes us stop imagining alternatives. I remember projects in which a good idea was dismissed with an apparently innocent question: “Where would we put that in the PMS?” The right question was different: “What outcome do we want to create for the guest and for operations?” By reversing the order, we had turned the software structure into the boundary of hotel strategy.

The market is evolving towards architectures with APIs, events, integration environments and broader access to reservation, guest, operational and payment data. However, the existence of an API in a commercial presentation does not guarantee that the hotel can use it freely, that it includes the necessary fields, that it works in both directions or that it updates information at the required speed. Technological openness is not declared; it is demonstrated through real use cases. Current documentation itself shows important differences between querying data, modifying it, receiving events and running complete processes from external applications. ([cloudbeds.com](https://www.cloudbeds.com/api/?utm_source=openai))

A recent study of 450 experienced hotel professionals placed integration speed among the priorities for PMS evolution. The same study identified training and data migration among the main barriers to change. It is a revealing combination: we need more open systems, but the difficulty of replacing them helps keep in place the very systems that limit that openness. ([hoteltechreport.com](https://hoteltechreport.com/news/2026-hotel-pms-report?utm_source=openai))

I have learned to look for five symptoms indicating that the PMS has stopped supporting the hotel’s evolution. None alone proves that it should be replaced, but their accumulation reveals a capability debt that deserves strategic attention.

• The hotel enters the same information more than once. Reservations, Front Desk, Housekeeping, Food and Beverage, Sales or Finance maintain parallel files because the PMS does not capture the right data, does not display it where it is needed or does not allow action to be taken on it. Duplication is not merely a loss of productivity. Every copy creates an additional version of the truth, adds the risk of outdated information and forces the team to decide which one to trust.
• Important exceptions live outside the system. Sensitive arrivals, commercial commitments, special requirements, group agreements or still-open issues end up in emails, internal messaging, shared documents and notebooks. The PMS retains the reservation, but the hotel depends on a side conversation to fulfil it. At that point, the system records the transaction while the organisation tries to manage hospitality through other channels.
• Every innovation requires manual translation. A new tool may generate recommendations, requests or useful information, but someone must convert them into tasks, notes or changes within the PMS. Then someone else must retrieve the outcome and communicate it back to the originating system. The integration exists on a slide; in operations, several people act as human middleware.
• Data access depends on reports designed for another era. The hotel has information, but can only consult it through closed reports, periodic exports or requests to the vendor. When a new question takes weeks to answer, the problem is no longer analytical. It is a governance limitation affecting hotel management, marketing, Revenue Management, workforce planning and hotel profitability.
• Decisions are subordinated to the vendor’s timetable. Changing a rule, adding a field, activating a connection or correcting a process depends on external development work, priorities and budgets. Waiting may be reasonable when a modification involves technical risk. It ceases to be reasonable when the hotel needs permanent authorisation to evolve in activities that form part of its value proposition.

These symptoms create what I call the operational translation tax. It is the set of hours, errors, waits, reconciliations and controls required for the hotel’s reality to be expressed in a system that was not designed to understand it completely. It does not usually appear as a separate item in the profit and loss statement. It is dispersed across payroll, overtime, administrative tasks, compensation, commercial delays and opportunities that are never implemented.

Consider a late check-out request. To make the right decision, we may need to know forecast occupancy, the estimated arrival time of the next reservation, Housekeeping status, room type, rate, guest benefits and the day’s operational pressure. If that information lives in different systems, someone will have to reconstruct it for every request. The guest receives an answer, but the hotel pays several minutes of coordination. Multiplied by hundreds of decisions, those minutes become lost capacity.

Something similar happens with personalisation. A hotel may store thousands of preferences and still be unable to use them safely at the right moment. Innovation is not about having more data, but about ensuring that relevant information reaches a specific decision. That is why I have argued that loyalty should mean that guests need to ask for less. If the PMS retains the benefit or preference but operations cannot deliver it without manual checks, we have digitised the record, not the experience.

It is also worth challenging the idea that the PMS must necessarily be the brain of the entire hotel. A brain that tries to do everything may end up becoming an extraordinarily well-documented bottleneck. I prefer to think of the PMS as a reliable record of certain essential facts within a broader architecture. This distinction allows us to demand stability and accuracy from it without forcing it to solve CRM, marketing, Revenue, maintenance, communication, payments, loyalty, operations and the guest experience on its own.

Misunderstood centrality causes two opposing errors. The first is adding modules to the PMS simply to avoid integrations, even when those modules are less suitable than other solutions. The second is procuring multiple tools without defining which system maintains each data point and what happens when discrepancies exist. In one case, we sacrifice specialisation; in the other, we build an archipelago of applications that exchange information with the same coordination as several guests trying to enter a lift at once with their luggage.

The right architecture does not depend on the number of tools, but on the clarity with which we distribute responsibilities. The hotel must know where each data point originates, who can modify it, which system maintains the authorised version, which events must be communicated and how much delay is acceptable. This discipline is particularly important because, as I explained when analysing the control we relinquish when procuring technology, every platform we add also absorbs part of our knowledge and operational capability.

Replacing a PMS does not automatically solve this problem either. I have seen expensive migrations that transferred the same poor practices into a more pleasant interface. Unnecessary fields were copied, codes that no one understood were retained and reports that had not supported a decision for years were rebuilt. The hotel changed systems without changing its way of thinking. The result was a visually modern but operationally conservative transformation.

Before discussing vendors, it is worth identifying the PMS’s silent zones: those parts of the business that the system cannot represent with sufficient precision. They may include relationships between guests, travel purposes, service commitments, preferences with expiry dates, costs associated with a reservation, space utilisation, operational restrictions or pre-purchase interactions. Every silent zone forces the team to improvise an alternative memory.

Not all of these zones should be incorporated into the PMS. Some will belong in the CRM, others in an operational platform, Finance or a data layer. What matters is that they do not remain ownerless. An innovative hotel is not one that accumulates more software, but one that can explain where every significant part of its reality resides and how it reaches the people who must act on it.

Leading through capabilities changes the PMS conversation

The new way of approaching this issue begins by stopping the evaluation of the PMS as a list of features. Commercial demonstrations usually take us through screens, menus, automations and reports. Everything appears possible because the environment is clean, the data fits and no integration has decided to take the afternoon off. Real operations are less accommodating. They contain duplicates, exceptions, room changes, amended reservations, partial payments, related guests, accounting close-outs and policies that vary according to the moment.

I prefer to assess the system through hotel capabilities. A capability expresses something the business must be able to do reliably, repeatedly and measurably. For example, recognise a returning guest, amend a promise across all channels, calculate the net contribution of a reservation, respond to a request with context or trigger a task when a stay condition changes. The technology function is only one part. Data, rules, permissions, owners and follow-up are also involved.

This approach prevents the conversation from being hijacked by the vendor or the catalogue. The hotel first defines the capability and then determines which part the PMS can provide, which part requires another system and what coordination must exist between them. Technology thus returns to its proper place within hotel strategic planning.

The Innovation Friction Map

To diagnose the PMS’s real ceiling, I use an exercise that can be carried out without launching any tender process. It consists of selecting between five and ten relevant initiatives for the next two years and subjecting them to an Innovation Friction Map. They should not be abstract features, but changes the hotel wants to implement: personalise an arrival, sell a new product, automate a request, improve profitability per reservation or better coordinate Housekeeping and Front Desk.

Each initiative is reviewed through six questions:

• Representation. Can the current ecosystem accurately describe what we want to manage? If we want to sell an experience linked to a stay, we need to know whether the system understands the product, its availability, its relationship with the reservation, its conditions and its fulfilment. When there is only a free-text field, information may be stored, but it can hardly be governed.
• Access. Can we obtain the required data with the right level of detail, permissions and frequency? Downloading a report at the end of the day is of no use for a decision that must be made during check-in. An integration that delivers incomplete data may be technically correct and operationally useless.
• Action. Does the system only allow consultation, or can it also modify, confirm and close the process? Many connections read reservations but cannot update certain statuses, record the outcome or return a decision. Half an integration usually leaves almost all the work manual.
• Timeliness. How much time passes between the event and its availability for action? In Hospitality, five minutes may be irrelevant for a monthly report and excessive when preventing an incorrectly assigned room. Data quality includes its timeliness.
• Governance. Do we know who can change the information, which system prevails and how an error is corrected? Without this definition, every integration adds speed but also multiplies the possibility of propagating a mistake.
• Economics. How much does it cost to build, maintain and adapt the capability? The initial price of the connection presents an incomplete picture. We must include fees, support, testing, updates, monitoring, training and the cost of tasks that will remain manual.

The outcome can be classified into four situations. The first is direct fit, when the PMS allows the capability to be delivered without major changes. The second is internal configuration, when the system can do it but requires processes, permissions or parameters to be reviewed. The third is coordinated extension, when it is advisable to use another solution connected to the PMS. The fourth is structural blockage, when the current architecture prevents the capability from being developed at an acceptable cost and risk.

This classification brings calm. It avoids replacing a PMS over a minor limitation and, at the same time, prevents us from normalising strategic blockages. Not every friction justifies a migration. Some require cleaning up configurations, training the team more effectively or eliminating processes that should never have existed. Others indicate that we are trying to build the hotel’s future on a foundation that only permits minor renovations.

Measuring the cost of a PMS that appears to work

The difficulty in assessing an ageing PMS lies in the fact that its costs are dispersed. The vendor’s invoice may be competitive while the organisation pays the remainder through invisible work. To correct this perception, I use several indicators that complement the usual availability and support metrics:

• Time to viable change. This measures the days between approval of an improvement and its stable use by the team or guest. It includes configuration, integration, testing, training and corrections. A system may offer many features and still have a pace of change that is too slow for the hotel’s strategy.
• Double-entry minutes. This adds up the time spent entering, copying, verifying or reconciling information between the PMS and other tools. It should be measured by process and multiplied by its frequency. Five minutes seem insignificant until they are repeated hundreds of times a month.
• Percentage of exceptions outside the system. This identifies how many relevant situations require emails, documents, external notes or personal memory to be resolved. The higher this percentage, the lower the hotel’s ability to ensure continuity between shifts and departments.
• Decision latency. This calculates how long the necessary information takes to reach the person who must decide. This metric is particularly useful for assignments, requests, incidents, service availability and commercial opportunities.
• Annual adaptation cost. This includes development work, connectors, maintenance, consultancy, testing, training and the internal resources required to sustain the architecture. The objective is not to punish the PMS, but to compare alternatives using the total cost of capability rather than the licence alone.
• Abandoned innovation rate. This records initiatives that were conceptually approved but postponed or discarded due to integration, data or configuration limitations. It is one of the most uncomfortable indicators because it reveals opportunities that never appear as accounting losses.

From this data, we can estimate the PMS innovation tax: the additional share of time, cost and risk the hotel bears in order to implement an improvement because of the restrictions of its current architecture. There is no need to achieve academic precision. It is enough to develop a consistent estimate that makes it possible to compare the cost of retaining, supplementing or replacing the system.

This logic also changes how we calculate return. An integration should not be justified solely by the hours it saves. It may reduce errors, accelerate revenue, improve conversion, protect the guest experience or enable products that could not previously be sold. Hotel innovation creates value when it changes decisions and outcomes, not when it adds another icon to the desktop.

A good example is ancillary products. If the hotel wants to market services, experiences or vouchers, but the PMS only understands accommodation and charges, the team often creates parallel solutions. The problem is not that another application exists, but that the reservation, payment, availability and fulfilment become disconnected. The experience gained by designing gift vouchers integrated into the commercial and operational relationship demonstrates that innovation requires connecting the sale to the real capacity to deliver it.

Optimise, work around or replace

After the diagnosis comes the most delicate decision. In my experience, there are three legitimate paths, and none should be chosen out of technological enthusiasm.

Optimising the current PMS is the right option when the platform has underused capabilities, configuration has deteriorated or internal processes create more friction than the system itself. Before declaring a tool obsolete, it is worth reviewing roles, profiles, automations, catalogues, rules, active interfaces and data quality. Sometimes, the hotel is using a historical version of itself within a system that could offer considerably more.

Working around the PMS with a coordinated architecture is appropriate when the system remains reliable for reservations, inventory, stays and billing, but should not take on functions for which it was never designed. An integration layer, CRM, operational tool or experience platform can extend capabilities. For it to work, we must define data owners, events, permissions and recovery procedures precisely when a connection fails.

Replacing the PMS makes sense when the blockage affects several strategic capabilities, the annual adaptation cost is growing, data remains inaccessible, integrations are fragile or the vendor lacks an evolution roadmap compatible with the hotel. Migration then ceases to be an IT project and becomes a business decision about how we want to operate in the coming years.

The choice must also consider commercial strategy. A hotel seeking to improve direct sales, develop new products, personalise services or better manage the contribution of each reservation needs an architecture capable of relating inventory, customer, cost and context. There is little point in applying sophisticated criteria to decide which demand should be granted access to inventory if systems cannot share the information required to execute that decision.

Before signing off on a replacement, I recommend carrying out an Innovation Capability Test. This involves selecting three use cases that the hotel still cannot execute satisfactorily and asking each alternative to demonstrate the complete process using realistic data and exceptions. It is not enough to show a screen. The vendor must show what information it receives, how it interprets it, what action it permits, what happens if it fails and how the outcome is recovered.

The three cases should represent different levels of complexity:

1. A frequent operational improvement, such as coordinating a late check-out, a priority room or an open incident between shifts. It makes it possible to verify speed, permissions and traceability.
2. A commercial capability, such as selling a service linked to a stay, recognising a rate condition or activating a relevant opportunity without overwhelming the guest. It serves to assess the relationship between PMS, marketing, Revenue and operations.
3. A cross-functional decision, such as calculating the contribution of a reservation, identifying a capacity constraint or coordinating information across several properties. It reveals whether the architecture can support more strategic hotel management.

I would also request a demonstration of export and continuity. Not to repeat the debate on dependency, already addressed when discussing practical technology exits, but to verify the quality of the information model. A system that can receive data but cannot return it with understandable structure, context and relationships makes the hotel’s future learning more difficult.

The PMS must earn its centrality

The most liberating idea I have found along this journey is that no system should be central by tradition. It must earn that centrality through the quality with which it supports the business’s critical capabilities. Some functions deserve to remain in the PMS because of their need for transactional consistency. Others will work better on specialised platforms. What matters is that the hotel retains governance of the whole.

That governance requires a small, stable group involving Operations, Sales, Revenue, Finance and those who administer the systems. There is no need to create a ceremonial committee that meets twice a year to admire an application inventory. There is a need to review specific decisions: which capabilities we want to develop, what data they require, what friction exists and who is accountable for the outcome.

The agenda should include, at a minimum, these questions:

• What business change do we want to achieve? The conversation must begin with the guest, the team, the revenue, the margin or the risk we aim to improve, never with a newly discovered tool.
• Which system should know each fact? A reservation, a preference, an incident, a commercial opportunity and a payment have different life cycles. They do not need to live in the same place, but they do need to maintain clear relationships.
• What manual work will remain? Every implementation leaves an operational residue. If we do not measure it before procurement, it will later appear during the shift of someone who probably did not participate in the purchase.
• What authority does the hotel retain? We must know what the team can configure, what depends on the vendor and how long each type of change takes. The pace of evolution is a contractual condition, not a pleasant surprise afterwards.
• How will we know that the capability works? Implementation ends when an observable outcome changes, not when the vendor activates the licence.

This way of governing technology is closely linked to a broader vision of the hotel capable of understanding and deciding better. The important leap is not to automate everything possible, but to design an organisation in which systems share context, people retain judgement and every relevant decision can become learning.

When we work this way, the PMS stops being an excuse and also stops being an enemy. It can remain an essential component, but it no longer has the right to define the boundaries of what is possible on its own. Strategy regains priority, and the technology architecture is designed to serve it.

My advice is not to begin by asking whether the time has come to change PMS. First, create a list of the ten decisions, experiences or capabilities your hotel needs to improve over the next two years. Then determine which ones the current architecture can support, how much additional work it requires and which initiatives it is forcing you to abandon. That conversation produces far more clarity than a hundred feature comparisons.

Nor should you turn migration into a promise of salvation. Changing PMS can open possibilities, but it can also amplify poorly designed processes, deficient data and ambiguous responsibilities. Use any renewal to decide which information is worth retaining, which rules should disappear and which authority the team needs to recover. Migrating everything is often an expensive way of moving disorder to a new address.

The good news is that the hotel is not condemned to innovate at the pace of its oldest system. When we define capabilities, measure friction and distribute data and responsibilities correctly, a different way of leading emerges: less dependent on specific screens and far more aware of how value flows. Perhaps your PMS is currently the greatest brake on innovation. It can also become, if it learns to occupy its place, a reliable foundation from which the hotel can move again.