The queue at the door of an event is not determined by the total number of guests, but by the combination of two things: how many people arrive at the same time and how many the reception can process per minute. An event with 500 guests can go smoothly if arrivals are distributed; another with 150 can form a queue in a few minutes if almost everyone appears at the same window and each service requires additional decisions.
Therefore, designing a check-in with QR Code starts before choosing cell phones, readers or applications. The central point is to transform the entry into a measurable operation: estimate the peak arrivals, measure the real time of the normal flow, calculate the capacity of the stations and remove exceptions from the main queue. Technology helps, but it cannot alone correct an undersized reception or a team without contingency procedures.
Start with peak arrivals, not total guests
The total number of people is just the size of the universe. To calculate entry pressure, it is most useful to estimate how many guests are expected to arrive at the busiest window. This window can be 10, 15, 20 or 30 minutes, depending on the type of event and expected behavior.
A wedding with a scheduled ceremony, a lecture with a strict schedule or a show with a main attraction tend to concentrate more arrivals near the beginning. A fair with access over several hours can better distribute the flow. The estimate must use what the organizer really knows: gate opening times, main program times, history of previous editions, RSVP, contracted public transport, excursions, parking and any other factor capable of concentrating people.
The basic account is simple. If you expect 120 arrivals in 20 minutes, the peak equates to 6 people per minute, or 360 per hour. This number does not mean that 360 people will arrive during an entire hour. It serves to represent the intensity of that critical stretch and compare this demand with the capacity of the stations.
When there is no history, work with scenarios. A more distributed scenario, a likely scenario, and a high concentration scenario are more useful than pretending that there is an exact prediction. The function of planning is to discover at what point the structure stops following arrival.
Measure actual service time before calculating jobs
There is no universal QR Code check-in speed. The time depends on the device, the lighting, the interface, the team's experience and, mainly, everything that happens beyond reading the code.
The test needs to reproduce the actual sequence. The guest approaches, presents their cell phone or printed ticket, the team locates and reads the QR, waits for confirmation, hands out a bracelet or credential when available and guides the person on the next step. If the flow includes document checking, material delivery, table selection or any other task, this also enters the time.
Do several repetitions and record the times. Don't just use best attempt. The average helps to calculate capacity, but dispersion also matters: if some services are much longer than others, the queue becomes more sensitive to peaks and interruptions.
Current documentation for check-in systems confirms an important operational standard: QR reading usually coexists with manual search by name, and several platforms allow more than one device to work on the same event. Some also offer offline operation as long as the data is loaded beforehand. This reinforces a practical conclusion: the station must be tested as a complete system, and not just as a camera pointed at a code.
Transform the measured time into capacity per station
After measuring the average time of normal flow, it is possible to estimate the theoretical capacity of a station.
If the average service takes 15 seconds, a station would have a theoretical capacity of 240 services per hour, because 3,600 seconds divided by 15 result in 240. If the predicted peak is 360 arrivals per hour
Now, dividing 360 by 240 produces 1.5. In this case, two stations are the mathematical minimum for the nominal capacity to exceed the arrival.
The formula can be written like this: capacity per station per hour = 3,600 / average time in seconds. Then, minimum stations = peak arrival rate / capacity per station, always rounding up.
This result is a floor, not the final dimension. Queuing theory shows that waiting time increases rapidly when utilization approaches the capacity limit. In practice, arrival variations, delays in opening a ticket, reading failure, change of operator and small interruptions make operating permanently at the limit fragile.
The margin must reflect the risk of the event. Instead of adopting a universal percentage, compare the scenario with an additional station, evaluate the available physical space and decide how much idle capacity you accept to purchase in exchange for lower queue risk. For a short, critical opening, redundancy may be worth more than maximum efficiency.
Three scenarios to understand the account without creating a universal speed
The following examples use 15 seconds per service only as a hypothetical number obtained in testing. It is not a market reference and should be replaced by the measurement of your event.
Scenario with 100 guests
Imagine that 50 of the 100 guests are expected within a 15-minute window. This equates to 200 arrivals per hour at peak. With 15 seconds per service, a single station would have a theoretical capacity of 240 per hour.
Mathematically, a position exceeds expected demand. Operationally, however, it leaves reception without redundancy: any crash, doubt or device change interrupts the entire flow. The organizer may decide to open a second station even if the minimum bill indicates one, especially when entry needs to happen within a few minutes.
Scenario with 250 guests
Consider 120 arrivals in 20 minutes. The peak rate is 360 per hour. With a theoretical capacity of 240 per hour at each station, one station is insufficient and two offer a nominal capacity of 480 per hour.
In this scenario, the structure starts with two stations and must be tested with simulated arrivals. If the trial shows that people arrive in groups, that wristband handing out adds time, or that exceptions contaminate the main queue, a third resource can be kept as backup or support in the first few minutes.
Scenario with 500 guests
Now assume 250 arrivals in 20 minutes, equivalent to 750 per hour at peak. With the same hypothetical time of 15 seconds, three stations would provide 720 services per hour and would already be below expected demand.. Four stations would increase the nominal capacity to 960 per hour.
The difference shows why just rounding the total guests by some fixed number of people per receptionist is a weak method. What changes the need for staff is the concentration of arrivals and the real time of the process.
Separate the normal flow from the exception flow
Fast reception depends on preventing a two or three minute case from occupying the same post that normally responds in seconds. Missing name, different companion, unavailable QR, ticket already used, payment problem, special credential or authorization doubt are examples of occurrences that may require investigation.
The most efficient procedure is to define what the normal queue team can resolve immediately and at what point the guest should be forwarded to an exceptions point. This point could be a table
dedicated, a supervisor with a tablet or a lateral position close to the entrance. The format depends on the expected volume.
Separation should not be humiliating or feel like punishment. It exists to allow people to receive more attention without blocking dozens of guests who already have everything in order. Signage and staff training need to explain this flow in a neutral way.
If the number of exceptions is very low, a mobile supervisor may be sufficient. If the event has a complex list, many companions, pending payments, multiple types of credentials or changes at the last minute, it is worth dimensioning specific capacity for this service. The same principle applies: measure how long these cases take and keep track of how many appear.
Manual search should be an official path, not improvisation
When the QR is not available, the first digital contingency is usually to locate the person at the base. Current check-in systems offer search by name, and some also allow you to search for order details or email. This feature needs to be rehearsed before the event.
The team must know which fields are reliable for locating the guest and how to act when the same names appear, an order in someone else's name or multiple tickets appear in the same purchase. If each attendant invents a criterion, the risk of releasing the wrong person or registering duplicate attendance increases.
It's also important to decide what data actually needs to be available on the port. The more personal information is exposed on screens, spreadsheets or printed lists, the greater the care required with access and disposal. Contingency must resolve input without turning reception into a point of unnecessary data exposure.
Offline mode is only a plan B when it has been prepared beforehand
Some check-in apps can continue reading tickets and registering attendance without a connection, but they usually require that the event and the list of participants have been loaded onto the device while the internet is still available. There are also functions that may be unavailable offline.
Therefore, "the application works without internet" is not a complete contingency. Before opening, place appliances in a condition similar to the failure you fear. Confirm that the list is still accessible, that the QR is validated, that the manual search works, what happens to local appointments and how the data synchronizes when the connection comes back.
The simultaneous use of multiple devices deserves special attention. With an active connection, platforms can synchronize check-ins between devices. Without connection, this behavior can change. If two offline stations do not immediately share information that a ticket has already been used, the team needs to know this limit and adopt a compatible procedure.
Have a contingency outside the application
An exported list can be a last resort when devices, accounts, batteries or infrastructure stop working. Event platforms even offer exporting or printing of lists precisely for this type of operation.
The contingency copy must be generated at a defined moment and treated as a photograph of the base at that moment. If there are sales, cancellations, or changes after export, the list may be out of date. Therefore, the plan needs to say who authorizes its use, when it comes into effect and how records made manually will be reconciled in the system afterwards.
In events with sensitive data, protect the physical list or local file. Do not leave copies circulating unchecked and dispose of material properly after reconciliation.
Test devices, accounts and staff before opening the door
The most useful test is operational. Use the same devices planned for the event, open the account with the correct permissions, load the base, test reading, manual search, operation with multiple devices and offline behavior when this function is part of the contingency.
Current documentation from check-in platforms recommend downloading and testing the app before the event, opening the event on each device, practicing reading and preparing battery and connectivity. This seems basic, but it prevents the first real attempt from happening with the queue already formed.
It's also worth testing your physical position. A reception can have four devices and function as two stations if people pass each other, if there is no space for the guest to leave after confirmation or if the exceptions queue blocks normal entry. The flow must have a visible entrance, service and exit.
Define roles before defining number of people
Counting "four people at the front desk" doesn't tell you the capacity if they all do the same thing or if no one has the authority to resolve exceptions. Turn team into roles.
In normal positions, the objective is to receive, validate and release. In support, someone organizes the queue's approach, instructs the guest to leave the QR open and directs special cases before they reach the scanner. At the point of exceptions, a person with more access and knowledge resolves disagreements. A person responsible for the operation monitors the queue, redistributes the team and decides when to activate reserve resources.
This division can be accumulated into smaller events. The important thing is that responsibility exists. When the queue grows, it shouldn't be necessary to find out at that moment who can open an extra station, change a device or authorize a solution.
Use the queue as an indicator during operation
Planning doesn't end when the doors open. Observe whether the queue is growing, stable or decreasing. A short, temporary queue may be normal during a rush. The sign of a problem is when more people enter the queue than leave for several minutes.
If this happens, the cause needs to be identified quickly. It could be demand above the scenario, a station stopped, service time longer than expected or excessive exceptions on the main line. The answer changes depending on the cause: opening an additional station, moving an attendant, removing exceptions from the queue, simplifying a step or better guiding guests before they reach the scanner.
Simple monitoring helps. Recording opening times, approximate queue size at intervals and number of active stations creates history for the next edition. The next event no longer depends on guesswork.
Reception opening checklist
The guest base is updated
Confirm the last update time, whether new registrations can still occur, and whether all ticket types that are expected to enter appear on the correct devices.
All devices can open the event
Check login, permissions, camera, battery, chargers or external batteries, and connectivity. If there is offline mode, load the data first and do a real test without a network.
QR was tested from start to finish
Use test tickets or controlled records to validate reading, confirmation and possible undoing of check-in. The team needs to recognize success messages, already used ticket and invalid code.
Manual search has been tested
Everyone should know how to locate a person without a QR code, what data to use to confirm registration and when to forward the case to exceptions.
The exception flow is physically defined
Indicate where there are cases of missing name, divergent companion, unavailable QR and other pending issues. The guest must leave the main line without losing service.
The contingency plan is accessible
The team must know what to do if the internet goes down, if a device stops, if the account does not open or if the application becomes unavailable. If there is an offline or printed list, it must be protected, updated at the defined time and under the responsibility of one person.
There is reserve capacity
Define in advance which device, person or position will be activated if the peak exceeds what is expected. A reserve resource decided in advance is much faster than improvising when the queue has already blocked the entrance.
The best dimensioning is the one you can explain with numbers
A well-designed check-in operation does not need a fixed rule like "one scanner for every X guests". It needs to answer four questions: how many people can arrive in the critical window, how long the normal flow actually takes, how many stations are needed to overcome this demand with a margin and what happens when a service is no longer normal.
With these answers, the QR Code stops being the center of planning and starts to occupy the correct role: a validation tool within a reception process. The result is a more predictable input, a team that knows when to escalate issues, and a plan B that already exists before the first failure.
