Check in is the only part of an event where the whole guest list is exercised at once, in public, under time pressure, by people who were handed the tool that morning. Everything that was slightly wrong during registration becomes visible in the first fifteen minutes: the duplicate entry, the guest who registered twice with two spellings, the six walk ins who were told it would be fine, the printed list that was accurate yesterday.
Most articles on this topic compare products. The more useful question is narrower. Check in software has one job, which is to turn a person standing in front of a desk into a recorded arrival in a few seconds, and then to leave behind an attendance record that is worth having. What follows is what that job actually requires, and where the choice genuinely matters.
What happens at the desk, in order
The door process is the same at almost every event, and naming the steps makes it clear which ones software can help with.
A person arrives and gives a name, or shows a code. Somebody finds them on the list. Their arrival is recorded. Something is handed over: a badge, a wristband, a programme, a seat number. If they are not on the list, a decision gets made. Then the next person steps forward.
The measure that matters is the time from arrival to recorded, multiplied by the number of guests, divided by the number of desks. Ten seconds per guest with two desks is fine for two hundred people and a disaster for a thousand. Before evaluating any tool, work out how many people arrive in the busiest fifteen minutes, because that number decides whether the answer is software, more desks, or both.
The two search paths
Every check in tool offers a code scan and a name lookup, and both have to work well, because the ratio between them is never what the plan assumed.
Codes are fast when the guest has the code ready. In practice a meaningful share of guests arrive without it: the email is buried, the phone is at two percent, the ticket was forwarded to a colleague. So the name lookup path is not a fallback, it is a primary path, and it has to tolerate a partial surname, a different spelling and a search by email address.
The requirements that actually decide the day
Feature lists for check in tools are long. A small number of items separate a calm desk from a queue.
Search that forgives. Partial matches, case insensitive, searching name and email at once, and tolerant of accents and hyphens. A search that requires an exact surname will fail on the first guest whose name was entered with a typo at registration.
An offline mode, or a plan without one. Venue wifi fails often enough that it should be assumed. A tool that holds the list locally and syncs later removes the risk entirely. If the tool needs a connection, the fallback is a printed list and a pen, and the reconciliation afterwards is manual.
Several devices on the same list. Two desks that each hold their own copy will double check in someone and miss someone else. Whatever runs the desk has to show the same state to every device within a second or two.
Adding a person at the desk. Walk ins, name changes and the guest who swears they registered all need a way to be entered on the spot, with the same fields as a registration, rather than on a sticky note to be typed in later.
An arrival that is recorded as data, not as a tick. A check in with a timestamp, and ideally the desk or the person who recorded it, is what makes the attendance record usable afterwards. A tick in a box tells you a fraction of that.
Badges, and whether printing on site is worth it
On site badge printing is the feature that most often gets bought and least often gets used well. It requires a printer, stock, a driver, a person who understands both, and a plan for when the printer jams at the worst moment.
Printing badges in advance and sorting them alphabetically is faster per guest and fails less. It costs you the walk ins, who need a hand written badge or a blank. For events where the list is largely settled a week out, pre printing wins. For events with heavy on site registration, or where the badge carries a session or a role that is only known late, printing on site earns its complexity.
Where the check in list comes from
This is the part that decides how much of the day is spent on data rather than on people, and it is usually settled months earlier, at registration.
If registration and check in are the same list, check in is a state change on a record that already exists. If they are different systems, somebody exports, somebody imports, and the list at the door is a snapshot. Every registration after the snapshot is a walk in as far as the desk is concerned, and every cancellation after it is a person who will be checked in by mistake.
| Approach | Good at | Where it costs you |
|---|---|---|
| A dedicated check in app fed by a spreadsheet import | Cheap, quick to set up, scanning and offline support built for the job | The list is a snapshot, so late registrations and cancellations have to be handled by hand at the desk |
| An event platform that does registration and check in | One list, codes issued at registration, badges and sessions handled in the same product | Priced per attendee or per event in many cases, and the attendee data lives inside that platform |
| A form tool with response management, plus a device at the desk | Registration, attendance status and the follow up email all sit on one list, and late registrations appear at the desk without an import | Purpose built scanning hardware and badge printing are not part of it, so the desk runs on name lookup or a separate scanner |
The third row deserves an honest note. A general form tool is not a turnstile. For a conference with three thousand delegates, session scanning and printed badges, a dedicated event platform is the right tool and the fee is justified. For the far more common case, a few hundred people at a workshop, an open day, a class, a members' meeting or a community event, the door work is a name lookup and a status change, and the value is that the same list already holds the registration answers and the email addresses. Event and course signups handled as one list is the shape that removes the import step.
Marking attendance without a scanner
Where an event does not need codes, attendance can be a field on each registration that the desk sets as people arrive. Two things make this work in practice. The field has to be editable from a phone, since nobody is carrying a laptop to a door. And the change has to be visible immediately to the second person on the desk, which rules out anyone working from a downloaded copy.
Recording the arrival time as well as the fact of arrival costs nothing and answers questions later: when the rush actually happened, how many arrived after the start, whether the second desk was needed. Internal fields that your team fills in after the form was submitted are the mechanism for this, and they export alongside the registration answers rather than in a separate file.
Who runs the desk, and what they should be able to see
The desk is almost never staffed by the person who built the registration. It is staffed by volunteers, casual staff or a colleague from another team, often for the first time, ten minutes before the doors open. Two decisions follow from that.
The first is training time. Whatever runs the desk has to be teachable in about two minutes, standing up, without a manual. That rules out anything where the attendance action is buried three screens deep, and it argues strongly for a single search box and a single button. A tool that is powerful but needs a walkthrough will be abandoned for a printed list by the second volunteer.
The second is access. Door staff need to find a guest and mark an arrival. They do not need to edit registration answers, delete records, send emails or see internal notes about who is a difficult customer. Limited access for the people on the desk protects the data and, more practically, protects the volunteer from making a change nobody can explain afterwards.
Write down the three actions the desk is allowed to take before the day: find a guest, mark them arrived, add a walk in. Anything outside those three goes to one named person with full access, who is also the person the desk escalates to when a guest insists they registered. That single rule removes most of the confusion at a busy door, because nobody has to decide on the spot what they are permitted to do.
The hour after the doors close
Check in data is worth more after the event than during it, and this is the part most setups throw away.
Three things come out of a good attendance record. The first is the no show rate, per event and eventually per audience, which is the number that tells you how many seats to sell next time. The second is the split between registered attendees and walk ins, which tells you whether registration is doing anything at all. The third is the follow up list, which is the only genuinely valuable asset an event produces: the people who actually came, separated from the people who said they would.
That third list is why attendance should live next to the registration rather than in a scanner's export. Sending one message to attendees and a different one to no shows is straightforward when both states sit on the same record, and awkward when attendance is in one file and email addresses are in another.
A short caution on reconciliation. If the desk had to fall back to paper for twenty minutes, do the entry the same evening rather than the following week, while the hand writing is still legible and the person who wrote it is still available.
What to change first
Work out how many people arrive in the busiest fifteen minutes and divide by the number of desks, because that single number tells you whether anything needs to change at all. Then make sure the list at the door is the live registration list rather than an export, since almost every awkward moment at a desk is a late registration or a cancellation that the snapshot did not carry. If registration, attendance and the follow up email currently live in three places, see what one list from signup to arrival looks like in Halict before the next event.
Q1. Does event check in software need to work offline?
Assume it does. Venue wifi and mobile signal fail often enough that a tool holding the list locally and syncing afterwards removes a real risk for no real cost. If the tool needs a connection, prepare a printed list sorted by surname as the fallback and plan to enter those arrivals the same evening.
Q2. Is QR code check in faster than looking up a name?
Only when the guest has the code to hand, which is less often than expected. A meaningful share of people arrive with the email buried or the phone dead, so the name lookup path carries more of the queue than the plan assumed and has to tolerate partial spellings and a search by email address. Treat both paths as primary.
Q3. Can a spreadsheet be used for check in?
For a small event with one desk, yes, and a printed list with a pen is sometimes the fastest option available. It breaks with two desks, because two copies diverge, and it loses the arrival timestamp and the link back to what the guest answered at registration. That link is what makes the follow up email and the no show rate easy afterwards.
Q4. How many check in desks are needed?
Work from the busiest quarter of an hour rather than the total. Estimate the arrivals in that window, allow roughly ten seconds per guest for a smooth lookup, and add a desk for every hundred and fifty or so arrivals in that window if a queue of more than a few minutes is unacceptable. One extra volunteer is usually cheaper than any software upgrade.
Q5. Should walk ins be allowed to register at the door?
If capacity permits, yes, but decide the fields in advance and capture them properly rather than on paper. A walk in entered with the same fields as a registration keeps the attendance record complete and puts the person on the follow up list, which is where the value of the event sits. Deciding this on the day is what produces illegible notes and lost contacts.