hybrid-event-design

Hybrid Event Design

You design the programme and the staffing for an event with two audiences at once: one in the room, one watching from elsewhere. The format decision arrives made. Never reopen it.

This skill is deliberately narrow, and the reason matters

Siblings already own most of what a hybrid event needs. The scope left over is small. Say so rather than expanding into their territory:

• samber/dev-event-organizer-skills@event-format-selection decides whether hybrid happens at all and owns the entire cost case against it. Its verdict: "It is the maximum-cost, maximum-risk option, not the middle". Consume that verdict. Never re-derive the cost argument, never re-quote its figures. If the user is still deciding, route them there and stop.
• samber/dev-event-organizer-skills@event-production owns the room's signal path, capture tier, crew and redundancy, and states its own limit as "Reports hybrid's cost consequence; never decides the format." Every camera, cable and encoder is its work. You name the sessions that need a feed. It builds the feed.
• samber/dev-event-organizer-skills@virtual-event-production owns the event with no room. It starts "once the format decision has already chosen virtual", and scopes itself to the case where "You own the case with no stage to point at." A hybrid always has a stage, so its platform, remote-speaker and drill menus are not yours to repeat.
• samber/dev-event-organizer-skills@event-run-of-show owns the day-of document, the roles and the escalation paths. You add one column to its artifact. Never write a second one.
• samber/dev-event-organizer-skills@event-schedule-design owns the grid. You mark sessions on it. Never move them.

Four things are genuinely left, covered by three menus and one section:

• Which sessions the remote audience gets.
• How far a remote attendee's voice reaches the stage.
• What cue track the stream needs beside the room's.
• Who staffs the remote side.

That is the whole skill. Its shortness is the correct outcome, not a gap.

Every ranking below is a default, not a law. After the interview, re-rank all three menus against what you already know:

• A room already wired for capture.
• A community that has streamed before.
• A remote audience that has already paid.
• A previous edition where remote questions went unanswered.

Each of these overturns a default rung.

Why parity matters, and why it fails

Remote audiences at hybrid events report feeling like second-class attendees when they watch but cannot participate. The failure is not equipment; it is attention.

Two documented cases:

• A workshop running late in the room while remote participants are not told.
• Remote check-in lagging because the team is busy in person.

In both, the staff were looking at the room and the remote audience got what was left. A scaled-back hybrid conference confirms the pattern: online participants reported it less engaging than anticipated, and the event closed at a loss.

Every value ordering below is reasoned, not measured. No menu choice here carries a figure tying it to remote attendance, engagement or satisfaction.

Never invent any of these to justify a rung:

• A parity threshold.
• A remote-to-in-room staffing ratio.
• A share of Q&A owed to remote.
• A tolerable stream delay.

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 - those orderings cannot be picked for the user.

1. What was the remote audience actually promised, and to whom? A paid virtual ticket, a sponsor deliverable naming the stream, an access commitment to people who cannot travel, or nothing written down. It reorders every menu below, and the rest of the day gets argued against it.
2. How many rooms run at once, and how many of them can physically carry a feed? A room the production sibling cannot instrument deletes rungs rather than reordering them.
3. Where is the remote audience relative to the room: the same working day, or a spread wide enough that part of your programme lands in the middle of their night?
4. What is the recording and publication consent posture per session, and who holds that record? Does the in-room audience appear on the outgoing feed during Q&A?
5. Does anything constrain which platform may carry the feed, or where attendee data may sit: an employer's procurement, a sponsor's contract, an umbrella organization's rules?
6. Has the schedule document arrived with a disruption priority order, and does it say anything about the remote side? Silence there is a gap you close in advance (see § The cue track the stream needs).
7. What is the last date a session can still join or leave the remote programme? These menus are ranked against that deadline, not against the event date.
8. One-off edition or a recurring event? A recurring event promotes every rung whose payoff lands after this edition: a briefed advocate, a cue template carrying both audiences, a consent form that already asks the right question.
9. What is the effort ceiling: how many people can work the remote side alone during a session, rather than also covering something in the room?
10. What already exists that should re-rank these defaults: a room already wired, an organizer who has streamed before, last edition's remote complaints, a community that already lives in a chat space?

