virtual-event-production

Virtual Event Production

You run delivery for an event with no room. A software platform is the venue, each attendee's own connection is the uplink, and the crew is a moderator roster plus a remote-speaker pipeline rather than a stage crew. Treat the format as settled: samber/dev-event-organizer-skills@event-format-selection already chose fully-virtual. Never re-argue that choice.

Where the room disappears

This boundary is written from your side only. Confirm it rather than implying an agreed handoff.

samber/dev-event-organizer-skills@event-production owns capture-through-published-master for any event with a physical room to instrument, including whatever stream that room also produces. It stops at the recorded or streamed output.

Its whole model has meaning only where a room exists: a mixing board, a camera on the board feed, a crew watching a monitor, a stage manager, the coverage tier named for a smartphone at the back of a room. You start where the room disappears entirely.

• Capture. A camera pointing at a physical stage is samber/dev-event-organizer-skills@event-production's signal path, not yours, even when the audience is remote. Own the case with no stage to point at.
• The remote attendee's day. samber/dev-event-organizer-skills@event-attendee-experience scopes itself to "the general-attendee on-site journey" and keys every mechanic (badge desk, wayfinding, quiet room) to a signed floor plan, so it says nothing about a remote attendee's journey. Cover that mirror here; that skill does not know this one exists.
• The channel architecture. samber/dev-event-organizer-skills@event-comms-channels owns which channels exist, who is on each, and which class of message routes where, for remote and physical attendees alike. Consume its roster. Add only the live in-session question surface and the staffing that watches it, and reuse its standing-moderation-cost argument rather than deriving a second one.
• Speaker care. samber/dev-event-organizer-skills@event-speaker-experience owns the speaker relationship end to end, including the recording consent record you may not publish past. Its tech check happens on "the actual stage equipment" and its green room is a physical space, so remote connectivity testing, home-setup guidance and local backup recording fall to you. Hand the results back.
• The day. samber/dev-event-organizer-skills@event-run-of-show builds a cue sheet keyed to rooms, room leads, and an organizer-only channel. One coordination channel reserved for the organizing team, separate from every attendee-facing one, carries over to a virtual event unchanged. Nothing else about a room-keyed cue sheet does.
• Accessibility. samber/dev-event-organizer-skills@event-accessibility-inclusion decides whether captions are required and to what standard. Deliver them on the platform and report what the platform can and cannot do. Never set the bar yourself.

Every ranking below is a default, not a law. After the interview, re-rank all four menus against what you already know. Each of these overturns a default rung:

• a community that already lives in a chat space
• an organizer who has streamed before
• a platform an employer or sponsor has already paid for
• a previous edition whose feed died

Each promotion condition below names its interview question inside the condition's own text, and each trigger in an "or" list is keyed separately rather than riding on the first. Never source a condition from the re-ranking list above: that is a standing instruction, not an answer the interview collected. The four delete items cite no question on purpose - each is deleted unconditionally, on an argument that holds whatever the user answers.

Interview

Ask one question at a time, multiple-choice where possible. Questions 7-9 exist because the menus diverge sharply on time-to-effect, durability and effort, and those orderings cannot be picked for the user.

1. Is there an interaction surface at all, or is this a feed people watch? This reorders every menu below, and it decides whether Menu 3 exists at all.
2. How many sessions run at the same time, and how long is the shortest gap between them?
3. Where are the speakers and where is the audience - one time zone, or a spread wide enough that somebody presents in the middle of their night?
4. What did the format decision promise, and to whom: a paid virtual ticket, a sponsor deliverable naming the stream, an access commitment to people who cannot travel?
5. What is the recording and publication consent posture per session, and where is that record held? Do attendees appear on camera anywhere - a breakout, a networking room, a Q&A?
6. Does anything constrain where attendee data may be held or which platform may be used - an employer's procurement, a sponsor's contract, an umbrella organization's rules?
7. What is the last date a platform choice can still be reversed? That deadline, not the event date, is what these menus are ranked against.
8. One-off edition or a recurring event? A recurring event promotes every rung whose payoff lands after this edition: a rehearsed crew, a warm fallback path, a home-setup note you send again next year.
9. What is the effort ceiling - how many people can be doing only production during a session rather than also doing something else, and who is still available the week after?
10. What already exists that should re-rank these defaults: a chat space your audience is already in, an organizer who has run a stream before, a platform somebody already pays for, last edition's failures?
11. Which sessions cannot be re-run or rescheduled, which carry a live demo, and which speakers have an unknown connection or have never presented on this platform? Nothing else above reaches what a session contains or how badly it must not fail, and four rungs below promote on exactly that.

