What check-in is actually for
Check-in answers three questions: is this person expected, have they already come in, and how many people came. The first is the one everybody designs for. The second is the one that catches fraud and confusion — a code shown twice, a screenshot forwarded to a friend. The third is the one the organiser is asked the next morning, and the only one that needs the first two to have been answered honestly all night.
A paper list answers the first question slowly, the second badly and the third not at all. A spreadsheet on a laptop answers the first, and then the laptop is at the wrong door. The point of a check-in system is that all three are answered by the same record, at every door, at the same time.
Personal codes, not one code for the event
A single QR code on a poster tells you that somebody arrived; it does not tell you who. Give every guest a code of their own, sent with the invitation, and give each plus-one one too where you can. The code should carry nothing readable — no name, no email, no event — so that a photograph of it reveals nothing, and so that it can be revoked by changing what the code points to rather than what it contains.
Codes on paper are fine. A guest who prints the invitation should be admitted as smoothly as one who shows a phone; the scanner does not care, and neither should the staff.
A phone is the scanner
Dedicated scanners are hardware to rent, charge, pair and lose. Any phone the team already carries has a camera and a screen large enough for the only two things a door needs to see: the guest’s name, and a colour. Green means in; anything else means look at the screen. The screen should be readable at arm’s length in bad light — one name, one status, one line of detail such as a table number.
Give each device to a named person. The record of who admitted whom is the record you will need when a decision at the door is questioned, and a device tied to a name is what makes the record mean something.
Plan for no signal
A basement, a marquee, a hall with four hundred phones on the same cell: the door will lose its connection, and the moment it does is the moment the queue is longest. A check-in system has to keep working — scanning against a copy of the list held on the device, queueing admissions, and sending them when the connection returns.
Be honest about the limit. Two doors with no shared connection can both admit the same person and neither can know. What a system can do is notice at the moment they reconnect, keep both records, count the first as the admission, and put the second in front of a person instead of silently discarding it. Anything that promises more than that is describing a network that does not exist in a basement.
The second scan
The same code will be scanned twice. Sometimes it is a guest who went out for a cigarette; sometimes it is a screenshot on two phones; sometimes it is a member of staff scanning again because the first scan did not seem to register. A system that silently accepts the second scan has just lost the answer to “how many people came”; one that silently refuses it has just started an argument at the door.
The screen should say what happened — scanned at 20:14, main door, by Mert — and let the staff member choose: refuse, record a re-entry, or admit with a supervisor’s approval. Each of those is a different fact, and the report should keep them apart.
Walk-ins and the guest who is not on the list
Somebody important will arrive without a code. The options are to turn them away, to let them in and lose the record, or to add them at the door. The third is the right one, if the person adding them has the right to, and if the record shows that the guest was added at the door rather than invited. Those guests belong in the report among the people who came without replying, which is exactly what they are.
Approvals should be rare and recorded. A doubtful case admitted by a supervisor is fine; a doubtful case admitted by whoever was standing there, with no record, is a number in the report that nobody can explain.
Several doors
A main entrance, a VIP door, a press entrance, a side door for the caterers’ friends. Every door should see the same list, and a code scanned at one should show as scanned at the others within a second while the connection lasts. Where a segment belongs to a door — VIP codes at the VIP entrance only — the restriction should be enforced by the system, not by the staff’s memory of who is who.
Staff the doors by expected flow, not by importance. The main door needs the most devices in the first forty minutes; the VIP door needs a person who knows the faces.
The report the next morning
If the door was run as above, the report writes itself: who was invited, who replied, who was admitted, by name; who promised and did not come; who came without replying; re-entries, repeated scans and supervisor approvals as separate lines; arrival times by door, which is how you staff the next event. Export it in the form the person asking will accept — a spreadsheet for the operations lead, a page for the board.
- Personal codes per guest and, where possible, per plus-one; nothing readable inside them.
- A phone per staff member, each device tied to a name.
- A copy of the list on every device; admissions queued when the signal drops; conflicts shown, never silently resolved.
- The second scan explained on screen: refuse, re-entry, or supervisor approval — recorded separately.
- Walk-ins added at the door by somebody with the right to, and marked as such.
- Doors staffed by flow; segment restrictions enforced by the system.
- A report by name, exported in the form the reader accepts.