What actually splits this work

Community-run and vendor-run events diverge at one question, not across the menus. A remote attendee waits the same seconds for an answer whoever funded the room.

That question is Q1. A vendor-run event more often arrives with the remote audience already sold something:

• A virtual ticket.
• A customer commitment.
• A sponsor line naming the stream.

Being sold something promotes rungs rather than reordering them, because a promise is not a preference.

Two things reshape every menu instead:

• Whether the remote audience has a return path at all.
• After that, how many rooms carry a feed.

A single streamed room with a one-way feed is a broadcast attached to a conference, and it needs almost nothing new. Two streamed rooms with live Q&A is a staffing problem before it is a technical one. Say which case a recommendation assumes whenever the two differ.

Workflow

1. Confirm the format decision is closed. If hybrid is still being weighed, route to samber/dev-event-organizer-skills@event-format-selection and stop. Re-arguing it here wastes the only pass you get.
2. Write down what the remote audience was promised, in one sentence, from Q1. Every later choice is measured against that sentence, not against what is technically possible.
3. Mark remote eligibility on the published grid (Menu 1) as a column, not as a separate list. A separate list is a second document, and second documents drift.
4. Choose the parity depth (Menu 2). For what each rung looks like minute to minute, read references/remote-eligibility-and-parity-mechanics.md.
5. Hand the eligible-session list to samber/dev-event-organizer-skills@event-production as an input to its own coverage-tier decision, per room. You name the sessions and the return path. It names the equipment. Never specify equipment yourself.
6. Check the consent record covers what the feed will carry (Q4). samber/dev-event-organizer-skills@event-speaker-experience holds that record, and samber/dev-event-organizer-skills@event-production states the constraint a live feed adds: "a speaker's opt-out has to be honoured in the room rather than in an edit". Settle this before the grid is marked, not after.
7. Staff the remote side (Menu 3), by name per streamed session rather than by function.
8. Add the stream's cue track to the run of show (see below) and hand it to samber/dev-event-organizer-skills@event-run-of-show as an addition to its document.
9. Close the two-audience gap in the disruption priority order (Q6) before the day, in writing, and say who decided it.
10. Report the staffing consequence to samber/dev-event-organizer-skills@event-budget, split by what a lean tier can drop. The feed itself survives every tier; the return path and the people watching it are what a lean tier cuts first.

Present the plan section by section for validation, in this order:

1. The promise.
2. Eligibility.
3. Parity.
4. Staffing.
5. The cue track.

Do this before the grid is published. After publication, removing a session from the remote programme is a public retraction rather than a decision.

If your harness has persistent memory, record per edition:

• What the remote audience was promised, and in whose words.
• Which sessions were marked eligible, and which speakers declined.
• How many remote questions actually reached a stage.
• Every moment the remote side was left unattended, and what the room was doing instead.
• What the disruption order turned out to say about remote.

A second edition should start from that record rather than from these defaults.

Menu 1 - Session remote eligibility

Which sessions the remote audience gets. Mark this on the grid samber/dev-event-organizer-skills@event-schedule-design published - that skill's own limit is "You stop at the published grid", so the column is yours to add and the placement is never yours to change.

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

• effort (rooms instrumented, crew committed, consent chased, editorial passes over the grid): every session in every room > per-session speaker opt-in > curated remote programme > one designated streamed room > plenary only. Opt-in outranks curation on cost, for two reasons worth stating:
  • An opt-in can land in any room, so you instrument every room, which is the top rung's bill.
  • Constrain where speakers may opt in and it stops being an opt-in. A curated set is bounded because you chose it, and you can choose it to sit in rooms already carrying a feed.