What actually splits this work

The community-run versus vendor-run pole decides less here than it looks. A packet takes the same milliseconds whoever funded the event. What it does decide is Q6: a vendor-run event arrives more often with a platform already forced on it by procurement, which deletes a rung rather than reordering one.

Two answers reshape every menu, in this order: whether an interaction surface exists, then how many sessions run at once.

• A single feed with comments closed is a broadcast, and needs almost nothing.
• Three simultaneous tracks with open chat is a staffing problem before it is a technical one.

Say which of the two a recommendation assumes whenever they differ.

Workflow

1. Fix the interaction posture in one line - a feed people watch, or an event people are inside. Write it down before anything else; every menu below is a consequence of it.
2. Read the inputs rather than re-collecting them: the channel roster, the per-speaker consent record, the accessibility bar, and whatever the format decision promised.
3. Choose the platform posture (Menu 1), then put the vendor questions in references/platform-selection-and-vendor-questions.md to whoever can answer them, in writing, before committing.
4. Choose remote-speaker readiness depth (Menu 2) and send the home-setup note the same day acceptances go out. Details in references/remote-speaker-readiness.md.
5. Staff moderation (Menu 3) per concurrent session, by name, not by function. Skip this step entirely if step 1 said "a feed people watch".
6. Pick the failure-drill depth (Menu 4) and publish the fallback line where the audience will look for it, before the day. Runbook in references/moderation-and-failure-drills.md.
7. Rehearse once, on the platform the event actually runs on. This is the step that gets cut, and a rehearsal on a different tool tests nothing.
8. Hand the cost consequence to samber/dev-event-organizer-skills@event-budget, split by what a lean tier drops: the feed itself survives every tier; the interaction surface and its staffing go first.
9. After the event, hand captured sessions to samber/dev-event-organizer-skills@event-content-repurposing and the recording consent check back to samber/dev-event-organizer-skills@event-speaker-experience.

Present the plan section by section for validation - interaction posture, then platform, then speakers, then moderation staffing, then the drill - before any contract is signed. After signature, a platform change costs money rather than a conversation.

If your harness has persistent memory, record per edition:

• which platform posture was chosen and what its vendor answers actually were
• which speakers needed which readiness rung
• how many moderators were genuinely busy versus idle
• every failure and which drill caught it
• what the audience did in the minutes after a feed dropped

A platform used twice is worth not re-learning.

Menu 1 - Platform posture

The platform is your venue. Rank it like one: what it costs to acquire, what it costs to run, and what it actually buys the person watching.

Ranking (default, not a law - Q1, Q6, Q7 and Q10 re-rank it):

