Ask any hotel general manager what their most critical system is and the answer comes back without hesitation: the property management system. The PMS is the spine. It holds the reservations, the rate plans, the guest profiles, the folios, the housekeeping status. If it goes down, the front desk goes quiet and the bar stops posting charges. Everyone knows this, which is why most hotels treat the PMS itself with the seriousness it deserves.

What surprises owners and IT managers, when we walk them through a year of incident logs, is how rarely the PMS itself is the problem. The big platforms, whether that’s Oracle Opera Cloud, Mews, Cloudbeds, Protel, Guestline, RoomRaccoon or Little Hotelier, are mature products with serious engineering behind them. They very seldom fall over outright.

What does fall over, constantly, is everything wrapped around them. The integrations. The connectors. The interface that posts a bar tab to a room. The handshake between the booking engine and the channel manager. The certificate that lets the door lock controller talk to the PMS. These are where the daily pain lives, and they are almost never owned by anyone in particular until something breaks.

This post is about that integration layer. What it actually contains, why it’s so fragile, and the decisions hotel operators can take to stop it eroding the guest experience.

What actually plugs into a PMS

If you sat down and drew the integration map for a typical 80-room independent hotel with an F&B operation, you would be surprised how busy the picture gets. A modern PMS doesn’t sit alone. It sits at the centre of a constellation of other systems, each one talking to it through some kind of interface.

The usual suspects are:

  • EPOS for food and beverage, posting bar and restaurant charges to the room folio so a guest can sign for a glass of wine and find it on their bill at checkout.
  • Payment terminals, increasingly tokenised, so the front desk can pre-authorise a card on arrival without the staff ever touching the PAN.
  • Electronic door locks, where the PMS sends an encoding command that turns a key card into a working room key for the right door at the right time.
  • Telephony or PBX, posting call charges to rooms and updating room status when housekeeping dials a code from the in-room phone.
  • Guest WiFi and the captive portal, often pulling guest names and stay dates from the PMS so the splash page can greet a guest by name.
  • TV and IPTV, doing much the same trick to personalise the welcome screen and, in some properties, to handle in-room ordering.
  • Booking engines and channel managers, pushing live availability out to OTAs and pulling reservations back in.
  • Accounting, with a nightly export of revenue and tax data into Sage, Xero or whatever the finance team uses.
  • Housekeeping apps that let cleaners update room status from a phone instead of a wall-mounted dial pad.
  • Kiosks and online check-in flows, which write directly into the PMS reservation record.

That’s ten interfaces before you’ve even thought about loyalty programmes, revenue management, business intelligence or spa booking. Each one is a separate piece of plumbing, and each one can break independently.

The three architectures, and why it matters which you have

Broadly, there are three ways these systems get connected.

The first is direct integrations. The EPOS vendor builds a connector to the PMS vendor, the door lock manufacturer does the same, and so on. Each vendor pair has its own bespoke handshake. This is the oldest pattern and still the most common in independent hotels. It works, but it scales badly, because every new system means another point-to-point connection to install, monitor and pay for.

The second is a middleware layer. Here, a single integration platform sits in the middle and translates between the PMS and everything else. The PMS only has to talk to the middleware. New systems plug into the middleware rather than into the PMS directly. This is cleaner, but it adds a vendor in the critical path and a monthly cost.

The third is standards-based messaging, usually built on HTNG (Hotel Technology Next Generation) or OpenTravel specifications. Here, the PMS exposes a documented set of message types and any compliant system can speak them. Oracle, Mews and several others publish open APIs that follow these conventions in spirit if not always to the letter. This is where the industry is heading, but it’s not yet the universal reality.

The reason this matters is that the architecture you’ve inherited dictates what your daily incidents look like. Direct integrations fail one at a time, often silently. Middleware solutions fail in clusters, but they’re easier to monitor. Standards-based setups are the most resilient but require vendors who actually honour the standards, which is uneven.

There’s no single right answer. There is, however, a wrong answer, which is not knowing which of the three you’re running.

Where integrations actually fail

After enough years doing this, the failure modes become very predictable. They are not exotic.

Stale interfaces. A vendor pushes an update to one end of the connection and the other end is still expecting the old format. Charges stop posting, or post to the wrong folio, and nobody notices until the night auditor flags the discrepancy at 3am.

Data format mismatches. A new field is added, a date format changes from DD/MM to ISO, a room number gets reformatted with a leading zero, and the receiving system silently drops the record.

