How can a hotel integrate PMS, guest room controls and maintenance systems?

At nine in the evening, a guest is moved to a new room. If the systems are not properly connected, the room they leave keeps heating an empty space all night while the one they walk into is still sitting in its unsold setback. Integration between the property management system (PMS), the guest room management system (GRMS) and the maintenance system exists to prevent exactly that kind of small, expensive irritation.

It works by agreeing a small set of events that pass between the systems, the identifiers that tie each event to the right room and asset, which system decides what, and what each system does when another is unavailable. Typically the PMS supplies booking and room status, the GRMS controls the room and reports faults and occupancy, and the maintenance system receives faults as tasks and reports when they are closed. Three things make the difference: an interface schedule written before procurement, guest data passed to building systems kept to the minimum each function needs, and every failure case tested alongside the normal flow before opening.

Three systems, three jobs

The PMS is the hotel's record of reservations, guests, folios and room status. The GRMS controls in-room heating, cooling, lighting and related devices, and knows whether the room appears to be occupied. The maintenance system, often a CMMS, records and tracks engineering work. Each is authoritative for different information, and integration problems usually begin where that is unclear.

The interface schedule

An interface schedule lists every message between the systems and states, for each, the trigger, direction, content, timing and what happens if it fails. A typical starting set looks like this:

Keep the list short at first, because every additional message is another thing to test, monitor and support.

Who decides what

Clear decision rights prevent the systems' logic from colliding. The PMS decides whether a room is sold, but not whether anyone is in it. The GRMS decides the room's conditioning mode within limits set by the operator, combining booking status, occupancy detection and door events. The maintenance system decides how faults are prioritised and when a task is closed. And only the front office can take a room out of order for sale, acting on engineering's advice when the reason is technical.

The conditioning limits for each mode should be written down, along with how quickly a room must recover to comfort when a guest returns and who may change those settings. Settings that anyone can change rarely stay where they were set.

Standards, where they fit

Hotels have an industry body for this. HTNG (Hospitality Technology Next Generation) is the hotel technology association whose members develop open specifications for connecting hotel systems; it has been part of the American Hotel & Lodging Association (AHLA) since 2021, which now publishes its specifications, and they cover many PMS integrations. The HTNG Express PMS Integration Specification is aimed at integrations that need only a limited set of reservation, guest and room information, and explicitly does not cover full-data integrations such as those between a central reservation system and a PMS. It lists related HTNG specifications, including Guest Room Status Messaging. Both the PMS and GRMS suppliers should be asked which specifications and versions their current releases support; a general claim of "HTNG compatibility" is not specific enough to contract on.

The link between the GRMS and the maintenance system is less standardised, so it should be specified by event and data content, with the supplier required to document it.

Most defects are identifier problems

The PMS, GRMS and maintenance system must use the same room numbers, and the maintenance system must recognise the device or asset that raised a fault. A naming convention agreed before installation needs to cover the awkward cases too: connecting rooms, suites with several zones, and back-of-house areas that appear in only one system. Identifier checks belong in commissioning.

Guest data: pass the minimum

Building systems rarely need to know who a guest is. Room conditioning needs to know whether a room is sold and its arrival and departure status; names, contact details and loyalty status are of no use to it. Where personalisation features such as a preferred temperature are proposed, the purpose, legal basis and retention should be agreed with the hotel's data protection lead before design. Under the GDPR, the principles of purpose limitation and data minimisation in Article 5 apply, and Article 25 makes data protection by design and by default an obligation on the controller. The interface schedule should record which personal data each message contains.

When a system goes down

Every system will be unavailable at some point, whether during a PMS upgrade, a network fault or a supplier outage. For each interface, the design should say what the receiving system does, how staff are told and how the systems resynchronise afterwards. A room should stay comfortable and safe with every interface down. Resynchronisation is the step most easily forgotten: after a PMS outage, check-ins and check-outs handled manually must still reach the GRMS, or rooms will sit in the wrong mode.

After opening

Each interface needs an owner who checks that messages are flowing, receives suppliers' notices about version changes and approves changes. Because PMS and GRMS upgrades can break integrations, integration regression tests belong in the change process.