Public Event Registration Kiosk Requirements in Singapore

Start with the public event operating model

A public event registration kiosk should be specified around the attendee journey, not a hardware catalogue. Before comparing devices or software, define who will use the kiosk, what they need to accomplish and what happens when the expected journey fails.

Public events may serve invited guests, walk-ins, families, tourists, volunteers, vendors or participants with limited digital confidence. Their registration records may also arrive from multiple channels. These factors affect screen design, identity matching, language needs, staffing and queue capacity.

Document the intended journey from arrival to admission. State whether attendees will retrieve an existing registration, register on site, update details, accept event terms, select a session, make a permitted payment or collect a badge. Each additional step introduces dependencies and possible failure points.

Functional requirements

Write every functional requirement as an observable user outcome. Avoid broad statements such as “easy to use” unless the brief defines how usability will be assessed.

• Record retrieval: State which identifiers may be used, such as a QR code, booking reference, mobile number or email address. Define how ambiguous and missing records are handled.
• Walk-in registration: List the required fields, optional fields, consent wording, validation rules and completion confirmation.
• Duplicate handling: Define whether the kiosk warns the attendee, merges records, blocks another check-in or routes the case to staff.
• Admission status: Specify the statuses that may permit, delay or refuse entry, together with the staff escalation path.
• Badge coordination: If badges are required, define the data printed, templates, stock, reprint permissions and response to printer or consumable failure.
• Completion feedback: Require an unambiguous success screen and instructions directing the attendee to the next location.
• Staff controls: Define which actions require authorised staff access, including overrides, reprints, record corrections and device closure.

Get Out! Events can scope registration operations, guest communications, check-in, badge coordination, queue planning and wider event delivery. Where a tailored technical workflow is required, GO Labs can assess and deliver it according to the agreed brief and selected tools.

Non-functional and environmental requirements

The kiosk must work in the actual venue, not only during a desk demonstration. Record expected opening hours, attendance pattern, peak arrival windows, indoor or outdoor placement, available floor area, lighting, noise, heat exposure and access to power or connectivity.

Set requirements for screen readability, input responsiveness, physical stability, cable protection and recovery after interruption. If the event cannot depend on continuous connectivity, ask suppliers to explain what functions remain available offline, how records are reconciled and which risks remain. Offline behaviour will depend on the selected platform and integration design.

Define performance through testable thresholds agreed during procurement. Useful measures include the maximum time to retrieve a valid record, complete a standard check-in, print a badge and restore service after a controlled restart. Base targets on the event journey and expected arrival rate rather than adopting arbitrary figures.

Accessibility and assisted service

Public access requires more than a visually polished interface. Consider approach space, screen height, reach, glare, text size, contrast, touch-target size, plain language and sufficient time to complete each step. Audio instructions, alternative input methods or multilingual content may be relevant to the intended audience.

Not every attendee will be able or willing to use a self-service kiosk. Include an equivalent assisted route and ensure signs make it easy to find. Staff should know how to help without unnecessarily exposing personal information on the screen. Accessibility requirements should be reviewed against the venue, audience and applicable guidance; specialist or legal advice may be appropriate for the final specification.

Data, privacy and integration dependencies

Identify the system that holds the authoritative registration record and when data must move between systems. List required fields, identifiers, status mappings, update frequency, reconciliation rules and ownership of each interface. If badges, access control, payments or session bookings are involved, document those dependencies separately.

Keep the kiosk display and printed output limited to information required for the agreed journey. The brief should address screen reset, unattended sessions, staff permissions, retention, deletion, support access and incident escalation. Appropriate controls depend on the implementation and the organisation’s obligations. Procurement teams should obtain privacy and legal review where needed rather than treating a kiosk feature list as compliance advice.

Queue and operational requirements

Estimate demand by interval, not only total attendance. A kiosk that handles normal flow may still fail during an opening surge. Model the expected arrival profile, average transaction time, exception rate and number of stations. Then define space for queues, priority access, bag handling and movement towards the next checkpoint.

Assign named operational roles for opening checks, attendee assistance, exception handling, consumable replacement, technical escalation and closing reconciliation. The plan should also identify spare equipment or an alternative process appropriate to the event’s risk level.

For the next delivery stage, see the public event registration kiosk implementation guide. Requirements for controlled delegate environments may differ from this public-event scope; the conference kiosk requirements guide addresses that context.

Acceptance criteria and test cases

Acceptance testing should use realistic records, venue conditions and staff roles. Record expected results before testing so that approval does not depend on subjective impressions.

1. Valid pre-registration: Scan or enter an accepted identifier, retrieve the correct record, complete check-in and confirm any connected output.
2. Unknown attendee: Submit an identifier with no match and verify that the message and assisted route are clear.
3. Duplicate attempt: Try checking in the same record twice and confirm the agreed warning or staff workflow.
4. Walk-in journey: Complete all required fields, trigger validation errors and verify that corrections do not erase valid entries.
5. Accessibility review: Test approach, reach, readability, timing and assisted alternatives with representative users where practicable.
6. Connection interruption: Remove connectivity in a controlled test and verify the documented behaviour, recovery and reconciliation process.
7. Printer exception: Simulate low stock, a jam or unavailable printer and confirm the attendee and staff instructions.
8. Peak flow: Run concurrent journeys at the planned load and observe transaction times, queues and staff intervention.
9. Session reset: Abandon a journey and confirm that personal information clears within the agreed period.
10. Closing reconciliation: Compare completed transactions, exceptions and source records, then document discrepancies.

Requirements checklist for procurement

• Audience groups, arrival profile and venue constraints are documented.
• Pre-registered, walk-in, duplicate and exception journeys are mapped.
• Required data fields, validation, consent and status rules are approved.
• System integrations, owners and reconciliation rules are identified.
• Accessibility requirements and an assisted-service route are included.
• Performance criteria are measurable and linked to expected demand.
• Power, connectivity, placement, signage and queue space are confirmed.
• Badge stock, printers and reprint controls are specified where relevant.
• Staff roles, escalation contacts and fallback procedures are assigned.
• Privacy, retention and access-control questions have appropriate review.
• Acceptance tests, test data and approval responsibilities are agreed.
• Setup, live operation, shutdown and post-event reporting are in scope.

A strong kiosk specification describes successful journeys, predictable exceptions and the people responsible for resolving them.