Festival Digital Event Passport Requirements in Singapore

A festival digital event passport gives participants a structured way to complete activities, visit zones or collect verified achievements through a mobile experience. Before choosing a platform or development approach, organisers should document exactly how the passport must behave across the participant journey and live operating environment.

This guide focuses on requirements for Singapore festivals rather than presenting a generic technology overview. Get Out! Events can scope the participant journey, operating procedures and delivery requirements, while GO Labs can assess suitable digital implementation options. Features and technical outcomes remain subject to the agreed brief, venue conditions, integrations and selected tools. For a broader service introduction, see the festival digital event passport overview.

1. Define the passport’s purpose and boundaries

Start with the behaviour the passport is intended to encourage. A food festival might guide visitors across participating stalls, while an arts festival might connect performances, installations and workshops. The requirement should describe the desired journey without assuming that every activity needs the same verification method.

• Audience: State who can participate, including age restrictions or ticket-holder conditions.
• Participation window: Define opening dates, daily operating hours and any completion deadline.
• Completion rule: Specify whether participants need every checkpoint, a minimum number or selected categories.
• Reward rule: Record eligibility, redemption limits, stock constraints and what happens when rewards run out.
• Exclusions: Identify activities, venues or participant groups outside the passport scope.

2. Document functional requirements

Functional requirements should describe observable user and operator actions. Avoid vague statements such as “easy to use” or “supports gamification”. Write requirements that can be demonstrated and tested.

Participant functions

• Participants can enter the passport through the approved access method, such as a campaign link or QR code.
• Participants can understand the activity rules before providing information or beginning the journey.
• Participants can view available checkpoints, completion status and remaining requirements.
• A valid checkpoint action updates the correct participant record once.
• Invalid, expired or repeated actions return a clear response without incorrectly adding progress.
• Participants can recover or resume their progress according to the agreed identity and session model.

Operator functions

• Authorised staff can verify or support checkpoint completion through the selected process.
• Organisers can distinguish successful, incomplete and disputed journeys where the agreed tools permit it.
• Checkpoint teams receive instructions for exceptions, device failure and participant assistance.
• Reward staff can verify eligibility and record redemption without relying on screenshots alone, if live verification is required.

3. Set measurable acceptance criteria

Each critical requirement needs a pass condition. Acceptance criteria should cover the interface and the live operation around it. Example criteria include:

1. A first-time participant can reach the passport instructions from the published entry point and identify the completion rule.
2. Scanning or entering a valid checkpoint reference records the intended checkpoint and displays updated progress.
3. Submitting the same checkpoint again does not create a second completion where duplicates are prohibited.
4. An ineligible redemption attempt is rejected with an understandable next step for both participant and staff.
5. Progress remains available after an agreed interruption, such as closing and reopening the browser, where persistence is in scope.
6. Operational staff can follow a documented fallback when connectivity or checkpoint equipment is unavailable.

Performance thresholds, device coverage and recovery behaviour should be agreed during scoping. They should not be assumed from a prototype or supplier demonstration.

4. Identify dependencies early

A digital passport often depends on decisions owned by several parties. Delayed inputs can affect configuration, testing and launch readiness even when the core experience is straightforward.

• Festival map and programme: Final locations, opening times and activity changes influence checkpoint logic.
• Venue connectivity: Test actual participant and staff network conditions at busy locations.
• Ticketing or identity: Confirm whether anonymous participation, email, mobile number or ticket-linked access is appropriate.
• Checkpoint materials: Allocate ownership for codes, signs, placement, replacement and tamper checks.
• Rewards: Confirm quantities, eligibility wording, fulfilment process and escalation authority.
• Content: Approve instructions, error messages, accessibility copy and multilingual requirements.
• Data handling: Define necessary fields, access roles, retention expectations and any required notices with appropriate advisers.

5. Include accessibility requirements

Accessibility must cover the complete journey, not only the digital interface. Requirements may include readable text, sufficient contrast, meaningful control labels, keyboard operation where relevant, clear error messages and instructions that do not rely on colour alone. Selected tools should be assessed against the agreed accessibility scope.

Provide an equivalent assisted route for participants who cannot scan a code, use a particular device or navigate a physical checkpoint. Staff should know how to offer support without publicly exposing personal information or creating a substantially harder completion path.

6. Plan privacy and operational controls

Collect only information justified by the operating purpose. Document who can access participant and redemption records, how corrections are handled, and when records are no longer required. Consent wording, notices and retention decisions should be reviewed for the actual campaign and applicable obligations; this guide is not legal advice.

Operational controls may include role-based staff access, controlled checkpoint references, incident logging and a defined method for disabling compromised materials. The exact controls will depend on risk, scale and the capabilities of the selected implementation.

7. Build a realistic test pack

Testing should reproduce festival conditions rather than cover only the ideal journey. Run tests on agreed mobile devices and browsers, at the venue where possible, with staff performing their actual roles.

• New participant completes the standard journey.
• Participant submits checkpoints in an unexpected order.
• Participant scans an invalid, duplicate, damaged or expired reference.
• Connectivity drops before or after a checkpoint action.
• Two participants attempt the same activity on one device.
• Checkpoint staff use the fallback and escalation procedures.
• Reward staff handle eligible, ineligible and previously redeemed records.
• A participant uses the agreed accessible or assisted route.
• A programme or checkpoint change is published during operations.
• The event closes and late completion attempts receive the intended response.

Requirements checklist for buyers

• Journey: Purpose, audience, checkpoints, sequence and completion rules approved.
• Access: Entry, identity, session recovery and device assumptions documented.
• Verification: Valid, invalid, duplicate and disputed actions defined.
• Operations: Staffing, training, signage, support and fallback owners assigned.
• Rewards: Eligibility, inventory, redemption and exception rules confirmed.
• Accessibility: Interface requirements and equivalent assisted routes included.
• Data: Required fields, access, notices, retention and correction processes reviewed.
• Testing: Acceptance criteria, devices, venue conditions and incident scenarios covered.
• Launch: Content freeze, readiness review, escalation contacts and closure process scheduled.

A strong requirements brief lets buyers compare options against the same operating standard. It also exposes dependencies before they become live-event problems. Scope the participant journey, staff workflow and exception handling together, then select and configure tools only after the acceptance criteria are clear.