Comparisons· 9 min read

QR Code Meeting Room Booking: Where It Helps and Where It Is a Gimmick

QR booking is genuinely good at four things and a waste of a sticker at everything else. The split comes down to one question: how many taps does it take, and does the person scanning already have an account.

Someone is standing outside a meeting room with a laptop under one arm and a phone in the other hand. There is a sticker on the glass that says "Scan to book". They scan it. The phone opens a browser, which redirects to an app store page, which asks them to install an app, which asks them to sign in with a work account they are not signed into on their phone, which sends a verification code to a laptop that is currently asleep. Four minutes later they give up and go and sit in the kitchen.

QR codes on meeting rooms are neither a breakthrough nor a joke. They are genuinely excellent at a narrow set of jobs and useless at everything outside it, and the line between the two is drawn by one thing: how many taps stand between scanning and done. This post covers where QR earns its place, where it is theatre, and the practical mechanics (static versus dynamic codes, deep links, guest phones, placement and print size) that decide which one you end up with.

What a QR code actually is, briefly

A QR code is a two-dimensional symbology standardised as ISO/IEC 18004 (currently the 2024 edition, which replaced the 2015 one). It encodes bytes, usually a URL, in a grid of modules with Reed-Solomon error correction. Two practical consequences:

  • Error correction is selectable. Higher correction levels let a damaged or partly obscured code still scan, at the cost of a denser grid. For a sticker on an office wall that will get scuffed, do not use the lowest level.
  • The quiet zone is not decoration. The blank margin around the code (conventionally four modules wide) is part of the spec. Designers who crop it to fit a sticker are the reason your codes fail to scan.

A rough rule of thumb for sizing: the printed width should be at least one tenth of the intended scanning distance. A code someone scans from a metre away wants to be at least about 10 cm across. A tiny code at the bottom of a door sign is a code nobody scans.

Where QR genuinely helps

1. Check-in to confirm a booking

This is the strongest use case by a distance. The booking already exists. The person is already in the room. All they have to do is prove they turned up so the room does not get auto-released. Scan, one tap, done. No search, no form, no decision.

It works because the QR carries the context. The code identifies the room, the system already knows which booking is current, and the user's only job is to confirm. That is a one-tap interaction, and one-tap interactions get used.

It also gives you the booked-versus-turned-up data that calendar data alone cannot produce, which is the input to any honest no-show conversation.

2. Reporting a broken room

Underrated and almost free. A sticker that says "Something wrong in here? Scan." opening a two field form (what is wrong, optional detail) is the most reliable way anyone has found to hear that the HDMI cable is missing or the chair is broken. Compare it to the alternative, which is that the person makes a mental note, does not send the email, and the next person finds the same broken cable.

This works for the same reason check-in works: the code carries the room identity, so the user does not have to specify which room they are in. Removing that one step changes the completion rate dramatically.

3. Booking the room you are standing outside

Genuinely useful if the person already has a session. Someone walks past a free room, wants it for the next 30 minutes, scans, taps "Book 30 min", walks in. That is the ad hoc case that door displays exist to serve, and QR is a reasonable second path to it for people who prefer their phone.

The caveat is large enough to be the whole next section: this only works if scanning does not lead to a login wall.

4. Guests and contractors with no account

A visitor cannot use your booking system, does not have an account, and should not have one. But a QR code that opens a read-only page showing what is free on this floor right now is genuinely useful to them, and costs you nothing because it discloses no more than the display on the wall already does. This is the one guest scenario where QR beats everything else, precisely because it does not try to book anything.

Where it is a gimmick

1. As a replacement for calendar integration

If your rooms are not properly wired into Google Workspace or Microsoft 365 as room resources, a QR code does not fix that. It gives people a second, parallel booking system that disagrees with the calendar, which is strictly worse than one system that works. The subject of the meeting still needs to land on the room's calendar so that Outlook and Google Calendar show it. QR is a front door, not a foundation.

2. Anything requiring a login on a phone in a corridor

This is the failure in the opening scene. Consider what a scan actually hits on a colleague's phone:

  • Best case: they have the app installed and are signed in. Two taps to done.
  • Common case: they have the app but it has logged them out. Now they are doing SSO on a phone, possibly with MFA, standing up.
  • Worst case: they do not have the app. Now it is an install, an account setup and a sign in, all before booking a room for fifteen minutes.

App dependency is a real design pattern in this category, not a hypothetical one. Joan, for example, documents a QR and NFC flow in which an admin generates a code per desk from the admin portal, and scanning it opens the Joan Workplace mobile app to complete the booking or check-in. That documentation covers desk booking and desk check-in rather than meeting rooms, so it is not a like-for-like comparison with a room display, but it illustrates the pattern well: an app-centred flow is a perfectly sensible design if your whole company already runs the app, and if they do not, the sticker on the wall is an advert for an install rather than a booking mechanism.

3. Any flow with more than two taps

Set this as a hard rule and it will decide most of your design questions for you. Scan plus two taps or it does not ship. A person standing in a corridor holding a laptop has roughly ten seconds of patience. Every extra screen, every "select duration" dropdown, every "confirm your details" halves the completion rate.

The mechanics that decide whether it works

Static versus dynamic codes

A static QR encodes the destination URL directly. Nothing between the phone and the destination, so it works forever with no dependency, but if the URL changes you reprint every sticker in the building.

