Readers, controllers, room panels, kiosks, printers and POS peripherals connected to the same platform as your memberships. Standard hardware you buy locally, and a gateway designed for real building networks.
The reader has one list, the printer has another, the room panel has a third, and none of them know who is still paying you. Somebody keeps them roughly in sync, which means they are always slightly wrong.
ZKTeco face, fingerprint and card devices connect through the DeskOS access gateway. Enrolments, grants and revocations are driven from the membership rather than from the vendor app on someone’s laptop.No second system to maintain
Devices sit behind NAT on the building network and reach out to the gateway rather than the other way round. Commands queue until the device confirms them, and confirmation is what marks something applied.No ports opened to the internet
A tablet outside each room shows what is booked now and next, takes an ad hoc booking, and releases the room when nobody checks in. It reads the same calendar as the app and the front desk.No more ghost bookings
A tablet at the entrance handles self check-in, guest passes, photo capture and day pass purchase, then notifies the host. Optional badge printing where your building requires it.Reception without a queue
A small agent on a Raspberry Pi connects your existing printers, meters pages per member, applies plan quotas and bills the overage. Jobs report back so a failed print is visible instead of mysterious.Printing that pays for itself
Receipt printers, kitchen displays and card terminals on standard hardware, running in the browser. The counter keeps working through a network drop and syncs when it returns.Off the shelf hardware, no lock-in
Devices are standard and sourced locally. We tell you exactly what to buy and we do not resell it with a margin on top.
Existing enrolments on a device can be matched to members instead of re-enrolled, so a live building can move over without queuing everyone at a reader.
A reader or an agent that stops reporting in raises an alert, so you learn about a dead device from us rather than from a member stuck at a door.
Every device in the building answers the same question: is this person allowed to do this, right now. There should be one place that knows the answer.
Grants are our records, reconciled onto devices, so a revocation cannot un-revoke itself on a reboot.
Panels read the same booking calendar as the app, and release a room nobody checked into.
The kiosk issues a real time limited door pass rather than a printed sticker with no authority.
Metered printing and POS sales become invoice lines with the right tax on the right entity.
ZKTeco face, fingerprint and card devices are the ones we deploy most, through the DeskOS access gateway. Because access grants live in our own records rather than inside a device, supporting another controller family is an integration rather than a migration.
No. Devices connect outward to the gateway and pull their commands, which is what makes this work on ordinary building networks behind NAT. Nothing is marked applied until the device confirms it.
Usually yes, and that is the cheaper path. Send us the make and model of your readers, printers and tablets and we will tell you honestly what connects and what does not.
Standard Android or iOS tablets. The panel and kiosk are apps pointed at your workspace, so replacing a broken tablet is a ten minute job rather than a service call.
Readers hold their enrolments locally and keep working. Events are buffered on the device and drain to the platform when the connection returns, so the log stays complete.
Tell us what readers, printers and tablets you already own and we will tell you honestly what connects, what needs replacing and what it costs.