Technology integration for hotels

This page is for you if you already have several systems in operation — PMS, channel manager, lock system, payment terminal, guest Wi-Fi — and feel that they do not talk to each other well enough, or if you are about to choose new systems and want to avoid getting stuck with a solution that is expensive to get out of.

How it works

1. Mapping — a review of all the systems in operation today: PMS, channel manager, lock system, payment terminal, Wi-Fi/guest portal, any booking engine and revenue management, and which of them already talk to each other and how.
2. Identifying integration needs — which connections are missing, which are broken or manual today (e.g. double entry in two systems), and what will actually make a difference if addressed first.
3. Supplier evaluation — the existing suppliers' APIs and integration options are reviewed, and any new suppliers are evaluated against the same criteria.
4. Contract review — requirements for data portability, division of responsibility and termination terms are secured before anything is signed (see "Common pitfalls").
5. Implementation and testing — the integrations are built or activated, and the entire flow is tested end to end before it goes live.
6. Go-live with monitoring — a period after launch during which the flow is watched especially closely, so that faults are caught before they cause double bookings or lost payments.

Which integrations, and where they tend to break

The PMS as the hub. The property management system is in practice the hub — the channel manager, lock system, payment terminal and guest portal are normally all connected to the PMS rather than directly to each other.

Channel manager. Synchronises availability and rates with booking channels such as Booking.com and Expedia. A common source of errors: a network outage or delay between the channel manager and the PMS that means an available night is sold twice before the systems have had time to sync — the root cause of double bookings.

Lock system. See the separate page on RFID implementation for the technical detail. From an integration perspective, the source of errors is usually that room numbers or check-in times are not transferred correctly from the PMS to card encoding.

Payment terminal. Must both meet the PCI DSS requirements for card payments and fit into the PMS check-out flow. A common source of errors: an update at the payment provider that changes how the transaction is reported back to the PMS, without this being communicated to the hotel in advance.

Wi-Fi and guest portal. Works best when the guest's login is linked automatically to the room number/booking via the PMS, rather than a separate password handed out manually by reception. A common source of errors: the link between the portal and the PMS breaks during a system update on either side, and nobody notices until guests start complaining.

How suppliers should be evaluated. Insist on seeing documented, preferably open, APIs — not just a promise that "integration is available". Ask for references from hotels of a similar size that actually run the specific integration you are looking for, not just the same system in general. Ask for the supplier's procedure for communicating API changes in advance.

What the contract should contain. The right to export your own data (booking history, guest register) in a usable format. A clear division of responsibility for who fixes an integration fault and within what time. Termination terms that do not penalise you unreasonably for replacing part of the system later.

How to avoid lock-in. Avoid tying the PMS, payments and channel management to a single supplier's all-in package without a clear exit plan. Test the export routine yourself before the contract is signed — do not just read that it exists in the contract text.

Common pitfalls

• Assuming that "supports integration" means tested and ready for your particular combination of systems — ask for a reference that runs exactly that connection.
• Not testing the entire flow end to end — from a booking via an OTA, to the PMS, to the channel manager, to payment — before launch.
• Nobody owning support responsibility when a fault occurs in the interface between two systems, and both suppliers point at each other.
• Having no manual fallback routine for what happens if the integration goes down during high occupancy.
• Choosing an all-in-one solution without having thought through what happens if you want to replace a single part later.
• Not requesting API documentation before the contract is signed, and relying instead on verbal promises from salespeople.

What it costs

The cost depends on how many systems are to be connected, whether these are ready-made standard connections or something needs to be custom-built, and how much of the technical work already exists at your current suppliers. We map your current system environment first and produce a realistic cost estimate based on that, rather than a standard price.

Frequently Asked Questions

Which systems really need to talk to each other?

Fundamentally, the PMS and the systems that directly affect booking, check-in and payment — the channel manager, lock system and payment terminal. Wi-Fi/guest portal is desirable but less critical if it fails temporarily.

Can we change channel manager without changing PMS?

In most cases, yes, as long as the PMS has an open interface to channel managers in general and not just to one specific supplier.

What happens if an integration breaks in the middle of high season?

That is exactly why the contract should contain a clear division of responsibility and response times before you sign — and why a manual fallback routine needs to exist, not just a hope that it never happens.

Do we need our own IT department to manage this?

No, but someone — internally or an external consultant — needs to have the overall picture of how the systems fit together, so that you are not left with several suppliers who each say that everything works on their side.

Are cloud-based systems more or less secure than local servers?

That depends more on the supplier's security work than on whether the solution is cloud-based or local. Ask about their security procedures and which certifications they hold, regardless of the hosting model.

How do we know that a supplier can really integrate, and is not just saying so?

Ask for a reference customer that runs exactly the combination you are looking for, and ask to see the API documentation before you sign.

Can you help us evaluate systems we already have, or only set up new ones?

Both — a review of the existing system environment is often exactly what reveals where the most expensive problems actually lie.