A guest-room mockup is a single fully built room — lighting, shades, HVAC, lock, TV, and PMS connection all live — used to test and approve the guest experience before it is ordered and installed in every room on the property. It exists because a drawing cannot show how a keypad feels at 2 a.m. or whether a welcome scene actually triggers when the door opens. Once the owner's representative, brand standards team, and operator sign off on that one room, its configuration becomes the template that is deployed, floor by floor, to the rest of the hotel.
What systems actually get tested in a mockup room?
A mockup is built to be touched and lived in, not just inspected. Crestron's own hospitality documentation describes the sequence a guest room is meant to execute: sensors trigger an automated welcome scene as the guest enters, with shades opening, lighting setting a warm level, a curated audio playlist starting, and the TV displaying a welcome message, while presence detection confirms occupancy back to the Guest Room Management System (Hospitality Guest Rooms). The same documentation describes the departure side of that same room: when the lock registers an exit, lights turn off, shades and drapes close, HVAC steps to an energy-saving mode, audio mutes, and the TV shuts off, with occupancy again reported to the GRMS. A mockup should run both halves of that cycle — arrival and departure — before anyone signs off on it, because a scene that looks right in a walkthrough demo can still fail the sensor logic behind it.
The in-room keypad is also part of what gets tested, not just specified. The same Crestron material notes that an engraved keypad is meant to carry Do Not Disturb and Make Up Room buttons that also display outside the door, and that a single button press should recall the guest's full preference set for lights, shades, HVAC, and audio together. A mockup walkthrough is the point to confirm those buttons actually fire the right scene and that the corridor sign updates correctly, rather than discovering a mismatch after two hundred rooms are wired the same way.
Beyond the room-automation layer, a mockup should also prove the PMS and access connections that make the room operational rather than just decorative. A PMS integration is only useful if the hotel has confirmed what data moves, which direction it flows, and how quickly updates land — questions worth testing against the actual mockup room rather than assuming from a vendor's integration listing. On the access side, hotel locking systems like Salto's Space platform separate admin-level configuration (creating rooms, associating zones and outputs, setting up guest access levels) from day-to-day front-desk operation (check-in, key encoding, check-out), and a mockup is a reasonable place to confirm that split works the way the operator expects before it's repeated at scale (Introduction to the hotel interface in Space).
Who typically signs off on the mockup, and what changes after the walkthrough?
Sign-off on a mockup room generally involves three perspectives: the owner's representative confirming the room matches the design intent and budget, the brand standards team (for a flagged or branded property) confirming the room meets published brand requirements, and the operator's own technical and housekeeping leads confirming the room is something staff can actually run day to day. Each group is looking for something different — design fidelity, brand compliance, and operational practicality — and a mockup walkthrough is where those three views get reconciled before the rest of the floors are built.
Walkthroughs commonly surface practical friction that a drawing never would: a keypad button placed where it's hard to read in low light, a welcome scene that's too aggressive on first entry, a DND indicator that housekeeping finds easy to miss, or a PMS-driven setback that triggers HVAC changes faster or slower than staff expect. Because a hotel's guest-room scope spans control, lighting, lock, network, and PMS working as one coordinated system rather than separate vendors, a mockup is useful precisely because it forces those systems to be tested together in one physical room instead of being accepted on separate spec sheets. For properties weighing a custom Crestron build against a packaged system, that same room is often the first place the choice gets tested in practice — see our related piece on custom Crestron guest-room automation scope for how that scope typically divides.
How does an approved mockup become the template for every room?
Once a mockup is signed off, the goal is to turn its configuration into something repeatable rather than re-designing each room from scratch. On the lighting-and-scene control side, Crestron's own commissioning tools are built around exactly this workflow: a room template can be extracted from an existing room, uploaded into a template library, and then applied and deployed to a selected room or group of rooms from a single management view (Manage Commissioning | Crestron Zūm Lighting Control Manual). That same template-and-deploy model is why a mockup matters more than a pretty showroom: the mockup room's extracted template is quite literally what gets pushed to the rest of the floors, so an error signed off in the mockup propagates everywhere, and a fix made only after rollout has to be repeated room by room.
Deploying a template at scale still requires mapping it correctly to each physical room, confirming the devices and components in each room match what the template expects, and deploying selectively rather than all at once so issues on one floor don't become issues on every floor simultaneously. A hotel moving from a mockup into full deployment should expect to validate a sample of early rooms against the template before committing the rest of the property, rather than treating template deployment as a single irreversible event.
Cave Group designs and builds custom guest-room automation on Crestron, and also deploys packaged Lutron myRoom XC systems, PMS integration, networking, and access control for hospitality properties; more on that scope is on the hospitality page.
Frequently asked questions
What is a hotel guest-room mockup?
A guest-room mockup is one fully built and functioning guest room — control, lighting, shades, HVAC, lock, TV, and PMS connection all live — used to test and approve the guest experience before the same configuration is ordered and installed across every room in the hotel.
Who needs to sign off on a mockup room?
Sign-off typically involves the owner's representative (design and budget fidelity), the brand standards team on a flagged property (brand compliance), and the operator's technical and housekeeping leads (day-to-day operability). Each reviews the room from a different angle before the design is locked.
What does the mockup walkthrough actually test?
It tests the full arrival-to-departure cycle: whether entry triggers the correct welcome scene (lighting, shades, audio, TV), whether exit correctly triggers an energy-saving shutdown reported back to the Guest Room Management System, and whether keypad buttons like Do Not Disturb and Make Up Room fire correctly and display outside the door.
How does the approved mockup turn into every other room?
The mockup's configuration is extracted as a room template, which can then be applied and deployed to selected rooms from a commissioning tool rather than reprogrammed room by room. Hotels should still validate an early sample of deployed rooms against the template before rolling it out to the full property.
Should the PMS integration be tested in the mockup too?
Yes — the mockup is a practical place to confirm what guest and room-status data actually moves between the PMS and the room system, in which direction, and how quickly, rather than relying on a vendor's integration listing alone.