Exhibition Custom Event App Requirements in Singapore

Start with exhibition outcomes, not a feature catalogue

An exhibition app should solve defined operational problems. Before listing screens or integrations, document who will use the app, what each group needs to accomplish and where those actions fit within the event journey. Typical audiences include visitors, exhibitors, organisers, speakers, sponsors and on-site operations teams.

For each audience, identify the critical tasks before, during and after the exhibition. A visitor may need to register, find exhibitors, save sessions and receive schedule updates. An exhibitor may need to maintain a profile, manage representatives or receive qualified enquiries. Organisers may need content controls, communication workflows and operational visibility. The required solution depends on the agreed brief, selected tools and available data.

If you are still defining the broader solution, review the exhibition custom event app planning guide before converting the concept into requirements.

Define the functional requirements

Visitor access and identity

Specify how users enter the app and how identity is established. Options may include email links, access codes, account credentials or a connection to an existing registration process. State whether anonymous browsing is permitted, which functions require authentication and how duplicate or changed records should be handled.

• Acceptance criterion: An eligible test visitor can access the correct event experience using the approved identity flow.
• Dependency: Registration data fields, unique identifiers and update frequency are agreed before integration work begins.
• Test case: Attempt access with valid, invalid, duplicate and amended registration records.

Exhibitor discovery and floor navigation

Define the information visitors need when evaluating exhibitors. Requirements can include searchable listings, categories, booth numbers, saved exhibitors and floor-plan references. Clarify who supplies each field, who approves it and when content becomes final. If interactive mapping is requested, document the required devices, location accuracy, venue inputs and fallback behaviour rather than assuming navigation will work like an outdoor map.

• Acceptance criterion: A visitor can find a named exhibitor by an approved search term and identify its assigned booth.
• Dependency: The organiser provides a controlled exhibitor list and final booth allocations in the agreed format.
• Test case: Search using full names, partial names, categories, punctuation variants and a listing that has recently changed.

Agenda, sessions and personal schedules

State whether the app presents a simple programme or supports personalised schedules, capacity controls, reminders or session access rules. Define the source of agenda data and how late programme changes are published. If a saved schedule does not reserve a seat, say so clearly within the experience.

• Acceptance criterion: Published session changes appear in the expected location within the agreed update window.
• Dependency: Session identifiers, rooms, speakers and publishing authority remain consistent across source systems.
• Test case: Change a session time, cancel a session and create a scheduling conflict.

Notifications and guest communications

Separate operational messages from promotional communications. Define the permitted channels, audience selection, approval process, scheduling rules and treatment of urgent changes. Requirements should also address failed delivery, outdated contact details and users who cannot or do not enable device notifications.

Get Out! can plan guest communications alongside RSVP, registration, check-in and wider event delivery. Exact communication and consent controls should be confirmed against the chosen tools, organisational policies and applicable requirements; this guide is not legal advice.

Document non-functional requirements

Performance and resilience

Set realistic service expectations using event conditions rather than broad terms such as “fast” or “scalable”. Record expected registered users, likely concurrent activity, peak moments, supported devices and venue connectivity constraints. Identify which functions must remain useful during weak connectivity and what users should see when a service or integration is unavailable.

Acceptance testing should use representative content volumes and devices. It should cover first load, repeated use, search, schedule updates and peak communication scenarios. Any offline or synchronisation outcome remains conditional on the agreed architecture and selected platform.

Accessibility and inclusive use

Accessibility requirements should be included at the start, not added during final review. Specify keyboard operation where relevant, meaningful labels, readable contrast, visible focus, text resizing, captions or transcripts for media, clear error messages and alternatives to colour-only instructions. Include users with different devices, input methods and levels of digital confidence in testing.

• Acceptance criterion: Core journeys can be completed using the agreed accessibility test methods without losing essential information.
• Test case: Navigate access, exhibitor search and schedule saving using a keyboard and screen-reader review.
• Operational fallback: Provide a staffed or non-app route for essential event access when a visitor cannot use the app.

Privacy, permissions and retention

Create a data inventory covering information collected, its source, intended use, access roles, transfer points and proposed retention. Define permissions separately for organisers, exhibitors, support teams and visitors. Avoid requesting personal information simply because a tool supports the field. Legal and privacy positions should be reviewed by appropriately qualified advisers.

Map dependencies before approving scope

Most delivery risks sit between systems and teams. Record every dependency with an owner, due date, input format and consequence of delay. Common examples include registration exports, exhibitor content, floor plans, agenda approval, brand assets, domain configuration, app-store processes, venue connectivity and stakeholder review availability.

For integrations, define the system of record, matching key, direction of data flow, update frequency, error handling and reconciliation process. A requirement such as “integrate registration” is incomplete until those decisions are documented.

Build an acceptance test plan

Every priority requirement should have a test that produces a clear pass or fail result. Use realistic user roles and data, including exceptions. Assign responsibility for preparing test records, executing tests, fixing defects and approving release. Distinguish defects that block launch from issues that can enter a controlled post-launch list.

1. Test a new visitor from registration through first app access.
2. Test amended, cancelled and duplicate visitor records.
3. Verify exhibitor search, categories, booth references and unpublished entries.
4. Verify agenda changes, conflicts, time zones and cancellation messaging.
5. Review permissions using visitor, exhibitor, editor and administrator roles.
6. Test supported devices and constrained venue connectivity.
7. Complete accessibility checks on every core journey.
8. Rehearse support escalation, content correction and launch rollback decisions.

Requirements checklist for buyers

• Named user groups and their essential exhibition journeys
• Prioritised functional requirements with exclusions
• Measurable acceptance criteria for each launch-critical item
• Data sources, identifiers, owners and update rules
• Supported devices, browsers and connectivity assumptions
• Accessibility criteria and assisted alternatives
• Permission roles, privacy review and retention decisions
• Content ownership, approval deadlines and change control
• Integration failure and reconciliation procedures
• Testing environments, representative data and sign-off authority
• On-site support, escalation and operational fallback plans
• Post-event access, exports and closure responsibilities

Use the requirements to compare delivery options

Issue the same prioritised brief to every shortlisted provider. Ask each party to identify what is standard, configurable, custom, dependent on another supplier or outside scope. Request evidence through scenario-based demonstrations rather than accepting feature-list confirmations. Differences should be recorded as assumptions, exceptions or proposed changes.

Get Out! can scope exhibition app requirements and coordinate relevant delivery through GO Labs, with technical outcomes tied to the approved brief and selected tools. For procurement questions beyond requirements definition, use the Singapore exhibition app vendor selection guide.