Conference Virtual Name Card Requirements in Singapore

Start with the intended exchange journey

A conference virtual name card should make professional introductions easier without creating uncertainty about data, consent or follow-up. Begin by describing the journey rather than naming a platform. State who receives a card, when it becomes available, how it is shared and what the recipient can do next.

Common journeys include an attendee presenting a QR code, opening another participant’s card from an event directory, exchanging details after a session or saving a contact from a digital event passport. Each route creates different requirements for authentication, connectivity, permissions and user support.

Separate mandatory journeys from desirable enhancements. This helps Get Out! and the GO Labs team scope an appropriate solution around the agreed brief and selected tools, without treating every possible feature as essential.

Functional requirements to define

Card creation and profile data

List every permitted field and identify whether it is mandatory, optional or hidden by default. Typical fields may include name, organisation, job title, email address, telephone number, professional profile link and a short biography. Avoid collecting information merely because a template can accommodate it.

• Define whether attendees create their own cards or organisers import approved records.
• Specify who can edit each field and when changes stop being accepted.
• Set rules for incomplete, duplicated or invalid records.
• Confirm whether a downloadable contact file is required.
• Define how withdrawn or cancelled attendees are handled.

Sharing and receiving

The brief should specify every supported sharing method, such as a personal QR code, an authenticated directory or a link delivered through event communications. State whether the recipient must sign in and whether the sender can choose which details to disclose.

If QR codes appear on badges, screens or mobile devices, define the expected scanning distance, physical dimensions, contrast and fallback route. Badge coordination should account for late registrations, replacement badges and profile changes after printing. For related identity-display considerations, review the name display system requirements.

Contact actions and follow-up

Specify what happens after a successful exchange. A recipient might view the card, save a contact, open an approved link or record a note. If either party receives a follow-up message, document its trigger, sender identity, timing and unsubscribe or preference route where applicable.

Do not assume that viewing a card automatically permits unrelated marketing. Intended uses, notices and consent mechanisms should be reviewed for the event’s circumstances. Organisers should obtain appropriate privacy or legal advice where needed.

Dependencies that affect delivery

A virtual name card rarely operates alone. Map its dependencies before approving the build. These may include the RSVP database, registration workflow, badge production, identity provider, email delivery, venue connectivity and post-event data handling.

• Source of truth: Identify the authoritative attendee record and how updates propagate.
• Identity matching: Define the stable identifier used across registration, badges and cards.
• Access control: Decide who can discover or open attendee profiles.
• Connectivity: Document degraded-network behaviour and any practical fallback.
• Operations: Assign responsibility for approvals, corrections and attendee support.

If cards depend on an attendee account or event website, align them with the conference RSVP website requirements and conference registration system requirements. A card used within a broader participation journey may also need alignment with a conference digital event passport.

Accessibility and inclusive use

Accessibility requirements should cover the complete task, not only the profile screen. Attendees must be able to open, understand, share and save details using supported devices and assistive technologies. Define the required standard or organisational policy in the brief rather than relying on a general promise of accessibility.

• Use meaningful labels and a logical reading and focus order.
• Provide keyboard-operable controls and visible focus states where relevant.
• Do not communicate status, errors or required fields through colour alone.
• Set minimum text, contrast and touch-target expectations.
• Provide text alternatives for meaningful visual content.
• Offer an assisted route for attendees who cannot use the digital journey.

Include accessibility checks with real content, long names, multiple languages where required and common mobile viewport sizes. Any claimed outcome remains dependent on implementation, content and the agreed test scope.

Write measurable acceptance criteria

Acceptance criteria should describe observable results. Replace “easy to use” with a testable condition such as: an authenticated attendee can display their personal QR code from the supported mobile journey within the agreed number of steps. Replace “updates quickly” with a defined synchronisation window and an agreed method for measuring it.

Useful criteria cover permissions, data accuracy, supported browsers and devices, failure messages, loading behaviour, contact export, analytics boundaries and administrative workflows. Include the test data, expected result, responsible approver and evidence required for sign-off.

Minimum test cases

1. Create a complete profile and verify every field against the source record.
2. Submit missing, malformed and overlength values and confirm useful error handling.
3. Change an approved field and verify the update across all relevant touchpoints.
4. Scan each QR presentation format on the agreed device and browser matrix.
5. Attempt access as an authorised attendee, unauthorised user and signed-out visitor.
6. Save the contact and verify field mapping in the supported destination.
7. Test duplicate names, replacement badges, cancellations and withdrawn sharing consent.
8. Repeat key journeys with keyboard navigation, screen-reader checks and enlarged text.
9. Simulate slow or interrupted connectivity and confirm the defined fallback behaviour.
10. Verify administrative logs, retention actions or reporting only where included in scope.

Requirements checklist for procurement

• Purpose, user groups and exchange moments are documented.
• Mandatory fields and prohibited data are approved.
• Card ownership, editing rights and publishing rules are defined.
• Sharing, authentication and recipient actions are specified.
• Privacy notices, consent points and retention responsibilities are assigned.
• RSVP, registration, badge and communications dependencies are mapped.
• Accessibility requirements and assisted alternatives are included.
• Supported devices, browsers and venue conditions are recorded.
• Acceptance criteria, test cases and sign-off owners are named.
• Event-day support, escalation and fallback procedures are agreed.

A strong brief lets buyers compare proposals on the same operational basis. It also helps Get Out! scope planning, attendee communications, registration operations, badge coordination, testing and wider event delivery around the conference’s actual needs. Technical behaviour should be confirmed during discovery and documented against the tools ultimately selected.