Exhibition Digital Event Passport Requirements in Singapore

Start with the passport’s operational purpose

An exhibition digital event passport should support a defined visitor journey, not exist as a novelty. Before discussing interfaces or scanning methods, establish the outcome: encouraging discovery across halls, recording attendance at selected booths, completing educational activities, managing reward eligibility or helping visitors organise their experience.

State which outcomes are essential and which are optional. A passport designed for exploration has different rules from one used to verify completion of compulsory sessions. The requirement should also explain whether participation is open to every attendee, restricted by ticket type or available only during particular exhibition hours.

For a broader explanation of the format, see the exhibition digital event passport guide. The requirements below focus on specifying and accepting an exhibition implementation in Singapore.

Define users, roles and access paths

List every user group that touches the journey: visitors, exhibitors, roaming ambassadors, registration staff, helpdesk personnel, operations managers and authorised administrators. Each group needs an explicit role rather than general access.

• Visitors: access their passport, view tasks, submit or validate activity and understand completion status.
• Exhibitors: validate eligible interactions without seeing unnecessary visitor information.
• Operations staff: resolve exceptions, record approved overrides and monitor issues.
• Administrators: configure content, schedules, locations and access permissions within the agreed toolset.

Specify whether visitors enter through pre-event registration, an emailed link, a QR code, an on-site check-in flow or another approved route. Avoid assuming every attendee will download an app or use the same device.

Write functional requirements as observable actions

Requirements should describe what a user can complete and what the system should return. Avoid vague statements such as “easy gamification” or “seamless engagement.” Useful functional requirements may include:

1. A visitor can open the passport using the agreed access method.
2. The passport displays eligible activities, locations, availability periods and completion rules.
3. An authorised action records a valid completion once, unless repeat participation is intentionally permitted.
4. The visitor receives clear confirmation or a useful error message after each attempt.
5. Progress reflects validated activity according to the agreed rule set.
6. Staff can follow a documented exception process for inaccessible, closed or technically unavailable stations.

If rewards are involved, define eligibility, redemption periods, stock dependencies and the authority permitted to approve exceptions. The passport should not imply that a reward is available when fulfilment depends on limited physical inventory.

Set measurable acceptance criteria

Every critical requirement needs a pass condition. For example, “completion status updates within the response time agreed for the selected setup” is testable; “updates instantly” is not sufficiently precise. Acceptance criteria should cover successful actions, rejected actions and recovery paths.

• Valid activities are credited only during configured dates and times.
• Duplicate submissions follow the specified rule without adding unintended progress.
• Expired, malformed or ineligible codes return an understandable message.
• Closed stations can be hidden, marked unavailable or handled through an approved alternative.
• Staff overrides require the agreed permission and produce an appropriate operational record where supported.
• Completion and reward messages match the approved eligibility logic.

Technical outcomes remain dependent on the final brief, integrations, venue conditions and selected tools. Acceptance criteria should reflect those constraints rather than promise performance independently of them.

Map dependencies before production

A passport journey may depend on registration data, ticket categories, exhibitor lists, floor plans, activity copy, QR production, connectivity, staffing and reward operations. Name an owner and deadline for each dependency. Late booth changes or unapproved activity rules can affect configuration and testing even when the underlying platform is ready.

Confirm who supplies visitor identifiers, whether integration is required and what fallback applies if an upstream service is unavailable. If passport actions may create queues at popular booths, coordinate throughput and staffing with the exhibition’s digital queue management requirements.

Include accessibility and assisted participation

Accessibility should be part of the core brief. Require readable contrast, meaningful labels, clear status messages, usable text sizing and interaction targets appropriate for mobile use. Essential instructions should not depend only on colour, sound or animation. Check whether the selected experience can be navigated with common assistive technologies and whether time-limited actions provide a reasonable alternative.

Plan an assisted route for visitors who cannot scan a code, use a personal device, reach a physical marker or complete a standard interaction. Staff need a consistent method for validating an equivalent activity without publicly exposing disability or personal information.

Specify privacy and data handling boundaries

Document the minimum information needed for access, progress, support and reporting. Decide whether the passport requires an identified attendee or can operate using a limited event identifier. Define authorised recipients, retention expectations, deletion processes and any approved data exports with the relevant stakeholders.

Where personal data is processed, organisers should obtain appropriate privacy and legal guidance for their circumstances, including applicable Singapore requirements. Do not collect optional profile data merely because a tool can capture it. Consent language, notices and exhibitor access should match the actual configured flow.

Build a realistic test plan

Testing should use representative devices, user roles and venue conditions. Include positive, negative and operational cases:

• First-time access through every published entry point.
• Valid, duplicate, expired and unauthorised completion attempts.
• Loss and restoration of connectivity during an activity.
• Incorrect device time, browser refresh and interrupted sessions.
• Changes to booth availability after the passport has opened.
• Assisted completion and authorised staff override paths.
• Completion at the exact boundaries of configured operating hours.
• Reward eligibility when physical stock is unavailable.

Run a venue rehearsal with actual placement, lighting and expected staff roles where practicable. A code that works in an office may still be difficult to locate or scan on a crowded exhibition floor.

Use a procurement-ready requirements checklist

• Purpose, audiences and success measures are approved.
• User roles and permissions are defined.
• Entry, activity, completion and exit journeys are mapped.
• Validation, duplicate and timing rules are documented.
• Content, language and accessibility requirements are agreed.
• Registration, venue, connectivity and hardware dependencies have owners.
• Privacy boundaries and reporting needs are reviewed.
• Fallbacks cover unavailable stations, devices and connectivity.
• Acceptance criteria and test cases are signed off.
• Training, support, escalation and event-day responsibilities are assigned.

Get Out! Events can scope and manage the visitor journey, guest communications, registration operations, check-in, badge coordination, queue planning and wider exhibition delivery. Through GO Labs, relevant digital passport components can be evaluated against the agreed requirements. The appropriate implementation depends on the event brief, operating environment, integrations and selected tools.