Give each scanning team a clear entrance
Main and VIP entrances can require different admission rules. Scan profiles define accepted ticket types and assigned scanners, avoiding reliance on an informal list. A profile does not replace security or age checks; it supports validation of issued admission. Use recognisable names and brief the actual team on which profile to select before opening.
Use a recognisable profile name for the door team.
Choose all ticket types or a deliberate selection
A profile can accept all relevant types or a selected subset. Keep the subset aligned with ticket descriptions and conditions. A VIP label alone does not configure a separate entrance. The simulator shows a main entrance and VIP selection using fictional tickets. It saves no profile and changes no scanner assignments.
Test allowed and disallowed types at every profile.
A used ticket stays used at another entrance
Successful check-in marks a valid ticket as used. Switching profiles does not make it unused again. This prevents the same admission being reused at another entrance. In the demo, switch entrances after a successful scan and try again. Re-entry and separate sessions need explicit operational arrangements; they do not follow automatically from having multiple profiles.
Include a duplicate scan in the briefing and test run.
Handle exceptions outside the normal scan queue
Wrong profiles, used tickets and missing payments need different responses from valid scans. Assign someone to investigate rather than expecting scanners to alter ticket states themselves. Check connectivity, battery and event assignments before opening. Reset in this simulator only resets its local example ticket and never restores a real ticket.
Use individual accounts and a reachable escalation contact.