Solution · 06
Room revenue, held on to.
A solution page sales can quote to a hotel as it stands.
The situation
Room-fee leakage is the quietest loss a hotel has.
A lent card, a front-desk override, a favour room — none of them large, but added up over a year they are an account nobody can ever explain.
-
Lent card · front-desk override · favour room
None of them large, but added up over a year they are an account nobody can ever explain. A lent card detaches the card from the guest; a front-desk override detaches permissions from the room state; a favour room detaches the record from the responsibility. Our answer is not more people watching — it is making all three leave an auditable trace in the system.
The norm
A traditional lock only opens; it does not record who opened it. When a dispute comes up there is nothing to check, so the blame lands on whoever is lowest in the chain.
Pain points
Cards move untracked
A card is lent or passed on and nobody knows.
Revoking is slow
Permissions outlive the checkout.
Nothing to audit
When a dispute comes up there is no record to check.
Our solution
Card bound to guest, entry on record.
Credentials are bound to the room state and the guest, every entry is traceable, and they expire at checkout with permissions following the room state automatically. Room revenue held 100%.
-
Credential bound to room state, entries logged, expiry at checkout
The credential is bound to the room state and the guest: who opened which room, when, with which card or phone is recorded and traceable. It expires at checkout and permissions follow the room state automatically, with no manual cancellation. Permissions are not a one-off grant either — they can be issued and recalled in the LMC by floor, time and person.
Advantages and differences
| Item | The usual way | LOCK.LINK |
|---|---|---|
| Credential binding | The card knows no one | Card bound to guest |
| Entry records | None | Every entry logged and traceable |
| Expiry at checkout | Manual, and easily missed | Driven by room state, automatic |
| Settling disputes | One word against another | Data to check against |
Specs and FAQs
The room-fee leakage prevention solution addresses the leaks hotels suffer — staying without paying, a different person moving in, one registration for several people — by combiningcard-to-guest binding, entry logging and unlock-logic verification so the card is strongly tied to the guest on file and revenue is protected from issue to checkout.
- Revenue held
- 100%
- Plugged at the source
- Core mechanism
- Card bound to guest
- The card is the guest
- Entry logging
- Every entry traceable
- Records auditable
- Unlock checks
- Multiple layers
- Against copying and sharing
- Staff separated
- Staff cards kept apart
- Internal work is not flagged
- PMS link
- Synced automatically
- Check-in / move / checkout
Traditional card system vs LOCK.LINK prevention
| Item | Traditional card system | LOCK.LINK prevention |
|---|---|---|
| Someone else moves in | Hand over a card and it works — a wide hole | Bound to the guest: the card follows the person |
| Card shared | One card, several people taking turns | Blocked by unlock-logic checks |
| One registration, extra occupants | Hard to spot | Entries logged and traceable |
| Collecting the fee | Chasing it afterwards | Held at the source, 100% |
| Staff handling | Mixed in with guest cards | Separate permissions, no false alarms |
Configuration steps
- Step 1 · Turn on card binding: Bind the card to the guest on file in the platform, so it follows the person and expires at checkout.
- Step 2 · Configure unlock checks: Set the unlock verification rules — command-ID replay protection, short-address location matching, validity-window checks.
- Step 3 · Authorise staff cards separately: Keep staff cards logically separate from guest cards so internal work does not trip the risk controls.
- Step 4 · Verify logging and alerts: Turn on anomalous-unlock logging and alerts, visible to the front desk in real time so revenue risk surfaces early.
Common questions
What exactly is room-fee "leakage"?
It means cases where the hotel never collects the fee — someone else moves in, a card is shared, or the bill is skipped. The solution binds identity at the point the card is issued, closing it at the source.
Will it inconvenience normal guests?
No. A normal guest taps a card or a phone exactly as before — binding and logging are back-end logic that leave the opening experience untouched.
Does it affect staff cleaning cards?
No. Staff cards are authorised and logged separately, with logic kept apart from guest cards, so they do not interfere with each other.
Does the front desk have to change how it works?
Only one thing changes: the PMS link is connected at issue/check-in so the card can be bound to the guest. Everything else is invisible to the front desk.