Smart access is not a code. It is a lifecycle.
A guest needs access for a specific reservation. A cleaner may need access immediately after checkout. Maintenance may need a temporary window during the stay. An extension changes the original departure date. A cancellation should remove access that is no longer required.
And sometimes, the lock simply does not sync.
That makes smart access less of a hardware feature and more of a reservation lifecycle problem.
Access should follow the reservation
The reservation should be the source of truth.
When a booking is confirmed, the system can create a unique credential associated with that stay. Its validity should follow the actual check-in and checkout window rather than requiring someone to manually manage the lock.
If the reservation changes, access should change with it.
If the guest extends by three days, their credential should remain valid for those three days. If they leave earlier, access should expire earlier. If the reservation is cancelled, the credential should be revoked.
This is already how mature smart-lock integrations are beginning to operate: reservation-specific codes can activate at check-in, expire at checkout and update when reservation timing changes.
Guest access and operational access are different things
The cleaner does not need the guest's credential.
Neither does maintenance.
Operational access should have its own identity and its own lifecycle.
A cleaning task scheduled between two stays might generate a credential that works only around that task window. Maintenance access could exist for a different period. Once the task is complete, that credential should expire.
Separating these credentials creates a much clearer access history and reduces the need for permanent staff codes circulating between properties.
Failure is part of the workflow
The interesting part of automation isn't what happens when everything works.
It's what happens when it doesn't.
A lock can be offline. A PIN can fail to provision. Connectivity can disappear. A same-day reservation can arrive before a device finishes synchronizing.
An access system therefore needs more than a code_created state.
It needs to understand states such as:
scheduled → provisioning → active → failed → fallback → expired
And every failure needs an operational response.
Can the system retry the credential?
Is there a backup method?
Does someone need to intervene?
Has the guest received working instructions?
Without those answers, "automated check-in" can still end with someone standing outside an apartment waiting for support.
Access becomes part of the operating system
Once access is connected to reservations, tasks and communication, the smart lock stops being an isolated device integration.
It becomes part of the property's operational state.
The PMS knows:
- who should currently have access;
- why they have it;
- when that permission began;
- when it should end;
- whether the credential reached the device;
- and what should happen if it didn't.
That's the larger opportunity for property-management software.
Don't automate the PIN. Automate the lifecycle around it.