• value, breadth (how much of the programme a remote attendee can actually watch): every session in every room > per-session speaker opt-in == curated remote programme > one designated streamed room > plenary only - argued tie: neither delivers a predictable share of the programme. How many speakers say yes sets opt-in's breadth; the organizer's own editorial ceiling sets curation's. Which ends up wider is not knowable before the fact.
• value, coherence (a remote attendee gets a day that holds together rather than a scatter of fragments): curated remote programme > one designated streamed room > plenary only > every session in every room > per-session speaker opt-in. This axis is why the menu is not a ladder:
  • A curated programme is designed as a remote day. A single streamed room is at least a continuous thread. Plenary-only is short but complete.
  • Streaming everything hands a remote attendee a multi-track grid they can watch only one stream of, with none of the corridor cues that make a room's choice easy.
  • Opt-in ranks worst: it produces holes at times nobody can predict.
• compliance cost (the review it triggers and what stops being reversible): every session in every room > curated remote programme == per-session speaker opt-in > one designated streamed room > plenary only - argued tie: both put a mid-sized, organizer-known subset of the programme out. The curated set arrives needing each chosen speaker's consent chased. The opt-in set arrives with the speaker's consent already given and needs the in-room audience's covered instead: the questioners whose voices and faces go out live. Same review, different half of it. What makes this axis real rather than decorative is the sibling constraint quoted above, an opt-out honoured in the room rather than in an edit, and "A published stream cannot be recalled from the people already watching it."
• efficiency: plenary only > one designated streamed room > curated remote programme > per-session speaker opt-in > every session in every room

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

The curated remote programme strictly dominates per-session speaker opt-in: cheaper on effort, tied on compliance, tied on breadth, strictly better on coherence.

The remaining nine pairs split into two blocks:

• Blocked by breadth alone, where the cheaper rung also wins coherence and loses only on how much a remote attendee can watch (five pairs): plenary-only against opt-in, plenary-only against every-session, one-room against opt-in, one-room against every-session, and curated against every-session.
• Blocked by cost running opposite to both value axes (four pairs): plenary-only against one-room, plenary-only against curated, one-room against curated, and opt-in against every-session.

That accounts for all ten (1 relation + 5 + 4).

• One designated streamed room - the default: one room is the remote room, and whatever the grid puts in it is what remote gets. It buys a continuous day for the cost of instrumenting one room, needs no per-session negotiation, and collapses the eligibility question into a room-booking question the schedule already answered. Move up to the curated programme whenever Q1 says the remote audience paid or was promised specific content. A room chosen for its cabling is not a programme anyone was promised.
• Plenary only - the minimum, and it wins outright more often than it looks. The opening, the keynotes and the closing carry the widest audience, usually sit in the room already best equipped, and make sense to someone who is not in the building. It is the honest choice when Q1's answer is "nothing written down".
• Curated remote programme - organizers choose the sessions that serve a remote audience specifically, and mark them. Tops coherence, mid on everything else. It treats the remote audience as an audience rather than as an overflow.
• Per-session speaker opt-in - strictly dominated above, and kept on the menu for one reason: a consent posture can hand it to you already decided. Where samber/dev-event-organizer-skills@event-speaker-experience's consent record is per-speaker and opt-out is genuinely offered, the eligible set is whoever said yes. Make the resulting holes legible rather than pretending they are a programme.
• Every session in every room - the starved option: tops breadth, tops both cost axes, bottoms coherence, so efficiency never picks it. Promotion conditions:
  • Keyed to Q1: a paid virtual ticket sold as access to the whole programme.
  • Keyed to Q2: a venue where every room is already instrumented, so breadth costs nothing extra to reach.
• Delete, do not demote: publishing the recordings afterwards and calling that the remote programme. Strike it from this menu and from the axis lines above. It reads as the cheapest hybrid and it is not a h

...