event-comms-channels

Event Comms Channels

You design the set of channels a technical event talks to its attendees on, for one edition, from the moment attendees exist to the moment the last channel is closed. Your output is an architecture somebody else executes:

• A roster of channels with a stated job each.
• A rule that says where any given message goes.
• A process that keeps several writers sounding like one event.
• A dated wind-down for every channel you opened.

This skill writes no copy. The register, what the event sounds like, arrives fixed from samber/dev-event-organizer-skills@event-cultural-identity, which owns "the register (hacker, corporate, design, business) and its consistent expression across every touchpoint" (verbatim from that skill's own description).

Decide how a team of writers executes that register across several channels without drifting. Never originate one.

Siblings own part of this, and you must not re-derive them

Sibling	The line
event-run-of-show	Owns the organizer-only coordination channel, kept separate from every population-facing one. Never route staff coordination onto an attendee channel.
event-code-of-conduct	Owns incident reporting entirely, including anonymous paths - exclude it from the roster - and the public-statement rule during an incident (enforced in § Message-class routing).
event-attendee-email-sequences	Owns the mailing list's copy, cadence, consent, hygiene. Decide only whether email is the right channel for a class of message.
event-social-media	Owns public-broadcast platform choice and social copy. Say "this goes out publicly" if needed; never pick the platform or write the post.
event-marketing-plan	Owns acquisition-channel weight before attendees exist. This architecture starts once someone has registered.

Two more boundaries are written from one side only, so say so when relying on them:

• event-attendee-experience owns static wayfinding (printed signs). Dynamic on-site announcement (PA call, live schedule-change screen) belongs here.
• event-community-building owns the standing community between editions. The same chat space can be this edition's channel and next year's community, handed off at Menu 4's top rung.

Interview

Ask one question at a time, multiple-choice where possible. Questions 6-8 exist because the menus below diverge sharply on time-to-effect, durability and effort, so the defaults cannot be picked for the user.

1. Which phase: pre-event, days on site, wind-down after, or all three?
2. Shape: one room/day, several rooms, several days, or an overnight hackathon? Remote, livestreamed, recorded, press-covered? Do attendees need to reach each other?
3. How many people write to attendees, and how many have never written for this event before?
4. Which channels already exist with attendees on them, and does anything signed force a channel (sponsor deliverable, venue system, umbrella platform)?
5. Does a register exist (event-cultural-identity)? If not, route there first and label anything here provisional - this skill executes a register, never sets one.
6. Is there a hard live-by date?
7. One-off edition, or compounding series with a next edition intended? (Turns Menu 4 outright; moves Menu 1's app rung too.)
8. Effort ceiling: organizer hours before the event, who can watch a channel during it, who is on duty the week after?
9. What can break in a way an attendee can't see for themselves (livestream, shuttle, single entrance, venue change, catering failure)?
10. What already exists that should re-rank these defaults - a community chat your audience is already in, last edition's member list, an in-house writer, an app already in use?

Every ranking below is a default, not a law. Re-rank all four menus against Q10's answers, and say which answer moved which rung.

How many things happen at once, and how many people write about them

Every menu below reorders between two scales:

• One room, one day, one writer. A list, and nothing else.
• Three rooms, two days, five volunteer writers. A routing rule, before another channel.

State which of those two scales a recommendation assumes whenever it holds at one and not the other.

A vendor-run event more often arrives with a channel already forced on it by contract (Q4), which deletes a rung rather than reordering one. Beyond that, funding model reorders nothing: a message takes the same seconds to reach a phone whoever paid for the room.

Workflow

1. Run the interview. Stop and route to event-cultural-identity if Q5 comes back empty.
2. List the message classes this edition will actually send, before choosing any channel: references/message-class-matrix-and-message-bank.md. A roster picked before the messages are known is picked by fashion.
3. Choose the channel roster (Menu 1). Give every channel one stated job and one named owner - an unstated job is the channel that goes quiet.
4. Choose the routing policy (Menu 2), written where the writers are, not a document they open once.
5. Choose the consistency process (Menu 3); at the message-bank rung or above, write the bank before the event.
6. Point at the channel directory: event-marketing-plan owns that page (its "comms hub" rung) as the acquisition-side artifact. Hand it the roster - every channel, its job, its boundary - to publish there rather than standing up a second page.
7. Check digital-space obligations: the code of conduct binds every channel; confirm with that sibling, never write the reporting path yourself.
8. Choose the wind-down (Menu 4) now, before the event, and publish its date on the channels themselves.
9. Present section by section - roster, routing, consistency, wind-down - approved before anyone creates a channel.

If your harness has persistent memory, record:

• The roster, with each channel's stated job and owner.
• The routing rule.
• Which message classes actually got sent and where.
• Every message that had to be repeated on a second channel because the first did not reach.
• The wind-down decision and its date.
• Any channel that went quiet.

The repeats and the quiet channels are next edition's roster changes.

Menu 1 - Channel roster

An additive ladder: each rung adds a channel to the ones below it. Two value axes, because reach and speed are not the same thing, and no rung tops both.

• value, a routine message reaches everyone who registered: announcement list > chat space == event app > status page
• value, a change of plan reaches people fast enough to act on it during the event: event app == chat space > status page > announcement list
• effort (setup, plus the standing ops and moderation each one adds for the whole lifecycle): event app > chat space > status page > announcement list
• efficiency: announcement list > chat space > status page > event app

All four orderings are this skill's own construction, not measured rankings. The menu is clean by care, not by construction: it has genuinely mixed pairs, since chat beats the status page on both value axes but costs more, so neither dominates. See references/menu-ranking-rationale.md for why the == ties hold.

The channel directory itself is not a rung here: event-marketing-plan owns that page (its "comms hub" rung). Extend that page rather than publishing a second one - see Workflow step 6.

• Announcement list (default/floor) - already exists from acquisition, reaches every registrant by construction, latency in hours. Move up as soon as a message would arrive too late by email - any message about today.
• Chat space - a persistent two-way space. Real cost is moderation for the whole lifecycle plus the code-of-conduct duty inside it: references/channel-roster-and-platform-notes.md. Promote when Q2 says overnight, multi-day, remote, or attendees need to reach each other.
• Status page - one canonical page saying whether the broken thing is still broken. The pattern is adapted from software incident communication, with four things that do not transfer: references/wind-down-and-status-page.md. Nobody checks it unprompted; it works only with a push on another channel pointing at it. Promote when Q9 names something an attendee can't see for themselves.
• Event app (starved rung) - tops effort, ties chat on speed, loses to the list on reach - efficiency never picks it. No ROI figure exists for a community-run event. Promote when Q4 says a signed commitment forces one, Q2 says 3+ concurrent rooms with a grid changing more than once a day, or Q10 says you already own one with sunk content cost.
• Delete, never demote: a second chat platform running the same job in parallel - doubles moderation, halves each announcement's audience.
• Conditional delete: status page where Q9 comes back empty - a page reporting "everything is fine" trains people not to look.

Menu 2 - Message-class routing

Which class of message goes on which channel.

Rungs:

• One channel for everything.
• A two-channel split (a broadcast channel nobody replies in, one open channel where people talk).
• Per-audience-segment channels.
• A full message-class matrix with escalation tiers.

Orderings:

• value, a message reaches the person who needs it without being buried: matrix > per-segment > two-channel split > one channel
• value, a volunteer writer routes a message correctly on the first try with nobody to ask: one channel > two-channel split > matrix > per-segment
• effort (channels to create and watch, plus the coordination to keep the rule current): matrix > per-segment > two-channel split > one channel
• efficiency: two-channel split > matrix > one channel > per-segment

A routing policy nobody can execute routes nothing. Writer-operability is therefore the pivot this menu turns on, and the efficiency line stands or falls with it: reject the axis and the ordering goes with it. That axis and all four orderings are this skill's own construction, not measured rankings.

One channel is unambiguous by construction. Per-segment channels are the worst of both: segment membership is a fresh judgement call on every message, and the writer resolves it by cross-posting, which rebuilds the noise the segments were meant to remove. See references/menu-ranking-rationale.md for why the efficiency line rests on writer-operability rather than a dominance check.

• Two-channel split (default) - one channel the event posts on, one where attendees talk back. Answers the only routing question most events have, at the cost of one extra channel. Promote when Q3 says multiple writers and Q2 says multiple rooms or days.
• Matrix with escalation tiers (starved rung) - tops reach and effort, loses every efficiency round. One table: message class down the side, channel across the top, plus escalation tiers. Promote with the two conditions above, plus recorded/livestreamed editions where a missed message is missed permanently.
• One channel for everything - legitimate at a single-room single-day event with one writer. Ranks third, not last, on efficiency: top operability at no cost.
• Per-audience-segment channels - last on efficiency, real cost, the operability floor. Choose only when segments are genuinely disjoint and stable for the whole event.
• Delete, never demote: a direct message from an organizer as a routing tier - no record for the next shift, unescalatable, makes the sender the channel.
• Conditional delete: matrix and per-segment rungs where Q2 is one room/day and Q3 is one writer - no message class concerns part of that room only.

One routing rule you inherit, and must not re-derive: a public statement after an incident has exactly one authorized publisher, and nobody else posts about it on any channel. samber/dev-event-organizer-skills@event-code-of-conduct owns that rule outright; restating it here would give a team two copies to disagree with. Make every channel obey it instead: the matrix carries an incident-statement row whose publisher is that named authority, with no local exception for being faster.

Menu 3 - Multi-writer consistency

How several writers execute one register without drifting. The register itself is fixed elsewhere. Nothing here originates one.

• value, consistency across the messages that actually go out during the event: editorial sign-off > pre-written message bank > named owner per channel > shared quick-reference > ad hoc
• value, a time-critical message goes out without waiting for a specific person: pre-written message bank > ad hoc > shared quick-reference > named owner per channel > editorial sign-off
• effort (hours before the event plus coordination during it): editorial sign-off > named owner per channel > pre-written message bank > shared quick-reference > ad hoc
• efficiency: shared quick-reference > pre-written message bank > named owner per channel > ad hoc > editorial sign-off

The first value axis is deliberately scoped to the messages that actually go out during the event, mostly the predictable classes. On that quantity a frozen template beats a human who drifts. Widening it to "every message ever written" would reverse the bank and owner rungs, so state which quantity you mean before reordering anything here.

All four orderings, the five rungs and every promotion condition are this skill's own construction, not measured rankings. See references/menu-ranking-rationale.md for the dominance relation this scope protects.

• Shared quick-reference (default) - one page condensing the register into do/don't lines and worked examples. Near-zero effort since the thinking is done. Move up when Q3 says a writer has never written for this event before.
• Pre-written message bank - templates for classes you know are coming (delay, room change, venue change, lost property, last call, closing, cancellation). Freezes the register into exact messages sent under time pressure. For the nudges that repeat every edition on a predictable clock - a venue-closing warning, a meal-ready ping, a "starting in 3 min

...