Conference Registration Kiosk Requirements in Singapore

Start with the attendee journey, not the kiosk screen

A conference registration kiosk is one part of an on-site operating system. Its requirements should begin with what different attendees need to accomplish: locate a registration, confirm identity, correct permitted details, receive a badge or access instruction, and move into the event without unnecessary uncertainty.

Document each expected journey before evaluating hardware or interfaces. Common paths include pre-registered delegates, walk-ins, speakers, sponsors, exhibitors, group registrations and guests whose records require staff review. State which paths may use self-service and which must be directed to an assisted counter. This prevents an attractive kiosk concept from becoming an operational bottleneck.

If the project includes the broader registration platform, separate kiosk-specific requirements from the conference registration system requirements. The kiosk specification should describe the on-site interaction, while the system specification governs records, permissions and connected workflows.

Functional requirements

Define the minimum functions in observable terms. Depending on the agreed brief and selected tools, a kiosk may need to find an attendee by QR code, reference number or approved search fields; display a limited confirmation screen; record arrival status; and initiate badge production or direct the attendee to collection.

• Identity matching: Specify accepted identifiers, handling of duplicate records and the point at which staff verification is required.
• Record handling: State whether attendees can view or amend fields, which fields remain locked, and how changes are recorded.
• Check-in status: Define when arrival is committed, how repeat scans behave and whether operators can reverse an incorrect action.
• Badge workflow: Identify the badge template, print trigger, printer assignment, reprint permissions and treatment of failed or partial prints.
• Exceptions: Provide an assisted route for missing registrations, unpaid bookings, access restrictions, substitutions and other unresolved cases.

Keep promotional messaging secondary. The primary interaction should make the next action obvious and reduce the chance of an attendee abandoning the process midway.

Operational and physical requirements

Calculate the proposed kiosk quantity from the arrival pattern, expected transaction steps, service time assumptions and acceptable queue condition. Total attendance alone is not enough. A conference with a concentrated opening rush can require a different layout from one with staggered session arrivals.

Specify power availability, network coverage, equipment footprint, cable routing, printer placement, consumable storage and staff access. Confirm venue loading rules and setup windows. The layout should provide a clear approach, space to pause without obstructing circulation, and an obvious route from successful check-in to badge collection or entry.

Assign operational ownership as well. Name who replenishes badge stock, clears printer faults, handles attendee exceptions, monitors queues and authorises reprints. GO Labs can scope registration workflows and technical dependencies as part of wider event delivery, but responsibilities should still be explicit in the event plan.

Integration and data dependencies

A kiosk cannot be assessed independently of its source records. Document where the attendee data originates, how frequently it must update, which system controls the authoritative status and what happens when two channels change the same record. For projects involving wider connectivity, use a separate CRM integration requirements exercise rather than assuming that every kiosk requires direct CRM access.

List dependencies for QR codes, email delivery, badge templates, printer drivers, venue connectivity and user permissions. Guest communications should explain what attendees need to present and where they should go; those requirements can be coordinated with the conference email communications plan.

Privacy and retention decisions should reflect the organiser’s policies, applicable obligations and the selected technology. Limit on-screen exposure, avoid displaying unnecessary personal information, define operator access and establish an agreed process for temporary files or locally stored data. Obtain appropriate professional advice where legal interpretation is required.

Accessibility and assisted service

Accessibility requirements should cover the whole interaction, not only screen height. Consider approach space, reach, text size, contrast, plain instructions, touch-target size, response timing and whether audio or visual cues create barriers. Avoid relying on colour alone to communicate success or failure.

Provide an equivalent assisted path for anyone who cannot or does not wish to use self-service. Staff should be able to complete the necessary journey without publicly discussing sensitive details. Test the physical setup at its intended height and location rather than approving accessibility from interface mock-ups alone.

Acceptance criteria

Acceptance criteria turn the brief into a decision. Each criterion should include a scenario, input, expected result and evidence. Useful criteria may include:

• A valid QR code retrieves the correct eligible record and completes the approved check-in flow.
• An already checked-in code produces a clear response without creating a second arrival record or unintended badge.
• An unreadable code offers the approved alternative lookup or directs the attendee to assistance.
• A failed badge print can be identified and recovered by authorised staff without an uncontrolled duplicate.
• Restricted fields cannot be changed through the attendee-facing interface.
• A temporary connection interruption produces the agreed message and recovery behaviour.
• Screen content and attendee information are not unnecessarily exposed to the next person in line.

Words such as fast, seamless and reliable are not acceptance criteria unless the buyer supplies a measurable threshold and test conditions.

Test cases before event day

1. Happy path: Test every permitted attendee type from scan through badge collection.
2. Record exceptions: Try duplicates, incomplete profiles, cancelled records, name changes and records added after the initial data load.
3. Hardware faults: Remove badge stock, create a printer error, disconnect a scanner and restart a kiosk.
4. Connectivity: Test degraded or interrupted network conditions and confirm the documented fallback.
5. Volume: Run simultaneous check-ins with realistic badge printing rather than isolated screen demonstrations.
6. Recovery: Confirm that staff can resume service, reconcile uncertain transactions and escalate unresolved issues.
7. Accessibility: test the installed position with representative users and the assisted-service route.

Run an end-to-end rehearsal with production-like records, final badge artwork, actual devices and the intended venue network where possible. Record defects, owners and retest results.

Conference kiosk requirements checklist

• Attendee categories and permitted self-service journeys are listed.
• Peak arrival assumptions and queue ownership are documented.
• Lookup methods, duplicate handling and staff-verification rules are approved.
• Badge formats, printers, consumables and reprint controls are confirmed.
• Power, network, footprint, cabling and venue constraints are checked.
• Source data, update timing, permissions and system ownership are defined.
• Privacy, screen exposure and retention decisions are documented conditionally.
• Accessible operation and an equivalent assisted route are included.
• Fallback procedures have named owners and required materials.
• Acceptance tests cover normal, exception, failure and recovery scenarios.

For a wider purchasing decision covering registration beyond the kiosk, review the conference event registration system separately. A precise kiosk brief should remain focused on what must happen at the venue, how the setup will be supported and what evidence will demonstrate readiness.