Definition
PMS (Property Management System) is used for business processes such as room management, reservation, check-in/check-out, and door lock authorization. Smart locks can interface with the PMS to enable automatic code generation at check-in and automatic deactivation at check-out, suitable for hotels, apartments, homestays, and other scenarios.
Core Functions
PMS covers reservation management, check-in/check-out, room status management, billing and settlement, membership management, report analysis, and more. When interfacing with smart locks, PMS issues room keys (temporary passwords, BLE Bluetooth keys, etc.) to the lock platform during check-in, which automatically deactivate upon check-out. It supports integration with OTA platforms and channels for reservation data synchronization. Apartment and homestay scenarios can combine self-check-in and unattended operations to improve operational efficiency.
Lock Integration
Smart locks mostly use BLE Bluetooth or WiFi to communicate with a mobile app and interface with the PMS through the cloud. PMS sends check-in information (room number, guest, validity period) to the lock platform via API; the platform generates the key and pushes it to the guest's phone or writes it to the lock. At check-out, PMS notifies the platform to deactivate the key. Some locks support NFC, keypad, and other methods. Protocol compatibility, latency, and offline scenario handling should be considered during integration.
Authorization Driven by Room Status
A check-in event creates a credential with a lifetime
In a property or hotel management system, a room is first a status that changes, not a lock that is valid forever. After a reservation is confirmed, the room can still be changed, extended, or cancelled. Only when a check-in event actually occurs should the system create a door credential and write the start time, the end time, and the room number it may open. The credential may be a short-lived code, a Bluetooth key on a phone, or an authorization written onto a card. All of them are only a projection of room status. Once the projection has been issued, if the source status changes again, the projection has to be extended, revoked, or moved to another room number. Otherwise the lock still treats the old credential as valid.
The interface should pass events and a validity period, not a permanent key. Check-in, stay extension, room change, check-out, and loss report each map to a different action. Issuing only at check-in and doing nothing at check-out leaves the code able to open the door after the guest has left early. Completing the folio and expiring the lock authorization are best bound to the same check-out event, so the front desk does not finish the bill while the lock waits for a nightly batch.
The lock has to accept revocation from the cloud
The condition for use is a path that can reach the lock to carry revocation and extension. The path may be a gateway in the room, the lock's own network, or a sync while the guest's phone is online. A fully offline lock learns that a credential is void only the next time someone comes near. That gap has to be written into the house rules: a high-risk room cannot rely on an offline code alone. Time zones have to be unified. If a property on daylight saving time, or one that spans time zones, passes "12:00 today" as a local string, the expiry can be off by a full day.
Room-number mapping is the other premise. The room number in the management system, the lock identifier on the lock platform, and the number on the door may be three different numbering schemes. Miss one cross-reference and the code for 101 is sent to 110. If a lock identifier is reused after a replacement, the old credential opens the new lock. Change the cross-reference when the lock is replaced, and keep a record that the old identifier was voided.
The offline window and a shifted time zone
An easy mistake is to treat order status as room status. A channel order is cancelled, the room-status service never hears it, and the lock still becomes valid at the original check-in time. The next guest finds the lock already taken. Use the room status confirmed inside the property as the source of truth. A channel message is only a trigger, not the final authorization. Another class of error is the clock. Lock, server, and phone each keep their own time. The code still looks unexpired while the lock has already refused it. The desk can only reissue, and the authorization log stacks credentials that overwrite one another.
The scope of permission is often set too wide. If housekeeping, maintenance, and visitors share the guest's credential, staff cannot get in after check-out, or the guest credential is written as a long-term card. Separate credential type and validity period. Finally, handle duplicate events. If the same check-in is pushed twice by the channel, and each push creates a new code without voiding the old one, the room has several valid keys at once. Idempotent handling should update the same authorization by order number, not append another one.
Night audit and stays that cross midnight also cut the validity period in the wrong place. If the system expires codes in batch at midnight of the calendar day, a guest who checked in across midnight is locked out at midnight while the folio still shows them in house. Anchor validity to the actual check-in and departure times. Let the batch job reconcile accounts. Do not let it replace the individual authorization. On a room change, make the new room valid first and void the old room second. Reverse that order and there is a gap when neither door will open.