Name the components on both sides of the connection
Record the PMS product and release, the lock-management software, interface or connector, issuing equipment and proposed credentials. Assign an owner to each part. “Works with the PMS” can describe several different workflows, so ask which events and actions actually pass between the systems.
Cloudbeds’ official access-management guidance states that available functions and setup requirements differ by integration. Its comparison distinguishes connections that update occupancy status from encoder-style workflows that require manual status changes. Do not apply either behavior to another PMS or connector without checking its own documentation.
Use a written acceptance matrix
Adapt the checklist to your property and have the supplier record the actual result.
| Scenario | Question to demonstrate | Evidence to keep |
|---|---|---|
| Check-in | What action creates the credential, and which room and stay window does it receive? | Configuration and observed result. |
| Room move | How are new permissions issued, and what happens to the previous credential? | Both old-room and new-room tests. |
| Late checkout | Does an extension update access automatically or require reissuing? | The exact steps and observed expiry. |
| Lost card or phone | How is replacement handled and when does the old credential stop working? | Procedure and access test. |
| PMS or network outage | Which functions continue and how do staff recover? | Recovery procedure tested on the proposed system. |
| Staff access | Who grants, changes and removes permissions? | Permission schedule and audit-log example. |
Separate a mobile key from the PMS connection
A mobile credential is an access method; PMS integration is a connection between systems. One does not prove the other. Ask whether guests need an application, how a credential is delivered and which device, account or network requirements apply. Test the actual supported phones and guest journey instead of assuming every Bluetooth-enabled lock behaves the same way.
Agree who supports the connection after launch
- Name the parties responsible for the PMS, connector and access hardware.
- List any interface, licence, subscription and support charges separately.
- Agree who diagnoses an issue that crosses system boundaries.
- Record the tested releases and how future upgrades are checked.
- Give reception staff a usable fallback procedure and support contact route.
Keep the acceptance record with the quotation and handover documents. A demonstration on different hardware or a different connector is not the same configuration as the one being ordered.
Two questions that prevent vague promises
Is an API or SDK enough?
No. Ask what has actually been implemented, who maintains it and which end-to-end workflows have been demonstrated.
Can a demonstration replace written scope?
No. Keep both: a written list of included functions and the observed results on the proposed system.
Sources and further reading
Public sources checked 20 October 2026.