Event Operations Command Center

Show night

An event producer’s operational reality on show night: the run-of-show lives in a spreadsheet printed that morning, staff coordination happens over radio and three group chats, and incidents live in whoever-saw-it’s memory until the debrief — if there is one. Every delay cascades invisibly; every decision is made with partial information about what the rest of the team already knows. The concept is a single operational surface for the day: what’s supposed to happen, what’s actually happening, and what went wrong, in one place with one timeline.

Who it serves

• Event producers and production managers running festivals, conferences, and venue shows
• Stewards, volunteers, and crew leads who need their slice of the plan, not all of it
• Operations leads accountable for safety records and post-event review

Run-of-show as live data

A run-of-show is a dependency graph wearing a spreadsheet costume. Modeled as data — cues, owners, locations, dependencies — a fifteen-minute soundcheck overrun visibly shifts everything downstream, and the people affected are notified specifically instead of discovering it by radio rumor. Changes are versioned with author and time, because “who moved the doors time?” is a question someone always asks at the debrief.

Designed for dead networks

Venue WiFi and cell coverage fail at doors-open, when ten thousand phones arrive — the precise moment the tool matters most. So the architecture assumes disconnection as the normal state: the full show plan, contact sheet, venue maps, and incident forms sync to every device before the event; every screen works read-only with zero connectivity; writes queue locally and reconcile when a link returns. Sync traffic is deltas measured in kilobytes, built for one bar of congested signal. Message delivery is explicit — sent, delivered, seen — because on show night, “probably delivered” is indistinguishable from “lost,” and people fall back to radio the first time the app lies to them.

Role-based views

The producer sees everything. A steward sees their zone: their tasks, their cue times, their escalation contact, and a big obvious button to report an incident. This is not a permissions nicety — it is cognitive load management for a temporary workforce that may have joined that morning. Broadcast messages exist but are rationed by design; targeted comms to roles and zones are the default, because an app that spams every volunteer with everything gets muted by 8 p.m.

Incidents: written for the debrief

Incident capture is deliberately minimal in the moment — category, location, severity, photo, free text, timestamped automatically — because nobody types paragraphs during a crowd surge. Ownership and status live on each incident, so “is anyone handling this?” has an answer. The quiet payoff comes later: the incident log, the message timeline, and the run-of-show deltas together reconstruct the event as it actually ran. The debrief stops being an argument about memory and becomes a review of the record — and across multiple events, patterns (the same gate, the same hour, the same understaffed zone) become visible enough to plan against.

System overview

• Local-first mobile apps with a pre-event full sync and queued, conflict-tolerant writes
• Delta sync protocol designed for congested, intermittent links
• Web console for planning and the live producer view
• Role and zone model shared across planning and show mode, so access follows the staffing plan
• Post-event export: timeline, incident log, and change history in one package

There is deliberately no AI in the concept. Show night is a low-trust, high-stakes environment where a wrong automated suggestion costs more than it saves; the product’s value is a reliable shared record, and reliability is the whole brief.

Prototype scope and evaluation

A credible prototype covers one event archetype — a single-day, multi-zone venue show — with run-of-show, targeted comms, and incident capture, tested in a forced-degradation harness that simulates the doors-open network collapse. Hypotheses worth testing: a steward reports an incident in under thirty seconds gloved and standing (design budget); zero queued writes lost across disconnection cycles; and the adoption question that decides everything — does the production team keep the radio channel quieter because the app is genuinely faster, or does the app become one more thing to ignore?