Executive Summary
A QR code on a desk is only as useful as the rules behind it. Stick codes on every workstation without deciding when check-in opens, how long a booking is held, or whether a scan is actually required, and you get a sticker program rather than a control system. This guide is written for the people who configure the system: workplace operations leads and IT admins who need to turn a hybrid attendance policy into concrete booking settings, then deploy QR codes that enforce those settings consistently across floors, offices, and devices. It walks through the policy settings a desk QR system depends on, the guardrails that make a scan meaningful, the rollout sequence, and the KPIs to watch in the first 90 days.
Audience + Job To Be Done
Primary readers are workplace operations, HR, and IT leaders in hybrid organizations of roughly 25 to 250 employees who share desks rather than assign them. The job to be done is specific: define booking and check-in rules once, apply them the same way everywhere, and get desk data that leadership can trust without someone walking the floor each morning.
Specialist Positioning
DeskHybrid is a desk-sharing specialist. It handles desk booking, check-in, release, and the reporting that comes from those events. It is not a broad workplace suite, and this guide does not cover visitor management, room booking, or facilities ticketing.
Start with the policy, then place the codes
The most common order of operations is backwards. Teams buy or print QR codes first, put them on desks, and then try to work out what a scan should mean. In a policy-driven office the sequence runs the other way. The attendance policy, whether that is "three anchor days a week" or "book before you come in", is translated into booking rules. The booking rules define when a check-in is expected. The QR code is simply the instrument that records whether that expectation was met.
Writing the policy down in operational terms forces useful decisions early. How far ahead can someone book? How short or long can a booking be? Is one desk per person per day enough, or do people genuinely move between desks? At what point does an unconfirmed booking stop being a reservation and start being wasted capacity? Each answer maps to a setting, and each setting changes how employees experience the QR code at their desk.
It also keeps the conversation between HR, workplace operations, and IT grounded. Instead of debating whether QR check-in is "too strict", the group debates a number: how many minutes after the booking starts should an unconfirmed desk be released? That is a question with an answer, and it can be revisited with data a month later.
Failure patterns that cause rollout drift
Three patterns account for most stalled QR programs.
**Codes without consequences.** If check-in is optional and nothing happens when people skip it, compliance decays within weeks. Employees quickly learn that the scan is ceremonial. Either connect check-in to automatic release of unconfirmed desks, or be explicit that check-in is informational only and do not report on it as if it were enforced.
**Enforcement without a fallback path.** The opposite failure is turning on strict QR enforcement before every desk has a readable code, before floor coordinates are set, or before employees know what to do if a scan fails. The first morning of failed check-ins becomes the story people tell about the system.
**Local exceptions that quietly become policy.** A floor manager tells one team they can skip scanning "for now". Six months later that team's desks are never released and their data looks perfect because nobody is measured. Exceptions should be time-boxed, written down, and reviewed, not granted in a corridor.
The policy settings a QR system depends on
DeskHybrid's policy engine keeps the settings that matter for QR check-in in one workspace-level policy, so every office and floor runs on the same rules. The settings to decide before launch are:
- **Booking horizon.** How many days ahead employees can book. Booking limits are evaluated against calendar days in each location's own timezone, so a team in a different region is not cut off early because of a server clock.
- **Minimum and maximum booking duration.** Short minimums allow half days; a sensible maximum stops all-week holds on a single desk.
- **One booking per person per day.** This one is built in rather than configured: DeskHybrid allows one active booking per employee per local day and blocks overlapping bookings for the same person, which removes the "book two desks just in case" habit before it starts.
- **Check-in window.** How many minutes before the booking start check-in opens. Employees receive a mobile notification when their window opens.
- **Desk release.** Whether unconfirmed bookings are released at all, and the delay in minutes after the booking start before they are.
- **QR-forced check-in.** Whether check-in must happen by scanning the desk's code, or whether the in-app check-in button is also accepted.
- **Location verification radius.** An optional extra requirement that the scan happens within a set distance of the floor.
Team-reserved desks sit alongside these settings. A desk can be assigned to a team, and only members of that team can book it, which is how many offices handle neighborhoods without reverting to fixed seating.
The practical advice is to settle these values in a short written policy before anyone prints a code. When an employee asks why their desk was released, the answer should be a sentence from that document, not an improvised explanation.
QR verification and location-control guardrails
A desk QR code in DeskHybrid is not just a link. Each code carries a signed payload that identifies the desk and its floor, and the server rejects codes that have been altered or that point to a desk on a different floor. That matters in offices where codes are photographed and shared: a picture of a code can still be scanned, which is exactly why the next two controls exist.
**QR-forced check-in.** By default, employees can confirm a booking either by scanning the desk code or by tapping check-in in the app once the window is open. Admins who need check-in to reflect physical presence can require QR check-in for desks. With that setting on, the check-in button is no longer accepted and the only valid route is a scan at the desk. For a policy-driven office, this is usually the setting that turns check-in from a courtesy into evidence.
**Location radius.** On top of QR-forced check-in, admins can require that the scan happens within a defined radius of the floor's configured coordinates. The employee's location is read once, at the moment of the scan, and compared with the floor location; there is no continuous tracking and nothing is collected between check-ins. Describe it to employees that way, because accuracy about what is and is not measured is what keeps the control acceptable.
Two operational notes. Location checks need coordinates set on each floor before they are switched on, otherwise scans fail with a clear "floor has no location" message. And indoor GPS can be imprecise, so set the radius generously at first and tighten it only if there is a real problem to solve.
No-show response and desk release timing
Release timing is the setting employees feel most directly. DeskHybrid checks every minute for confirmed bookings that have passed the release delay without a check-in, marks them as no-shows, and makes the desk bookable again for anyone eligible. The employee is notified on mobile that the booking was released.
Two settings interact here: the check-in window, which controls how early people can confirm, and the release delay, which controls how long after the start an unconfirmed booking survives. A wide window with a short delay suits offices where people arrive at consistent times. A narrow window with a longer delay suits offices with staggered arrivals or long commutes.
Do not tune these on instinct. Start moderately, then look at when people actually check in relative to their booking start. If most check-ins land in the first fifteen minutes, a much longer delay only holds empty desks. If a meaningful share arrive later, shortening the delay will produce complaints that look like a technology problem but are really a policy mismatch. For the full mechanics of release and recovery, see the no-show automation guide.
Cross-platform rollout sequencing
A QR program succeeds or fails on the phone in the employee's hand. DeskHybrid is available on Web, Android, and iOS. The native iOS app sits alongside the Android app and the employee web app, and the web app includes a camera-based scanner, so nobody is excluded by their choice of device.
Sequence the rollout so the scanning path is proven before enforcement goes live:
- Set floor coordinates and team-reserved desks in the admin tools.
- Export and print QR codes for every desk on a floor in one pass, rather than generating them desk by desk, and label each with the desk name employees see on the map.
- Run a pilot floor with QR check-in available but not forced. Watch for unreadable codes, poor placement, and scanning problems on specific devices.
- Place and test codes on the remaining floors to the same standard. QR-forced check-in is a workspace-wide setting, so every desk needs a working code before it is switched on.
- Turn on QR-forced check-in once failed scans are rare, then add location verification only if there is evidence it is needed.
The mobile apps reduce friction at the right moment. If the check-in window is already open when someone books, the app offers check-in straight away, and the desk dialog on the booking map shows a check-in button while the window is open. Under QR-forced check-in, the scan remains the confirming step. Biometric sign-in on the mobile apps means getting into the app at the desk takes a glance or a fingertip rather than a password.
Data quality controls for occupancy reporting
A QR system is supposed to produce data you can plan against, so protect the inputs.
**Double bookings are blocked at the database level.** Two people booking the same desk at the same moment cannot both succeed; the second request receives a clear error rather than a silent conflict. That keeps the desk map and the check-in record consistent with each other.
**Occupancy counts only active desks.** When a desk is deactivated for maintenance, a reorganization, or a broken monitor, it drops out of the occupancy denominator. Utilization figures stay honest instead of being diluted by desks nobody can book.
**Timezones are explicit.** New users default to the company's timezone, and booking rules are evaluated in each location's timezone. For organizations with more than one office, this removes a class of "my booking disappeared" tickets that come from mismatched clocks.
**No-shows are a status, not a guess.** Released bookings are recorded as no-shows, separate from cancellations, so reporting can distinguish people who changed plans and said so from people who did not turn up.
Governance model for HR, workplace, and IT
A policy-driven QR system needs clear ownership, because each function controls a different part of it.
**HR** owns the attendance policy and the language used to explain it. HR decides whether check-in is expected, how exceptions are handled, and how verified data may and may not be used.
**Workplace operations** owns the settings: booking horizon, durations, check-in window, release delay, QR enforcement, and team-reserved desks. Operations also owns the physical estate, which includes code placement, reprinting, and floor coordinates.
**IT** owns identity and devices. DeskHybrid supports single sign-on with Microsoft Entra ID (Azure AD), with accounts created just in time on first sign-in. When SSO is configured it becomes the primary sign-in action, SSO accounts never have a password, and display names come from the workspace rather than being edited by employees. For a QR program, that means the person scanning a desk is the person the directory says they are, and leavers lose access when their directory account is disabled.
Agree a change process across the three. Any change to release timing or enforcement should be announced before it takes effect, with a review date attached.
KPI framework for first 90 days
Measure in three phases rather than chasing a single number.
**Days 1 to 30: adoption.** Track the share of bookings that are checked in, failed scan attempts per floor, and support requests that mention QR. High failure rates in one area usually point to code placement or a missing floor coordinate, not employee resistance.
**Days 31 to 60: release behavior.** Track no-shows per week, how many released desks are rebooked the same day, and how arrival times cluster around booking start. This is the point to adjust the release delay.
**Days 61 to 90: decision quality.** Compare booked desks, checked-in desks, and active desk capacity by weekday. By now the data should support real decisions, such as which days need more desks, which floors can be consolidated, and which teams need a reserved neighborhood.
Review the numbers with HR, operations, and IT together once a month, and record every setting change with its reason and expected effect.
Execution checklist for production readiness
- Attendance policy written in operational terms and approved by HR.
- Booking horizon, duration limits, check-in window, and release delay agreed and configured.
- Decision recorded on QR-forced check-in and location radius, with the reasoning.
- Floor coordinates set on every floor that will use location verification.
- Team-reserved desks assigned where neighborhoods are needed.
- QR codes exported per floor, printed, placed at a consistent position, and test-scanned on Android, iOS, and web.
- SSO configured where the company uses Microsoft Entra ID.
- Employee communication sent covering why check-in exists, what happens to unconfirmed desks, and what location data is and is not read.
- Monthly review scheduled with named owners.