Visitor Check-In: Why a QR Code Beats an iPad on a Stand
Eight guests arrive at 08:58 for a nine o'clock meeting and there is one iPad on a stand. One tablet is a queue; a QR code is eight check-ins at once. The full argument on throughput, hardware you never buy, and input quality, plus the four situations where the tablet still wins.
Eight people arrive at 08:58 for a nine o'clock board meeting. There is one iPad on a stand next to the door. The first guest starts typing their name with one finger, reaches the company field, and the other seven form a line behind them in their coats.
That is the whole argument in one scene. One tablet is a queue. A QR code on a sign is eight check-ins happening simultaneously on eight phones, and the person standing at the back finishes at roughly the same moment as the person at the front.
What follows is the comparison done properly: throughput, the cost of owning a device in a lobby, input quality, hygiene, and failure modes. Then the part most vendor pages skip, which is the four situations where a tablet or a staffed desk genuinely still wins. And finally the awkward new problem with the QR model, which is that a growing number of your guests have been trained not to scan unknown codes, and they are right to be careful.
Throughput: one terminal serialises everything
A check-in is not one action. It is a small form: name, company, who you are here to see, sometimes a phone number, sometimes accepting an NDA or a site safety notice. On a shared terminal that form runs start to finish before the next person can begin.
Do not take a vendor's word for how long it takes. Time it yourself with a phone stopwatch, using a real guest rather than the office manager who has done it two hundred times. In most receptions you will land somewhere between 40 and 90 seconds per guest once you include the person reading the screen, mistyping the host's surname, and stopping to ask whether they need to accept the confidentiality notice. That range varies enormously with how many fields you ask for and whether the guest has been there before, which is exactly why a single global number is useless.
The arithmetic is unforgiving because it is linear. At 60 seconds per guest, eight arrivals is eight minutes of queue, and the last person in the line checks in at 09:06 for a 09:00 meeting. At 90 seconds it is twelve minutes. Nothing about the software fixes this, because the constraint is the single input device, not the form.
The QR model removes the constraint rather than optimising it. Eight guests scanning a sign is eight parallel sessions. Total elapsed time is not eight times one check-in, it is the slowest single check-in, plus however long it takes people to notice the sign. Ten guests is the same. Forty guests for a customer event is the same, which is the case where the gap stops being a nicety and becomes the difference between a lobby that works and a lobby with a queue out of the door.
There is a second-order effect worth naming. Because the terminal is a bottleneck, every field you add to the form costs you queue time, so terminal deployments tend to shrink the form until it stops collecting anything useful. On the guest's own phone, an extra field costs that guest four seconds and costs nobody else anything.
The device you never buy, charge, patch or replace
A tablet in a lobby is not a purchase, it is a small ongoing operation. You buy the device, then the enclosure, then the security tether, then you discover the nearest socket is four metres away behind the sofa. You enrol it in mobile device management so it stays in kiosk mode and so nobody walks out with a usable iPad. You keep it patched. You replace it when it stops receiving operating system updates, which happens years before the glass or the battery gives out.
None of that is dramatic. It is just a permanent low-level tax on somebody's week, and the person paying it is usually an office manager who did not sign up for endpoint management. We have itemised the three-year cost of that model per entrance in a separate post on what a reception iPad actually costs, because it deserves its own arithmetic rather than a hand wave here.
The QR side of the comparison has a hardware bill too, and it is honest to state it: a printed sign, a frame, and the ten minutes it takes to put it on the wall at eye height. There is no battery, no operating system, no patch cycle, and no MDM licence. If it gets damaged you print another one. If your building has three entrances you print three, which is the point at which the two models diverge most sharply, because the terminal model multiplies a device and a per-location licence by three while the QR model multiplies a sheet of paper by three.
The same logic runs through our writing on screens on walls elsewhere in the building. Every powered device you hang in a public space is a thing somebody has to look after, and the honest question is always whether it earns its keep.
The guest's own phone is a better input device than your tablet
This is the argument that gets least attention and probably matters most.
Your guest's phone has their keyboard on it. Their language. Their autocorrect dictionary, which already knows how to spell their own surname and their employer's name. Their text size setting. Their screen reader, their high contrast mode, their switch control, their zoom. If they have low vision or limited dexterity, their phone has already been configured around that, over years, by them.
The lobby tablet has none of it. It has whatever font size the vendor chose, in whatever language the office manager set at install, with the accessibility settings locked out because kiosk mode locks out the settings app. A guest who needs 200 percent text is standing in front of a screen that will not give it to them, in a queue, being watched by seven people.
There is a dignity argument here as well as a compliance one. Filling in a form is a private act. Doing it on a screen mounted at chest height in a public lobby means the person behind you can read your name, your employer and your phone number over your shoulder, and in a building where visitors from competing companies pass through the same reception, that is a genuine leak. On a phone held at a normal reading distance it is not.
The language point is not a small one either. A terminal typically runs one language, or offers a language picker that adds two taps and a moment of confusion to every check-in. A web check-in on the guest's phone can follow the browser's language preference by default. That does not solve translation quality, and someone still has to write and maintain the strings, but it removes the step where a visitor stands at a screen looking for a flag icon.
Hygiene, and the sticky screen problem
The hygiene argument arrived loudly in 2020 and then quietly stayed, which is roughly the right outcome. A shared touchscreen in a lobby is a surface every visitor touches with their hands before shaking somebody else's. Cleaning it is a real cleaning task that in practice gets done when someone remembers.
Do not overstate it. A door handle is also a shared surface and nobody proposes removing doors. The honest version is that a shared screen is one more thing to clean, that visibly grubby glass is a bad first impression regardless of transmission risk, and that a check-in on the guest's own phone removes the task rather than scheduling it.
The worst failure mode is a tablet that looks like it works
Powered devices in lobbies fail in a specific and irritating way. The app crashes to the home screen, or the session expires and the screen shows a login box, or the tablet drops off the wifi and quietly shows the last frame it rendered. To an arriving guest all three look like a working check-in terminal. They stand there, they tap, they wait, and then they look around for a human.
A dead battery is worse still, because a black screen at least reads as broken. A stale screen reads as fine. This is the same failure pattern we have described for availability screens outside meeting rooms: a display showing confidently wrong information is more damaging than no display, because people act on it.
The QR model has failure modes too, and pretending otherwise would be dishonest. The sign can be defaced, covered by a delivery, or taken down by a cleaner and never put back. The check-in service itself can be down, in which case the guest's phone shows an error and you have the same problem you would have had with a terminal. The difference is in the shape of the failure. A missing sign is obviously missing. A broken sign is obviously broken. The failure is legible, which means the guest does the sensible thing and looks for a person, rather than tapping a frozen screen for ninety seconds first.
Where the tablet or a staffed desk still wins
Four cases, and they are real. If your building is one of them, the QR-only design will hurt you.
Guests without a usable smartphone
Not everybody has one, not everybody has one with them, and not everybody has one with charge left after a two-hour drive. Older visitors, contractors on site with a locked-down work handset, and delivery drivers are all common cases. Any building that goes QR-first needs a fallback that does not require a phone, whether that is a doorbell to a staffed extension, a printed sheet, or a small terminal kept specifically for the exceptions.
Guests who will not scan a code they do not recognise
This is growing and it is a healthy instinct. See the next section, because the answer is design work rather than persuasion.
No guest wifi and poor mobile signal
QR check-in is a web page, and a web page needs connectivity. Basements, older concrete and steel buildings, lift lobbies, and industrial sites away from town all break this. The specific trap is the building where signal is fine at the front door and absent three metres inside it, so the code scans, the page half loads, and the guest gets a spinner.
Test this before you commit: stand exactly where the sign will hang, put the phone on the mobile network with wifi off, and load the check-in page. Do it on both a recent iPhone and a mid-range Android, because radio performance differs. If it fails, either provision an open guest network that does not itself require a login (a captive portal that requires a check-in code is a circular dependency and it will happen to somebody) or keep a terminal.
Photo capture and identity document checks
Some sites must photograph the visitor or scan a passport or national ID card, usually because of financial sector rules, pharmaceutical or food traceability requirements, or a client contract that demands it. A phone camera can technically do this, but the compliance question is whether you can prove the photo is of the person standing in your lobby rather than an image from their camera roll. If the answer has to be yes, you need a supervised capture on your own device, which means a terminal or a staffed desk. Badge printing sits in the same category: if the site needs a physical badge, something physical has to print it.
QR code trust, and how to design a sign that does not look like a quishing attack
Malicious QR codes are a real attack technique, common enough that the FBI's Internet Crime Complaint Center issued a public service announcement about tampered codes in January 2022, and common enough that stickers placed over legitimate codes on parking meters and charging points have become a routine fraud pattern. Security awareness training now tells staff not to scan codes they do not recognise. That training is working, which means a percentage of your visitors will hesitate at your sign.
You cannot argue them out of it and you should not try. You design around it.
- Make the sign obviously yours. Your logo, your colours, printed properly, in a fixed frame. A laser-printed A4 sheet taped to the wall next to a fire door looks exactly like what an attacker would put there, because it is exactly what an attacker would put there.
- Print the destination domain in readable text. Under the code, in words: the actual hostname the code resolves to. A guest who is suspicious can then read the domain before scanning, and can compare it against what their phone previews when the camera picks up the code. Most phone cameras show the URL before opening it, which only helps if the guest has something to compare it against.
- Use a domain a visitor can recognise. A subdomain of your own company domain is ideal. A generic vendor shortener with a random string in it is the worst option available, because it is unverifiable by design and it is precisely the pattern attackers use.
- Print a short URL as a typed fallback. Some people will never scan and will happily type. Make the fallback short enough to type on a phone keyboard without errors, and test it out loud with somebody who has not seen it.
- Fix the code to a hard surface and check it. A sticker over your code is the whole attack. A framed sign behind glass or an engraved plate makes tampering harder and makes it visible. Add a look at the sign to whatever weekly walkaround your facilities team already does.
- Do not ask for anything a lobby has no business asking. If your check-in page asks for a payment card or a password, you have taught your visitors that your building does exactly what the fraud does.
There is an honest counterargument to all of this: a well-designed sign can still be replaced with a well-designed fake, and a determined attacker will do that. Signage design reduces the casual case, not the targeted one. The targeted case is handled by the sign being physically hard to tamper with and by somebody actually looking at it.
What both models have to do anyway
Choosing QR over a terminal decides the input device. It does not decide whether the system is any good. The things that determine that are identical either way, and they are worth listing because they are where the buying decision actually gets made.
The host has to be told automatically, by SMS, email or a chat message in whatever tool the company already lives in, and there has to be an escalation path when the host is in a meeting with notifications off. Any system worth buying handles this, and if a vendor cannot show you the escalation working in a demo, assume it does not exist.
NDAs, site safety rules and access conditions have to be presentable at check-in and the acceptance has to be logged with a timestamp and a version number, otherwise the log proves nothing later. The on-site roster has to be live and usable as an evacuation list, exportable and broadcastable in one action, because that is the requirement that turns a visitor log into something a health and safety audit will accept. Data has to be stored somewhere you can point at, deleted on a schedule you set, and not quietly copied to a third country.
Those requirements are why compliance-heavy sectors buy this software at all. Operators covered by the NIS2 Directive and the CER Directive are expected to control and evidence physical access, and food and pharmaceutical sites have traceability obligations that a paper book in a drawer does not satisfy. The retention side is ordinary GDPR storage limitation work, and it applies to visitor records exactly as it applies to booking data.
The honest test
Stand in your own lobby at your busiest arrival time for a week and count. If your peak is two people arriving in the same minute, the queue argument is theoretical and either model works. If your peak is a board meeting, a training day, an audit team or a customer event, the queue argument is the only one that matters and it will not get better.
Then check the four exception cases. If you have no signal at the door, or you must photograph visitors, or you must hand out printed badges, the answer is not QR-only, it is QR plus something. Most buildings end up there anyway: a code on the wall for the ninety percent, and a doorbell for the rest.
TL;DR
- A shared terminal serialises check-in. At a realistic 40 to 90 seconds per guest (time it yourself, the range is wide), eight arrivals is a queue of eight to twelve minutes, and no amount of software design fixes a single input device.
- QR check-in is parallel by construction. Total time is the slowest single check-in, whether that is eight guests or forty.
- The tablet is not a purchase, it is an operation: enclosure, tether, power, MDM enrolment, patching, replacement when OS updates stop, and someone's time when it locks up.
- The guest's own phone brings their keyboard, language, reading speed and accessibility settings. A kiosk-mode tablet locks all of that out, and it makes a private form into a public one.
- The worst tablet failure is a stale screen, because it looks exactly like a working terminal. A missing or broken sign at least reads as missing or broken, so the guest looks for a person sooner.
- Four cases still favour a terminal or a staffed desk: guests without a usable phone, no connectivity at the door, mandatory photo or ID document capture, and physical badge printing.
- QR distrust is real and reasonable. Answer it with a branded sign in a fixed frame, the destination domain printed in readable text, your own domain rather than a random shortener, a typed short URL fallback, and a tamper check on the facilities walkaround.
- Input device aside, both models live or die on the same things: automatic host notification with an escalation path, timestamped NDA and policy acceptance, a live roster that works as an evacuation list, and a retention rule you can actually point at.
Related reading
- The reception iPad costs more than you think, the three-year arithmetic per entrance.
- Guest check-in without an app, the full journey from front door to meeting room.
- Pre-registering external guests from a calendar invite, the highest-value feature in the category.
- QR code meeting room booking, the same scan-and-go pattern applied to rooms.
- Securing displays in public areas, for anything you do end up hanging in a lobby.
Sources
- FBI Internet Crime Complaint Center, which published a public service announcement in January 2022 on criminals tampering with QR codes, the basis for the tamper-resistance advice above.
- UK National Cyber Security Centre, general guidance on phishing and user awareness training, which is why a share of your visitors now hesitate at unknown codes.
- Directive (EU) 2022/2555 (NIS2), security and access control obligations for in-scope operators.
- Directive (EU) 2022/2557 (CER), resilience obligations for critical entities, including physical access.
- Regulation (EU) 2016/679 (GDPR), Article 5(1)(e) storage limitation, which is what a visitor log retention rule has to satisfy.
- W3C Web Content Accessibility Guidelines 2.2, the reference for text resize, contrast and target size on a check-in page.