Network changes. Someone reconfigures the firewall, or the ISP changes the public IP on the line, and an interface that relied on a whitelisted address goes dark. Often this happens during a perfectly innocent piece of network housekeeping, which is one of many reasons your managed network and your PMS integrations need to be looked after by people who talk to each other.

Certificate expiry. Almost every modern integration is encrypted, which means certificates. Certificates expire. When nobody is tracking them, an interface that worked perfectly on a Tuesday afternoon stops working on a Wednesday morning, and the front office team spends two hours convinced the PMS is broken.

Vendor updates breaking connectors. A new version of the EPOS goes live overnight and the posting interface no longer authenticates. The EPOS vendor blames the PMS. The PMS vendor blames the EPOS. The hotel sits in the middle, losing revenue.

Nobody owning the integration layer. This is the meta-failure that causes all the others. The PMS vendor owns the PMS. The EPOS vendor owns the EPOS. The locks vendor owns the locks. But the connector between them belongs to nobody, until somebody decides to make it their job.

This is an IT decision, not a procurement decision

When hotels select a new PMS, the conversation tends to be commercial. Per-room pricing. Contract length. Modules included. What gets less attention, until the project is well underway, is the integration map. Which of your existing systems will still talk to the new PMS? Which won’t? Which need a paid-for connector from a third party? Which will require you to replace a perfectly serviceable piece of kit because the new PMS doesn’t support it?

The cheapest PMS on a per-room basis can easily turn into the most expensive overall if it forces you to rip and replace your EPOS, your locks and your booking engine. Conversely, a slightly more expensive platform with a richer integration ecosystem can save you a fortune over a five year contract.

This is why we push hotel clients to treat PMS selection as an IT and operations decision with finance input, rather than a procurement decision with IT input. The order matters.

What an MSP is actually for

If the integration layer belongs to nobody by default, the job of a good managed service provider is to take ownership of it on the hotel’s behalf. In practical terms, that means a few specific things.

Someone needs to maintain an integration map: a living document of every interface in the building, what it does, what protocol it uses, what credentials it needs, when its certificates expire, and who to call at each vendor when it breaks. Most hotels we walk into have never seen one of these. Building it is usually the single most useful thing we do in the first month of an engagement.

Someone needs to monitor the interfaces, not just the servers. Knowing that the PMS server is up tells you nothing about whether the EPOS is actually posting charges. Real monitoring watches the message flow itself and alerts on silence as well as on errors.

Someone needs to coordinate the vendors when something breaks across the boundary between two of them. Without that coordinator, hotels end up as the unwilling middleman in a vendor argument, usually in the middle of service.

And someone needs to be available out of hours, because hotels don’t close. A PMS interface that fails at 11pm on a Saturday is a problem that needs solving at 11pm on a Saturday, not at 9am on Monday.

There’s a security dimension to all this as well. Every integration is a potential attack surface, and PMS interfaces in particular often carry guest personal data and payment tokens. Treating the integration layer as part of your cyber security posture, rather than as plumbing, is overdue in much of the sector.

Practical recommendations

If you’re choosing a new PMS, ask the vendor for a written list of certified integrations with the specific products you already run. Not “we integrate with EPOS systems” but “we have a certified, in-production integration with version X of product Y”. Get it in writing.

If you’re reviewing your existing stack, start by drawing the integration map. You can’t manage what you can’t see. Then check the boring things: certificate expiry dates, credentials nearing rotation, interfaces that haven’t been touched in years and are running on assumptions nobody remembers.

If you’re picking an MSP, ask them how they handle hotel integrations specifically. Generic IT support is not the same as understanding why a Mews-to-Tevalis interface is throwing 401s on a Friday night.

How CloudMatters approaches it

Our hospitality IT support practice is built around exactly this gap. We start every hotel engagement by mapping the integration layer in detail, putting monitoring on every interface that matters, and establishing direct vendor relationships so we can pick up the phone to the right person without the hotel having to mediate. We run 24/7 cover because hotels do, and we treat the integration layer as a first-class system rather than as an afterthought.

The PMS may be the spine of your operation, but the muscles that move it are the integrations around it. Look after them properly and the guest experience takes care of itself. Ignore them and no amount of investment in the PMS itself will save you.

If you’d like a candid review of your current PMS integration stack, we’re happy to come and walk the building. Get in touch through our hospitality IT support page and we’ll arrange a visit.