A hotel technology RFP works when it forces every bidder to price the same deliverables: a named PMS interface model, a named AV-over-IP standard, a documented network segmentation plan, and a locks/access architecture — not a vague "integrated systems" line item. Without those specifics, bids come back on different scopes and the owner ends up comparing a stripped-down number against a complete one without realizing it. The fix is to write the RFP as a document that names standards and asks for evidence, not just a wish list of room features.
This matters most before a single integrator is selected, because once the contract is signed the owner has far less leverage to add scope back in. The questions below are the ones an RFP should answer for each system before bids go out.
What belongs in the PMS integration section of an RFP?
The RFP should name which PMS the property runs or is considering, and ask each bidder to describe exactly how their guest-room, access, and energy-management systems will talk to it. For a property on Oracle's OPERA Cloud, that means asking whether the bidder works through the Oracle Hospitality Integration Platform's self-service developer tools — OAuth 2.0 application keys, sandbox testing, and the specific OPERA Cloud APIs the integration depends on, such as the Front Desk Operations Service API for arrivals and room assignments or the Housekeeping Service API for room status. See Hospitality Integration Platform - PMS and POS | Oracle for the current API catalog. The RFP should also ask bidders to confirm in writing that new integrations are not available to OPERA 5 on-premises or hosted deployments, or to Suite 8 — a property still running either of those earlier platforms needs a migration conversation with its PMS vendor before an integrator can promise a live interface, not after the contract is signed.
A thin bid answers "PMS integration" with a single line. A complete bid names the interface module, lists which business events it subscribes to (arrival, departure, room status), and states which party — the integrator or the PMS vendor — owns the credentials and the sandbox testing phase.
How should the RFP specify guest-room automation and access control?
Guest-room automation should be scoped by platform, not by feature list alone. Ask each bidder whether they propose a custom-built system or a packaged, cloud-managed one, and have them justify that recommendation against the property's room count and renovation timeline rather than accepting a generic "guest-room automation" line. You can read more about how hotel guest-room systems get evaluated on the hospitality page.
For access control, the RFP should require the bidder to describe how guest credentials move from reservation to door, including mobile key issuance and revocation and the staff-credential model, which is separate from guest access. Salto positions its hospitality access systems as more than a guest-room lock — a credential and experience layer meant to work with the property's design and operations, per Security access control for hotels | Salto. The RFP should ask each bidder to name which access platform they propose, how it interfaces with the PMS, and what happens to a guest's access if a phone fails at the door — an acceptance test, not an assumption.
What should the RFP require for networking and AV-over-IP?
The network section of the RFP should require VLAN segmentation for guest, staff, IoT, and AV traffic, and ask bidders to describe how PCI scope is isolated from other traffic on the same backbone. It should also require a stated Wi-Fi design density — per-room access point placement for guest floors versus higher-density coverage for ballrooms and lobbies — rather than a generic "enterprise Wi-Fi" line.
For ballroom and meeting-room AV, the RFP should ask whether the proposed system uses AV-over-IP distribution and, if so, which standard. Crestron's DM NVX platform moves video, audio, USB, and control over a standard network, and scales using existing 1G infrastructure as endpoints are added, according to DM NVX | Crestron Electronics, Inc.. An RFP that simply asks for "divisible ballroom AV" without naming a distribution standard makes it difficult to compare a bidder proposing AV-over-IP against one proposing a legacy point-to-point matrix, since the two differ in scalability and long-term flexibility. Ask your contractor directly which approach they propose and why, given your room count and divisible-wall layout.
How do you tell a complete bid from a thin one?
A complete bid names specific platforms, interface modules, and standards for every system in the RFP and states who is responsible for each integration point — the hotel's IT team, the PMS vendor, or the integrator. A thin bid uses broad category language ("networking," "PMS integration," "guest-room automation") without naming the APIs, interface module, or access platform behind each line. Before comparing prices, line up each bidder's answers to the PMS, access control, and AV-over-IP questions above side by side; gaps usually show up as missing specifics rather than missing line items.
The RFP should also require documentation and training deliverables explicitly: as-built drawings, credential and sandbox access handed over at closeout, and a defined commissioning and acceptance-test period before go-live. These belong in the RFP itself, not left for negotiation after a bidder is selected.
Frequently asked questions
What is the biggest mistake owners make writing a hotel technology RFP?
The most common mistake is writing scope in broad categories like "networking" or "PMS integration" instead of naming the specific platforms, APIs, and interface modules each bidder must address, which makes bids impossible to compare fairly.
Should the RFP name a specific PMS platform?
Yes. If the property already runs or has selected a PMS such as OPERA Cloud, the RFP should name it and ask bidders to describe their exact integration method, including which APIs or business events they depend on, since integration paths differ by PMS and by deployment type.
Does the RFP need to specify AV-over-IP by name?
It helps to ask directly whether a bidder's ballroom or meeting-room AV proposal uses an AV-over-IP standard such as Crestron's DM NVX, since AV-over-IP and legacy point-to-point video distribution scale differently as a property adds rooms or endpoints.
Who should own the PMS credentials and sandbox access during integration?
The RFP should state this explicitly rather than leaving it implied — some PMS platforms require the integrator to register applications and manage their own API keys through a vendor's developer platform, so the RFP should clarify who holds that access and the testing timeline.
Can one RFP cover guest-room automation, networking, and ballroom AV together?
Yes, and it should — these systems share infrastructure and dependencies such as the network backbone and PMS triggers, so scoping them together in one document helps the owner compare bidders on the full technology stack rather than system by system. Cave Group works with owners and operators across these same systems as part of its hospitality technology integration work.