Keep Every Message Moving

Build contingency planning around the live message journey

A virtual event message wall can involve several connected steps: a participant submits content, the content reaches a review queue, a moderator approves or rejects it, and an approved message appears in the virtual programme or on a managed display. A disruption at any point can make the wall appear unresponsive even when other parts of the workflow remain available.

Contingency planning should therefore map the full journey rather than focus only on the final display. Get Out! Events can work with GO Labs to scope the operational workflow, selected tools, staffing arrangement and fallback procedures for a Singapore event. The appropriate controls depend on the agreed brief, programme format, venue or production environment, audience size and technical setup.

Begin by documenting what the wall must achieve, where participants will access it, who may submit messages, whether moderation is required and where approved content will appear. These decisions should align with the wider virtual event message wall requirements before technical and operational contingencies are finalised.

Assign clear live-operation roles

A concise responsibility plan helps the team act without debating ownership during the broadcast. Depending on event scale, one person may hold several roles, but each responsibility should still be explicit.

• Wall operator: monitors submissions, approvals and the visible output throughout the operating window.
• Content moderator: applies the agreed moderation rules and identifies messages that need escalation.
• Production liaison: coordinates with the streaming, show-calling or audiovisual team when the wall affects the live programme.
• Technical contact: investigates device, browser, network or integration issues within the boundaries of the selected tools.
• Decision owner: authorises major actions such as suspending submissions, switching to a fallback or removing the wall from the programme.

The run sheet should list contact methods, response order and authority limits. Avoid relying on a single chat channel that could be affected by the same connectivity problem as the wall. A secondary contact route may be appropriate for critical escalation.

Monitor signals that reveal problems early

Monitoring should cover participant experience, moderation flow and display output. Useful checks may include whether test submissions arrive, whether the moderation queue is moving, whether approved messages appear, whether the display remains current and whether reports from participants indicate a wider issue.

Set practical thresholds for intervention. One delayed submission may not indicate failure, while a sustained absence of new messages during an expected activity could justify investigation. The team should also distinguish low participation from a technical fault. A nominated operator can submit a controlled test message at agreed intervals where that is suitable for the event.

A message wall is not healthy merely because it remains visible. The team must know whether submissions, review and publishing are all functioning.

Prepare for connectivity and device failure

Operator connectivity loss

Where possible, provide the operator with an alternative connection appropriate to the operating environment, such as a separately tested network path. Confirm access before the event rather than assuming a backup will work. If the primary operator disconnects, the handover procedure should state who takes control, how they confirm the queue state and how duplicate moderation is avoided.

Display or browser failure

A display device may freeze, lose power, close unexpectedly or stop refreshing. Prepare a restart sequence that identifies the correct page, login dependency, display mode and validation step. If another prepared device is available, define when the team should switch rather than continue troubleshooting on air. Any credentials must be handled through the organiser’s approved access practices.

Participant submission failure

If participants cannot reach the submission route, the host or support team needs a simple, accurate holding message. Avoid repeatedly directing guests to retry when the cause is unknown. The decision owner may pause promotion of the wall while the team verifies scope, records the incident and selects a fallback.

Design a controlled manual fallback

A fallback should preserve the purpose of the activity without pretending the primary workflow is operating normally. One option may be to collect messages through an agreed secondary channel, review them manually and present a curated selection later in the programme. Whether that approach is suitable depends on moderation, consent, privacy, access and production requirements.

Document who can access fallback submissions, how messages are reviewed, how approved entries are transferred and how the audience is informed. Do not introduce an unapproved public channel during the event merely because it is convenient. Personal information should be limited to what is necessary for the agreed activity, with handling arrangements reviewed by the organiser or its advisers where appropriate.

Fallback records should include timestamps and status labels such as received, reviewed, approved, published or withheld. This supports orderly recovery and reduces the chance of publishing the same message twice.

Use severity levels and escalation triggers

A lightweight incident scale keeps responses proportionate. The exact timings and thresholds should be agreed during message wall implementation planning.

1. Minor: an isolated device or participant issue with no material effect on the wider wall. Record it and provide targeted support where feasible.
2. Degraded: delayed submissions, intermittent publishing or reduced moderation capacity. Notify production, increase monitoring and prepare the fallback.
3. Major: widespread submission, moderation or display failure affecting the programme. Escalate to the decision owner and activate the agreed alternative.
4. Critical: a safety, privacy or inappropriate-content concern that may require immediate suspension while the organiser assesses the situation.

Each level should specify who is notified, what evidence is captured and who may authorise recovery. Technical recovery should not automatically restore public output if unreviewed content accumulated during the interruption.

Recover carefully and reconcile every message

After service returns, first verify each stage with controlled testing. Confirm that moderation rules remain active, the display is showing current content and the team understands the queue state. Resume participant promotion only after the decision owner or delegated lead accepts the recovery.

Reconciliation should compare primary and fallback records. Identify messages already displayed, approved but not displayed, still awaiting review, duplicated or withheld. Decide whether late approved messages should appear during the remaining programme, be included in a post-event output or remain unpublished. The answer should follow the organiser’s agreed communication and content policy.

Maintain a short incident log containing the start time, observed symptoms, actions, decisions, recovery time and unresolved items. This creates a useful operational record without requiring speculative conclusions during the live event.

Rehearse the failures, not only the ideal flow

A meaningful rehearsal includes simulated disruption. Test operator handover, loss of the primary connection, a frozen display, an unavailable submission route, moderation backlog and fallback activation. Confirm that contact details, access permissions, devices and restart instructions work in the actual production context where possible.

Finish with a timed recovery drill and a short debrief. Update the run sheet where responsibilities were unclear or recovery depended on undocumented knowledge. Get Out! Events can coordinate these operational preparations with the broader event delivery team, while GO Labs can support the scoped message-wall implementation. Outcomes remain dependent on the chosen tools, third-party services, connectivity and procedures approved for the event.