Hotel systems integration: how to connect the PMS, POS and channel manager without blind spots
An out-of-date rate on an OTA, a restaurant bill that never reaches the room account, a booking that arrives twice: many of these problems do not come from a single system failing, but from a poorly built or poorly maintained integration between systems. Here is the map of integrations that supports a hotel's operation, and where security tends to be left out of the sales conversation.
The map of systems that need to connect
The PMS (property management system) is the centre of the operation, but it rarely works alone. Around it sit the booking engine on the hotel's own website, the channel manager that distributes availability and rates to OTAs (online travel agencies) such as Booking.com and Expedia, the restaurant and bar POS (point of sale), the payment gateway that processes cards and Pix (Brazil's instant payment system) and, increasingly, a CRM for guest relationships and an RMS (revenue management system) for dynamic pricing. Each of these connections is an integration that has to keep working after the salesperson has left the room.
When one of these integrations fails, or never properly existed, the symptom shows up in the operation, not on the system screen: rates that do not match between the website and the OTA, bar bills keyed into the room account by hand, duplicate bookings because the channel manager and the PMS do not talk to each other in real time.
Two-way integration: the standard that reduces the risk of overbooking
The ideal integration between the PMS and the channel manager is two-way: the PMS sends availability and rates to the channel manager, which distributes them to the OTAs, and any booking made on an OTA comes back to the PMS automatically, without the front desk re-keying it. This closes the loop and reduces the risk of one of the most expensive mistakes for a hotel: selling the same room twice because the availability update was slow or depended on someone entering it by hand.
One-way integrations, which still exist in older contracts, require the team to enter each OTA booking into the PMS manually. This works for small operations, but it scales badly and can contribute directly to overbooking in hotels that have grown without reviewing the integration.
POS, payment gateway and the guest's single account
The integration between the food and beverage POS and the PMS is what allows restaurant or bar spending to be posted straight to the room account, without the guest having to pay in two different places. Without it, the hotel increases the risk of charges that are never posted and creates friction for the guest at checkout.
To reduce manual reconciliation, the payment flow should be integrated with the PMS and, where applicable, with the booking engine, so that direct bookings can be charged, including by Pix. Gateways that are not integrated create manual reconciliation, delays in closing the books and, in some cases, depend on a receipt sent over WhatsApp to confirm a payment, a practice we cover in the guide to integrating Pix into direct booking.
CRM and RMS: beyond the booking
A CRM integrated with the PMS brings the guest's stay history, preferences and communication together in one place, which supports direct booking campaigns and loyalty programmes without relying on parallel spreadsheets. A dynamic pricing RMS depends on two integrations: with the PMS, from which it reads bookings and occupancy, and with the channel manager or the PMS itself, to which it sends the rates it suggests or adjusts based on occupancy and forecast demand. Tools of this kind now also appear in mid-sized hotels.
The risk here is not technical but one of governance: when the CRM and the RMS sit outside the security scope the hotel applies to the PMS, they can become the weakest link through which guest data leaks, even if the main PMS is well protected.
Point-to-point integration or a central platform (iPaaS)?
In hotels with few systems, connecting each one directly to the others (point-to-point integration) is simple and cheap. The problem appears as the number of systems grows: five systems that are fully connected to each other already mean up to ten different connections to maintain, monitor and protect. A central integration layer (iPaaS, integration platform as a service) reduces that complexity, centralises the logs for every integration and makes it easier to replace a supplier without rebuilding each connection from scratch.
This central layer has its own cost and complexity, and it usually only pays off above a certain size of operation, or for a hotel group with several properties. For many independent hotels, the starting point is to map and document the integrations that already exist, something that is often not written down anywhere.
Security: the part the sales demo does not show
Each integration is, in practice, a way for data to enter and leave between two different systems, and supplier sales demos do not always go into this in depth. Start with three questions. Is the traffic between the systems encrypted in transit, for example with TLS, or does part of it travel in a manually exported, unprotected file? Does the integration use an authenticated API, or a generic access key shared between several hotels on the same supplier? And does the contract define each party's responsibilities for the data that flows through this integration, not just in the main system? Where applicable, this can be formalised in a data processing agreement (DPA).
An integration also needs monitoring. The hotel should know when a sync has failed, is running late or has started returning errors, instead of discovering the problem when the front desk or the finance team notices a discrepancy.
In many guest data flows, the hotel acts as the controller under the LGPD (Brazil's data protection law) and may be held responsible for these gaps even when the technical problem is on the supplier's side. That does not remove the responsibilities of suppliers that process data on the hotel's behalf, and each party's role should be assessed according to the processing carried out, with the hotel's legal advisers, as the ANPD guide on processing agents (in Portuguese) advises. We go into this in more depth in the LGPD guide for hotels.
Before signing up for a new integration
- Is the integration already certified and used in production by other hotels, or would it be developed to order?
- Is it two-way, or does one side require manual entry?
- Does the supplier document the API and offer webhooks so the hotel can monitor sync failures?
- Is the traffic between the systems encrypted in transit (HTTPS/TLS)?
- Does the contract define each party's responsibilities for the data in this specific integration?
- Is there an availability SLA for the integration, not just for the main system?
- Who answers for each integration when it fails: the PMS supplier, the supplier of the other system or the integrator? And what is the escalation path?
The last question avoids a familiar deadlock: the PMS supplier points to the POS, the POS supplier points to the PMS, the integrator points to the network, and nobody fixes the problem. A responsibility matrix agreed before signing, like the one we describe in who is responsible for what in hotel IT (in Portuguese), shortens that path.
Next steps
Many hotels do not have a complete map of which systems are integrated, how, and with what level of security. That map is usually the first step before any decision to change PMS, add a CRM or review supplier contracts. Our team carries out this survey and assesses each integration before any new investment. Talk to our team. To see how these integrations fit into the rest of the hotel's technology, see the complete guide to the hotel technology ecosystem.
Sources
- ANPD, Guia Orientativo para Definições dos Agentes de Tratamento de Dados Pessoais e do Encarregado (guidance on processing agents and the DPO, version 2.0, 2022, in Portuguese), gov.br/anpd
Hotel Systems
Mapping and governance of the integrations between the PMS, POS, channel manager and other critical systems.
View service- Complete integration map
- Validation of two-way integrations
- Review of data processing agreements
- Supplier selection and governance
Related reading
Which systems does a hotel usually need to integrate?
In general, the core is the PMS (property management system), integrated with the booking engine and the channel manager (which distributes availability and rates to the OTAs), the restaurant and bar POS, the payment gateway and, increasingly, a guest CRM and an RMS (revenue management system) for pricing. Each missing integration tends to become duplicated manual work and one more source of rate errors or overbooking.
Two-way or one-way: which channel manager integration should you choose?
Two-way integration is the recommended standard: the PMS updates availability and rates in the channel manager, and bookings made on the OTAs come back to the PMS automatically, without manual re-keying. One-way integrations, which require bookings to be entered into the PMS by hand, increase the risk of overbooking and still appear in legacy contracts that are worth reviewing.
Who is responsible for data security when several suppliers are integrated?
Responsibility is shared according to each party's role in the processing. In many guest data flows, the hotel acts as the controller under the LGPD and needs to make sure the contracts define each supplier's responsibilities, that traffic between systems is encrypted and that no integration is exposed to the internet without authentication. Suppliers that process data on the hotel's behalf keep their own obligations. A weak link in any integrated system can compromise the data that flows between all the others.
Is it worth using an integration platform (iPaaS) instead of point-to-point integrations?
It depends on how complex the integrations are. With few systems and simple APIs, point-to-point connections may be enough. As the number of systems, data flows, properties and suppliers grows, the number of direct connections rises quickly and becomes hard to audit. A central integration layer reduces those connections, centralises logs and makes it easier to replace a supplier without rebuilding every integration from scratch, but it has its own cost and complexity. Groups with several properties tend to benefit most.
What should you check before signing an integration contract with a new supplier?
Start with three points: whether the integration is already certified and used in production by other hotels (not a promise of future development), whether the supplier exposes a documented API and webhooks so the hotel can monitor failures, and whether there is an availability and response-time SLA for the integration, not just for the main system. It is also worth defining who answers for the integration when it fails. Integrations promised in a sales meeting, without documented technical requirements and responsibilities, are a recurring risk in projects that stall during implementation.
Map your hotel's system integrations
Talk to our team before changing PMS or adding a new system to the operation.