• ops effort (setup hours, people on the day, skill required): assembled stack > managed virtual-venue platform > broadcast tool with a built-in question queue > one-way feed plus the existing chat space > single one-way feed
• procurement cost (lead time to acquire, commitment signed, how reversible up to the date): managed virtual-venue platform > broadcast tool with a built-in question queue > assembled stack == one-way feed plus the existing chat space > single one-way feed - argued tie: both are assembled from things you can start and abandon in the same week, with nothing signed. The assembled stack's real price is paid in hours, and those already sit on the effort line above; the existing chat space was procured for another reason and this decision does not commit it further.
• value, reach (a watchable, audible talk arrives at a person on their own home connection): single one-way feed == one-way feed plus the existing chat space > broadcast tool with a built-in question queue > managed virtual-venue platform == assembled stack - argued tie at the top: the chat space sits beside the feed rather than inside it, so it adds nothing the video path has to carry. Argued tie at the bottom: both put the viewer behind a login and a bespoke player instead of a public video platform's delivery, and both add moving parts between the speaker and the viewer.
• value, interaction (attendees reach the speaker and each other, live): managed virtual-venue platform > assembled stack > one-way feed plus the existing chat space == broadcast tool with a built-in question queue > single one-way feed - argued tie: one buys attendee-to-attendee conversation with no question discipline, the other buys a disciplined question queue with no peer space. Neither buys both, and which one is worth more depends on Q1's answer, not on this ordering.
• compliance cost (the review it triggers and what stops being reversible): managed virtual-venue platform > assembled stack > broadcast tool with a built-in question queue == one-way feed plus the existing chat space > single one-way feed - argued tie: both hold attendee identity inside one vendor's chat or question record and nothing more; neither creates a directory a third party can export. The top rung is different in kind: an attendee directory and sponsor-facing lead capture trigger a data-handling review before signature, and a list a sponsor has already exported cannot be recalled. The assembled stack sits second because you chose each component's jurisdiction yourself, which is a review you own rather than one a vendor's terms performed for you.
• efficiency: single one-way feed > one-way feed plus the existing chat space > managed virtual-venue platform > assembled stack > broadcast tool with a built-in question queue

Dominance check: 5 rungs, 10 pairs, four cost-and-value axes plus compliance, one real strict-dominance relation.

• The one-way feed plus the existing chat space strictly dominates the broadcast tool with a built-in question queue: cheaper on ops effort, cheaper on procurement, tied on compliance, better on reach, tied on interaction. Dominance asks for no-worse on every axis and strictly-better on at least one; the two ties count as part of the relation, not as gaps in it, since this pair is strictly better on three axes.
• Eight of the remaining nine pairs are blocked by the interaction axis running opposite to effort: the rungs that buy conversation cost strictly more to acquire and to run. One of those eight, the broadcast tool against the assembled stack, is blocked twice over, since procurement also runs opposite to ops effort there.
• The last pair, the managed platform against the assembled stack, is blocked by procurement and compliance running opposite to ops effort and interaction: the managed platform is the lighter one to run and the heavier one to commit to.
• That accounts for all ten pairs (1 relation + 8 + 1).

One warning about the reach axis. Taken alone it is close to rank-identical to inverse effort, and would collapse this menu into cheapest-first, the ordering the ranking discipline exists to prevent. It earns its place only because the interaction axis runs the opposite direction, which is what gives this menu a real dominance relation rather than a vacuous check.

• One-way feed plus the existing chat space - the default. The feed goes to a public video platform; the conversation happens in the space samber/dev-event-organizer-skills@event-comms-channels already designed, with no second login and no second roster.

  Drop to the single one-way feed whenever Q9 says nobody can watch a chat during sessions: an open space in the event's name with nobody on duty is a code-of-conduct obligation with no responder. The published digital-harassment warning applies to it exactly as it does during a staffed session.

• Single one-way feed - the minimum viable posture, and it wins outright more often than it looks. Comments closed, no accounts, nothing to moderate, the lowest compliance exposure on the page, and the most robust delivery to a person on a phone.

  It is the honest choice for an event whose remote audience wants the talks and not the company. It is not "not running a virtual event" - that decision belongs to samber/dev-event-organizer-skills@event-format-selection.

• Broadcast tool with a built-in question queue - strictly dominated above, and kept on the menu for one reason only: Q6 can arrive with it already chosen and paid for. When it is what you have, run it and spend the saved decision on Menu 3.

• Assembled stack - separate streaming software, a separate chat platform, a separate sched

...