A dynamic QR encodes a short redirect URL that you control, so you can change the destination later without reprinting. That flexibility costs you a redirect service that must stay up, and if that service is a third party marketing tool, it is now a dependency on your room booking working and possibly a tracker you have to declare.

For room codes, dynamic is usually the right call, but host the redirect yourself on a domain you own. A room booking flow that breaks because a QR shortener changed their pricing is a bad afternoon.

Deep links and what happens without them

A well built flow uses a universal link (iOS) or app link (Android) so that the same URL opens the native app if it is installed and a web page if it is not. Without that, you get the worst outcome: a web page that tells the user to install an app, losing the room context in the process, so after installing they land on a home screen and have to find the room manually.

Test this properly, on a phone that does not have the app, on both platforms, with the work account not signed in. That is the actual user, not you.

The guest phone with no session

Decide explicitly what a scan does for someone with no account. Three defensible answers:

  1. Show a read-only availability page. No auth, no personal data beyond what the wall display already shows.
  2. Show nothing and say so clearly ("Staff booking only, ask at reception").
  3. Allow a guest booking with a name and email, if your policy allows it and you have thought about the data you are collecting.

The undefensible answer is a login page with no explanation, which is what most deployments actually do.

Printing and placement

  • Eye height, next to the door handle side. Not on the door itself if the door swings, because the code moves.
  • Not on glass with a bright window behind it. Backlight kills contrast and phones fail to lock on.
  • Laminate or use a proper vinyl sticker. A paper printout scuffs in a month.
  • Put the room name in human-readable text on the sticker. When the code fails, the person can still find the room in Outlook.
  • Say what the code does. "Scan to check in" and "Scan to report a problem" get scanned. "Scan me" does not.

The accessibility problem, stated plainly

A QR-only flow excludes people. Not hypothetically, concretely:

  • Anyone without a smartphone, or without a work-configured smartphone. In plenty of European workplaces staff are not issued phones and are not obliged to use personal ones for work.
  • People with low vision, for whom locating and framing a small printed code is genuinely difficult.
  • Wheelchair users, if the sticker is at standing eye height. Placement height is an accessibility decision, not a design one.
  • Anyone whose phone battery is dead, which is a mundane case that happens constantly.

The rule that follows: QR is always an additional path, never the only path. Whatever the code does, there has to be a way to do the same thing without a phone, whether that is a button on a display, a room list in Outlook or a person at a desk. If your check-in mechanism is QR-only, some fraction of your staff cannot check in, and their rooms get released while they are sitting in them.

A short test before you print anything

  1. Count the taps from scan to done on a phone that has never seen your system. If it is more than two, redesign.
  2. Test with the work account signed out. That is the real state most phones are in.
  3. Test in the actual corridor lighting, not at your desk.
  4. Ask what happens for a guest. If the answer is "a login page", fix it.
  5. Check there is a non-QR way to do the same thing.

The buy side of this decision

Our own position, since this is our blog and we ship a QR feature. Lobby is a meeting room display that syncs in real time with Google Workspace and Microsoft 365 room resources, on e-ink hardware from USD 69 per room, in a browser tab, or as a room overview board. On the Pro Unlimited plan we include QR stickers for room feedback, free on that plan: someone scans the sticker in the room and tells you the projector is broken.

Being precise about what that is and is not: it is the "report a problem" use case from section 2 above, and nothing else. It is not QR booking, it is not QR check-in, and it does not replace the display. Booking happens on the display or in the calendar. We chose feedback because it is the use case that works with zero account, zero app and one tap, and we would rather ship the narrow thing that works than the broad thing that leads to an app store page.

On pricing, so the plan names above mean something: the Free plan covers up to 3 displays with no credit card and is free forever rather than a trial. Unlimited is USD 30 per month billed yearly (USD 50 per month month to month). Pro Unlimited, which is the tier with the QR stickers, is USD 60 per month billed yearly (USD 100 per month month to month). Paying yearly saves 40 percent and there is no annual contract lock-in. The e-ink hardware is bought direct from the manufacturer with no markup from us, at USD 69 each for 1 to 9 units and USD 62.99 at 10 or more.

The rest of what Lobby does not do, plainly: no desk booking, no visitor management, no room or AV automation, no enterprise SSO or SCIM at scale, no MDM on the e-ink hardware, no on-premises Exchange without hybrid. The e-ink panel is battery powered and refreshes on an interval (15 minutes on the Free and Unlimited plans, 5 minutes on Pro Unlimited), so it is not an instant-response touchscreen. Setup is under 10 minutes with no sales call.

TL;DR

  • QR works when the code carries the context and the user's only job is to confirm. Check-in and problem reporting are the two clear wins.
  • Booking from a QR works only if the person already has a session. Otherwise the sticker is an app install advert.
  • For guests, the good QR use case is read-only availability, not booking.
  • Hard rule: scan plus two taps, or redesign.
  • Use dynamic codes on a redirect you host yourself, and use universal or app links so an installed app opens with the room context intact.
  • Test signed out, on both platforms, in the real corridor lighting.
  • Print big enough (roughly one tenth of scanning distance), keep the quiet zone, laminate, and label what the code actually does.
  • QR-only excludes people. It is always an additional path, never the only one.
  • A QR code is not a substitute for proper room resources in Google Workspace or Microsoft 365.

Related reading

Sources

Competitor product behaviour described above is taken from the vendor's own published documentation and was verified on 5 August 2026. Features and pricing change. Verify current behaviour directly with the vendor.

Try Lobby — free forever up to 3 displays

Room booking that just works.

Get started →