event check-in app
Event Check-In Apps: What Works at the Door
An event check-in app is the tool your staff run at the entrance: it finds an attendee, proves their ticket is valid, marks it used, and records that they arrived. Every one of those jobs happens under worse conditions than the website the ticket was bought on - one device, a queue, unreliable wifi, and a volunteer who has never used the app before.
That is the whole test. A check-in app that behaves perfectly on a desk in an office is not the same product as one that behaves at a sold-out door at 7pm, and only one of those is worth buying.
What an event check-in app has to do
Five jobs have to happen for every arrival, and an app that skips any of them pushes the work back onto a spreadsheet after the event. They are worth naming explicitly, because a demo usually shows only the first one.
- Find the ticket - by scan, by name, by email, or by order number, because people arrive without the QR code more often than organisers expect.
- Prove it is valid - the right event, the right date, not cancelled, not refunded, and not already used.
- Mark it used - once, in a way two entrances cannot both do at the same moment.
- Record the arrival - who came, when, and through which entrance.
- Handle the exception - the wrong tier, a comp, a duplicated name, or a ticket on a phone with a flat battery.
Why the door is not the website
Check-in fails for environmental reasons more often than for feature reasons. The software that survives a real door is the software built for the conditions rather than adapted to them.
- One device, one pair of hands. The person scanning is also answering questions and pointing people towards the cloakroom.
- A queue. Every extra tap per attendee is multiplied by the number of people waiting behind them.
- Unreliable connectivity. Venues are concrete boxes; assume the wifi drops and the mobile signal is weak in the room you care about.
- Bad light and awkward angles. Screens are dimmed, screen protectors and cracks interfere, and people hold phones at arm length.
- Staff who have never used it. Volunteer turnover means the interface has to be obvious without a training session.
The checks that decide whether the door runs
These are the capabilities worth testing before you commit, because they are the ones that only reveal themselves under load. A demo with three test tickets will not surface any of them.
- Offline tolerance - can it keep scanning when the connection drops and sync the arrivals when it returns, or does the queue stop dead? Ask what happens to a scan taken while offline.
- Duplicate control across entrances - if two doors scan the same ticket, does the second scan fail loudly, or does the attendee walk in twice?
- Fast name lookup - typing part of a surname or an order number should find the record in a moment, not after a spinner.
- Re-entry rules - venues that allow re-entry need that recorded without the ticket reading as already used.
- Tier-aware validation - a general-admission ticket should not open a VIP door, and the app should say why it refused rather than just flashing red.
- Permissions - a door volunteer should not be able to refund a ticket or edit an order from the scanning screen.
- Badge or label printing - at a conference, printing a name badge at the door turns check-in into the first useful moment of the day.
- A live count - how many are in, how many are still to arrive, and how many seats remain, readable by whoever is running the room.
Devices, entrances and how many you need
How many scanning stations you need is a throughput calculation, not a licensing one. Work out how many people arrive in your busiest ten minutes, then measure how many one station clears in the same window; the ratio tells you how many doors to open.
- A phone is enough for a single-door event with a steady arrival, so long as the battery lasts the evening.
- A tablet on a stand is easier to hold and to read, and it survives a full night on one charge.
- For two or more entrances, each station needs its own device and its own app session, plus the duplicate control that keeps them honest.
How to rehearse the door before the night
A ten-minute rehearsal the day before removes most of the failure modes you would otherwise meet in front of a queue, where every one of them is more expensive.
- Scan a test ticket on every device you intend to use, including the spare.
- Turn the wifi off mid-scan and confirm the app keeps working and syncs later.
- Print the fallback list - alphabetised names with ticket types - for the case where no device works at all.
- Brief the staff on the three things they will actually meet: wrong tier, already used, and no QR code.
- Name one person who owns the door, so exceptions have somewhere to go instead of being argued out in the queue.
Check-in is the last step of selling a ticket and the first step of the event. Judging an app on how it feels on a desk tells you nothing about how it behaves when the queue is real and the wifi is not.
Frequently asked questions
What is an event check-in app?
It is the software your staff use at the entrance to validate tickets and record arrivals. At its core it finds an attendee record, confirms the ticket is valid for that event, marks it used, and stores the arrival time and entrance. Everything else - badges, re-entry, live counts - hangs off those four jobs.
Does an event check-in app need an internet connection?
Not continuously, and that is the point. The app should be able to keep scanning while offline and sync arrivals once the connection returns, so a dropped signal slows the door rather than stopping it. Ask specifically what happens to a scan taken offline and how conflicts are resolved when the device reconnects.
How many scanning devices do I need at the door?
Enough to clear your busiest arrival window, which is usually the twenty minutes before start time. Measure how many attendees one station clears in ten minutes, then divide your peak arrivals by that number. Add a spare device and a printed fallback list for the case where the software or the network fails entirely.
Can the same ticket be checked in at two entrances?
Only if the platform keeps a shared used-state across devices and doors. If each device holds its own copy of the ticket list, two stations can both accept the same ticket and the attendee is counted twice. Ask how the platform handles a second scan of a ticket that was already admitted.
Should check-in be part of the ticketing platform or a separate app?
One platform is simpler when it works, because the ticket, the attendee record and the arrival count all agree without an integration to maintain. A separate check-in app can be a reasonable choice if the door team needs a different device or a purpose-built interface, but you then own the job of keeping the two systems in step.
Related on ShopDango
Run your next sale on your own domain
ShopDango gives each client a branded storefront and gives the operator one console for every store - auctions, events, rentals, subscriptions, and retail together.