Plan event check-in with clear ticket categories, QR scanning, supervisor lookup and wristband issuing. A practical guide for Nigerian organisers.
A practical event check-in plan for Nigerian organisers
Your entrance is where the event promise meets the guest experience. Someone has travelled across Lagos, paid for a ticket and reached the venue. They expect staff to find their booking, confirm their category and direct them to the right place. A clear check-in process gives your team a consistent way to handle those steps, including the cases which do not go to plan.
Buying scanning equipment is not the starting point. First agree who is eligible to enter, which session their ticket covers and who resolves exceptions. Then choose tools which support those decisions. A scanner should help staff apply the rules, rather than leave them guessing what a green screen means.
Separate entry checks from wider event safety
Ticket validation answers whether a person has an eligible admission. It does not establish whether the venue is safe, whether an entrance layout is suitable or whether a crowd response plan is adequate. Those responsibilities need separate planning with the venue and appropriately qualified event personnel.
For check-in, focus on a manageable sequence: identify the event and session, validate the ticket, record the admission and direct the guest. Keep a help point away from the main scanning position so a difficult booking does not stop every other arrival. The exact layout needs to suit the venue rather than follow a generic diagram.
Make ticket categories match the door instructions
If your checkout sells Regular, VIP and VVIP, those names should appear on the attendee record, ticket, wristband plan and staff briefing. Avoid selling one label online and using a different label at the entrance. Guests should not need to explain how the categories relate.
Date matters as much as category. A ticket for Saturday should not be accepted on Sunday simply because both sessions share the event name. Where there are multi-day passes, define which sessions each pass covers and how repeat entry is recorded. State the re-entry policy before tickets go on sale.
Give each admission its own record
One buyer purchasing five places needs five independently checkable admissions. A single order reference is useful for customer support, but it should not force staff to admit all five people together. Record the holder information required by your event policy and explain whether guests must arrive as a group.
The system should keep payment status separate from attendance status. A booking being found in a list does not by itself prove payment completed. Likewise, a payment confirmation does not prove the person has not already entered. Staff need the relevant status for the individual admission they are checking.
Use QR scanning as a check against the record
A QR image stores information. In a ticketing workflow, the important step is the server checking the corresponding ticket and recording admission. HighLevel's native event documentation illustrates this distinction through scanning, manual admission and an already-checked-in result. The same principle should guide whichever platform your event uses.
Brief agents to wait for a confirmed result. The first scan should not be accepted merely because the camera recognised an image. An unknown code, a wrong-session ticket and a ticket already admitted need different responses. Keep the screen wording clear enough for staff to act without interpretation.
Set up a supervisor route for exceptions
Some guests will have a flat phone battery, an inaccessible email or a QR code which is difficult to read. Give authorised supervisors a private search by name, email, phone or ticket reference. The supervisor should select the correct individual admission, check its eligibility and record manual admission through the same database process used by the scanner.
This shared record is essential. If manual admission lives in a separate spreadsheet, another agent might still accept the QR ticket. Record the supervisor, time and reason for the manual action. Do not let a support conversation become permission to change payment status without verification.
Plan for a weak connection
If an agent's phone loses connectivity while a supervisor remains online, move that guest to the supervisor's connected device. If every device is offline, current cloud records are unavailable. A downloaded list might help identify a booking, but it cannot reliably reveal an admission made by another disconnected phone.
For an online-only setup, show a pending connection result rather than confirmed admission. Prepare a tested alternative connection and device charging arrangements. If you require offline admission, select and test a system designed for it, including how it resolves duplicate use across devices. Staying on a web page does not automatically provide offline synchronisation.
Fit wristbands after validation
Where bands identify entry categories, staff should validate the ticket and record admission before fitting the band. Keep category stock organised and avoid leaving unused bands where anyone might collect them. A wristband buying guide helps connect your material and print choices with this process.
Before doors open, test a valid ticket, a used ticket, a wrong-date ticket and a manual lookup. Have two phones attempt the same admission and confirm the result. Finish the briefing with a clear escalation contact. Use the resources area alongside your event checklist, and review your event setup before sharing the public link.
Editorial source register
Research checked 6 November 2026. This is operational planning guidance, not a venue safety assessment or legal compliance guide.
- HighLevel, in-person check-in: https://help.gohighlevel.com/support/solutions/articles/155000008294-check-in-experience-for-in-person-events . Supports the example of QR/manual check-in, wrong-event rejection and duplicate status. It does not establish the implementation of the proposed custom Seats & Tickets portal.
Publication check: verify the platform's delivered functions before adding claims about its scanner, offline mode or supervisor tools.

