Door level grants tied to the membership, on whatever readers your building already has. Access issues itself when you sell, ends itself when somebody leaves, and every unlock is on the record.
Credentials get issued in a vendor app that knows nothing about who is paying you. People leave and keep their card. Somebody has access to a floor they moved off in March. The list is only ever cleaned up after an incident.
A member gets the main entrance, their floor and their cabin. A staff member gets the server room. Each grant is its own record against a specific door, so access is described exactly rather than approximately.No blanket credentials nobody can audit
Sell the membership and credentials issue themselves. Log a notice and access ends on the last day of the term. Nobody has to remember, and nobody keeps working access three months after they churned.Ex members stop walking in
Enrol whichever credential the site uses. The grant is the same object regardless, so changing a member from card to face does not mean rebuilding their access.Mixed hardware, one access model
Removing access blocks the credential rather than quietly dropping the record, so a revocation survives a device reboot, a resync or a controller replacement. The grant list is the truth and devices are reconciled against it.Revocations that cannot un-revoke themselves
Devices behind NAT with no public address still work: they report in and receive their commands, with confirmation from the device treated as the source of truth rather than an assumption. Nothing is considered applied until a device says so.Works without opening ports to the street
A searchable log of who opened which door, when, with which credential, and which grant allowed it. Answer a landlord, an insurer or an incident question from the console rather than from a device.One log across every door and centre
The front desk can open a door remotely, but the unlock is time limited, permission gated and logged like everything else.
Access windows follow what the member bought. Weekday plans, shift plans and 24/7 plans each open the door at the right hours.
Existing enrolments on a device can be matched to a member rather than re-enrolled, so a live site can move over without queuing everyone at the reader.
Access goes stale when it is maintained by hand. Here it is a consequence of the membership, so it is correct by construction.
Sell, upgrade, move or end a membership and the door grants follow the same day.
A visitor pass is a time limited grant on the doors that visit needs, and nothing else.
Door events feed check-in and attendance, so presence is measured rather than self reported.
If you choose to, non payment can restrict access. It stays a deliberate policy, never a surprise.
ZKTeco biometric and card readers are the ones we deploy most, connected through the DeskOS access gateway. Because grants are stored as our own records rather than inside a device, adding another controller family is an integration job rather than a migration.
No. Devices reach out to the gateway rather than the gateway reaching in, so no inbound ports and no public IP are needed. Commands are queued and only marked applied once the device confirms them.
Access ends on the last day of the term automatically, because the grant hangs off the membership. If they extend, it extends with them.
Yes, that is the default. Access is a matrix of members and doors, so a member can hold their floor and their cabin without holding the whole building.
Yes. Doors belong to centres, and members can hold grants at one centre or several depending on what they bought.
We will enrol a member, grant a door, end the membership and show you the credential stop working. It takes about ten minutes.