A guest's do-not-disturb press, a dirty-room status change, or a maintenance flag does not travel straight from the keypad to a housekeeper's phone. It travels through the property management system first, which records the event, and then through a separate staff-notification layer — a GRMS dashboard, a mobile app, or a department task list — that decides who actually sees it. Understanding that this is two layers, not one, matters when scoping a new build or a renovation, because the PMS platform in use (Opera Cloud or Mews) shapes how that handoff is built.
This distinction is easy to miss because the guest-facing side of the room — a Crestron keypad or a packaged Lutron myRoom system — gets most of the design attention. But the back-of-house side, where PMS-triggered events land on a staff device, is its own architecture question, with its own platform differences to resolve before cabling and software licensing are locked in.
How does a PMS event actually reach hotel staff?
The two PMS platforms a property is likely to run expose staff-facing events differently, which affects how a staff device integration should be built. In Oracle's OPERA Cloud, alerts are tied to a reservation and its lifecycle: staff configure a Code, an Area (Reservation, Inhouse, Check-In, or Check-Out), and a description, and the alert then displays automatically when a staff member opens that reservation's detail screen from Arrivals, In-House, or Departures — a pull model where the alert surfaces inside the PMS interface itself rather than pushing to an external device. Some alerts are also "Global," meaning they are rule-driven rather than attached to one reservation, as described in PWA - Managing Alerts.
Mews takes a push model instead. Its Connector API documentation describes housekeeping integrations that subscribe to resource-state changes using Webhooks (the ServiceOrderUpdated event) or WebSockets (the Reservation event), rather than polling for updates. Staff tasks can be created directly through an Add task call and assigned to a specific department using department identifiers retrieved via Get all departments, and a list of outstanding tasks is available through Get all tasks, per Housekeeping | Connector API. That webhook/task-assignment structure is what lets a third-party staff app or GRMS integration receive a live push the moment a room's state changes, rather than requiring staff to check the PMS screen directly.
Where does the guest-room control platform fit into this?
The guest-room system is a separate layer again, and it is where the in-room devices that generate these events actually live. On Crestron, guest-facing do-not-disturb and make-up-room requests are generated by in-room devices — keypads, touch screens, or third-party hardware like Axxess's GRM, HCM, and CCMD modules — that run on Crestron's infiNET EX wireless communication software. According to Crestron and Axxess: A Great Guest Experience, the stated goal of that pairing is that "one GRMS and PMS solution is all that's needed to manage the entire room," with hotel staff able to monitor room status "directly from the PMS." In other words, the GRMS (guest room management system) is positioned as the aggregation point that already talks to the PMS — the staff-notification layer should be built to read off that GRMS/PMS connection rather than duplicating it with a separate parallel integration.
Crestron's broader hospitality material frames the same idea at a system level: a separate Crestron hotel blog post describes a "single pane of glass" where devices across the property "can then be managed and monitored," with the system able to "alert management to any problems that might come up." That single-dashboard framing is useful conceptually, but a GM scoping a project should still confirm, concretely, which events route where: an occupancy sensor reporting vacancy is not the same signal as a guest pressing a DND button, and not every event needs to reach every staff role.
Cave Group designs custom guest-room automation on Crestron and also builds packaged guest-room systems on Lutron myRoom where that fits the property better, with PMS integration handled as part of that scope — see the hospitality page for how guest-room, networking, and PMS work is structured as one delivery. For properties specifically weighing Opera Cloud against Mews as their underlying platform, the related PMS integration article covers how each connects to locks and lighting.
What should a GM confirm before staff devices are chosen?
A few practical questions are worth raising with whichever integrator and PMS vendor are involved, because the answers change what hardware and licensing get specified:
- Does the chosen PMS platform push events (webhooks, as Mews does for housekeeping) or does it require staff to pull them from within the PMS screen itself (as OPERA Cloud's reservation-level alerts do)? That determines whether a mobile staff app can receive a true push notification or needs a polling bridge.
- Which department should receive which event — housekeeping, engineering, front desk — and is that routing configured through department-level task assignment (the Mews model) or through area/code rules tied to reservation status (the OPERA model)?
- Does the GRMS vendor's existing PMS connection already carry the event types staff need, or does a separate integration have to be built and maintained alongside it?
These are design questions to put directly to the contractor and PMS vendor during scoping, since the answer differs by platform and by property.
Frequently asked questions
Does OPERA Cloud push alerts to a staff phone automatically?
Not directly. OPERA Cloud's alerts are displayed when a staff member opens a reservation's detail screen from Arrivals, In-House, or Departures — a pull model inside the PMS interface, rather than a push to an external device, per Oracle's documentation.
How does Mews notify staff of a housekeeping change?
Mews supports subscribing to resource-state changes using Webhooks (the ServiceOrderUpdated event) or WebSockets (the Reservation event), and tasks can be created and assigned to a specific department through its API, which is the mechanism a staff app would use to receive a live push.
Do Crestron guest-room devices talk to the PMS directly?
Crestron's guest-room hardware, including third-party devices like Axxess's GRM and HCM modules, runs on infiNET EX and is designed so a single GRMS and PMS connection manages the whole room, with staff able to monitor room status from the PMS rather than a separate system.
Is the staff notification layer the same system as the guest-room control platform?
No. The guest-room platform (Crestron or Lutron myRoom) generates events at the room; the PMS records and exposes them; a separate staff-facing layer (app, GRMS dashboard, or task list) is what actually alerts a staff member, and how that layer is built depends on whether the PMS pushes or requires a pull.
Who should a hotel ask to confirm this routing before opening?
The hotel's technology integrator and PMS vendor should be asked jointly to document which events route to which staff role and device, since that routing is configured differently on OPERA Cloud than on Mews.