event-comms-channels

活动沟通渠道

你为一场技术活动设计一组渠道，供活动在某一届活动期间与参会者沟通，覆盖从参会者出现到最后一个渠道关闭的整个过程。你的输出是一套由他人执行的架构：

• 一份渠道清单，并为每个渠道注明职责。
• 一条规则，说明任何给定消息应发送到哪里。
• 一个流程，确保多位撰稿人的表达听起来像同一场活动。
• 为你开设的每个渠道制定有日期的逐步关闭计划。

此技能不撰写文案。活动的语气固定由 samber/dev-event-organizer-skills@event-cultural-identity 提供，该技能负责“语气（黑客、企业、设计、商务）及其在所有触点上的一致表达”（引自该技能自身的描述）。

决定团队如何在多个渠道中_执行_这一语气，同时避免偏离。切勿自行创作语气。

这部分由相关技能负责，你不得重新推导

相关技能	职责
event-run-of-show	负责仅供组织者使用的协调渠道，并与所有面向活动人群的渠道分开。切勿将工作人员协调信息发送到面向参会者的渠道。
event-code-of-conduct	全权负责事件报告，包括匿名途径——将其排除在渠道清单之外——以及事件发生期间的公开声明规则（在 § 消息类别路由中执行）。
event-attendee-email-sequences	负责邮件列表的文案、发送频率、同意管理和维护。你只需决定邮件是否适合发送某类消息。
event-social-media	负责选择公开广播平台和撰写社交媒体文案。如有需要，说明“此内容将公开发布”；切勿选择平台或撰写帖子。
event-marketing-plan	负责参会者出现前的获客渠道权重。本架构从有人注册后开始。

另外还有两项边界只从单侧定义，因此依赖它们时要说明：

• event-attendee-experience 负责静态导览（印刷标识）。动态现场公告（PA 呼叫、实时日程变更屏幕）由本技能负责。
• event-community-building 负责不同届活动之间持续存在的社群。同一个聊天空间可以既是本届活动的渠道，也是明年的社群；在菜单 4 的最高级别移交。

访谈

每次只问一个问题，尽可能采用选择题。之所以要问第 6～8 题，是因为下方的菜单在见效时间、持久性和投入方面差异很大，不能替用户选择默认项。

1. 属于哪个阶段：活动前、现场期间、活动结束后的收尾阶段，还是三个阶段都包括？
2. 活动规模：一个房间一天、多个房间、持续数天，还是通宵黑客马拉松？是否有远程参与、直播、录像或媒体报道？参会者需要彼此联系吗？
3. 有多少人会向参会者发送信息？其中有多少人从未为这场活动撰写过内容？
4. 哪些现有渠道已有参会者使用？是否有已签署的协议要求使用某个渠道（赞助商交付内容、场地系统、统一平台）？
5. 是否已有规范（event-cultural-identity）？如果没有，先转到那里，并将此处的所有内容标为暂定——此技能负责执行规范，而不是制定规范。
6. 是否有必须上线的硬性期限？
7. 是一次性活动，还是计划举办下一届、逐步积累的系列活动？（这会直接影响菜单 4；也会改变菜单 1 中应用的排序。）
8. 投入上限是多少：活动前组织者能投入多少小时？活动期间谁能看管渠道？活动后一周谁负责值守？
9. 有哪些故障可能在参会者无法自行察觉的情况下发生（直播、接驳车、唯一入口、场地变更、餐饮故障）？
10. 已有哪些现成条件应该改变这些默认排序——受众已加入的社区聊天、上一届的成员名单、内部撰稿人，或已在使用的应用？

下面的所有排序都是默认建议，而非硬性规定。请根据问题 10 的回答重新排列全部四个菜单，并说明哪个回答改变了哪个排序项。

有多少事情同时发生，又有多少人负责撰写

下面的每个菜单都会在两种规模之间调整排序：

• 一个房间、一天、一位撰稿人。 一份名单，仅此而已。
• 三个房间、两天、五位志愿撰稿人。 先制定分发规则，再增加其他渠道。

只要某项建议在其中一种规模下成立、在另一种规模下不成立，就要说明它假设的是哪种规模。

供应商运营的活动往往会因合同要求而必须使用某个渠道（问题 4），这会直接删除一个排序项，而不是调整顺序。除此之外，资金模式不会改变排序：无论谁为场地付费，信息传到手机上所需的时间都一样。

工作流

1. 进行访谈。如果问题 5 的回答是没有，则停止并转到 event-cultural-identity。
2. 在选择任何渠道之前，先列出本届活动实际会发送的信息类别：references/message-class-matrix-and-message-bank.md。不知道要发送什么信息就先选渠道，无异于跟风。
3. 选择渠道名单（菜单 1）。为每个渠道指定一项明确的用途和一位具名负责人——用途不明的渠道最终会无人问津。
4. 选择分发规则（菜单 2），并将其写在撰稿人所在之处，而不是写在他们只会打开一次的文档里。
5. 选择一致性流程（菜单 3）；达到信息库档位或更高时，要在活动前编写信息库。
6. 指向渠道目录：event-marketing-plan 负责维护该页面（其“沟通中心”档位），作为获客侧的交付物。将渠道名单——每个渠道及其用途、边界——交给它发布在那里，而不是另建一个页面。
7. 检查数字空间的相关义务：行为准则约束所有渠道；请与负责行为准则的同级技能确认，切勿自行编写举报途径。
8. 现在就选择活动结束后的收尾方式（菜单 4），在活动前完成，并在各渠道上公布日期。
9. 按章节逐项提交——渠道名单、分发规则、一致性、收尾方式——每项获批后再创建任何渠道。

如果你的运行框架支持持久记忆，请记录：

• 渠道名单，以及每个渠道明确的用途和负责人。
• 分发规则。
• 实际发送过哪些信息类别，以及发送到了哪里。
• 因第一渠道未能触达而必须在第二渠道重复发送的所有信息。
• 收尾决定及其日期。
• 任何无人问津的渠道。

重复发送的信息和无人问津的渠道，都是下一届调整渠道名单的依据。

菜单 1 - 渠道清单

一架逐级增加的阶梯：每一级都会在下方各级的基础上增加一个渠道。两个价值维度，因为覆盖面和速度并非一回事，而且没有哪个级别能在两方面都拔得头筹。

• 价值：一条常规消息能触达所有已注册者：公告列表 > 聊天空间 == 活动应用 > 状态页
• 价值：计划变更能及时触达参与者，让他们在活动期间采取行动：活动应用 == 聊天空间 > 状态页 > 公告列表
• 投入（设置成本，以及整个生命周期内每种渠道新增的持续运营和审核工作）：活动应用 > 聊天空间 > 状态页 > 公告列表
• 效率：公告列表 > 聊天空间 > 状态页 > 活动应用

以上四种排序均为本技能自行制定，并非实测排名。这份菜单之所以合理，是经过审慎设计，而非自然形成：其中确实存在互有胜负的组合，例如聊天空间在两个价值维度上都胜过状态页，但成本更高，因此两者互不支配。关于 == 持平的依据，请参阅 references/menu-ranking-rationale.md。

渠道目录本身不属于这里的某个阶梯：event-marketing-plan 负责该页面（其“沟通枢纽”阶梯）。请扩展该页面，而不要另行发布第二个页面——参见工作流第 6 步。

• 公告列表（默认／底线）——在获客时就已建立，自然能触达每位注册者，延迟以小时计。一旦某条消息通过邮件送达时已经太迟，就应升级渠道——任何有关当天的消息都是如此。
• 聊天空间——一个持久的双向交流空间。实际成本是整个生命周期内的审核工作，以及其中的行为准则维护责任：references/channel-roster-and-platform-notes.md。当 Q2 的答案提到通宵、多日、远程，或参与者需要彼此联系时，就应启用。
• 状态页——一个说明故障是否仍未解决的权威页面。此模式改编自软件事故沟通，但有四点无法直接沿用：references/wind-down-and-status-page.md。没人会主动查看它；只有通过其他渠道推送链接，引导人们访问时，它才有效。当 Q9 提到参与者无法自行看到的内容时，就应启用。
• 活动应用（供给不足的阶梯）——投入最高，速度与聊天空间持平，覆盖面不及公告列表，因此从效率角度看，它永远不会胜出。社区运营活动没有现成的 ROI 数据。当 Q4 表示签署的承诺要求必须使用时、Q2 表示有 3 个或更多并行分会场且日程表每天变更超过一次时，或 Q10 表示你已经拥有活动应用且其中已有内容投入时，就应启用。
• **删除，切勿降级：**同时运行第二个平台来承担相同聊天工作——审核工作翻倍，每条公告的受众各减半。
• **有条件删除：**当 Q9 的答案为空时的状态页——报告“一切正常”的页面会让人逐渐不再查看。

菜单 2 - 消息类别路由

哪类消息应发到哪个频道。

层级：

• 所有消息都发到一个频道。
• 双频道拆分（一个只用于广播、无人回复的频道，以及一个供大家交流的开放频道）。
• 按受众细分的频道。
• 包含升级层级的完整消息类别矩阵。

排序：

• 价值：消息能送达需要它的人，而不会被淹没：矩阵 > 按受众细分 > 双频道拆分 > 单频道
• 价值：志愿撰稿人无需询问，就能在首次尝试时正确路由消息：单频道 > 双频道拆分 > 矩阵 > 按受众细分
• 工作量（创建和关注频道，以及维护规则的协调工作）：矩阵 > 按受众细分 > 双频道拆分 > 单频道
• 效率：双频道拆分 > 矩阵 > 单频道 > 按受众细分

没人能执行的路由政策，什么也路由不了。因此，撰稿人能否操作是这个菜单的关键所在，效率排序也取决于此：如果不认同这个维度，排序也就不成立。这个维度和全部四项排序都是本技能自行构建的，并非依据测量结果得出。

单频道在设计上没有歧义。按受众细分的频道则两头不讨好：每条消息都需要重新判断受众细分，撰稿人会通过跨频道发布来解决这个问题，重新制造原本希望通过细分消除的噪声。请参阅 references/menu-ranking-rationale.md，了解为何效率排序依据的是撰稿人可操作性，而非支配性检验。

• 双频道拆分（默认）——一个频道用于活动发布，另一个供参会者回应。只多出一个频道，就能解决大多数活动唯一需要考虑的路由问题。当 Q3 表示有多位撰稿人，且 Q2 表示有多个会场或多天时，升级到此方案。
• 包含升级层级的矩阵（受限层级）——触达效果最佳、工作量最大，但在每轮效率比较中都落败。一张表：纵向列出消息类别，顶部列出频道，并加上升级层级。当满足上述两个条件，且活动有录制版或直播版、漏掉消息就会永久错过时，升级到此方案。
• 所有消息都发到一个频道——适用于单会场、单日且只有一位撰稿人的活动。在效率排名中位列第三，而非最后：操作性最佳且无需额外成本。
• 按受众细分的频道——效率最低，成本高，操作性垫底。仅当各受众群体确实互不重叠，且在整个活动期间保持稳定时才选择。
• **删除，绝不降级：**将组织者的私信作为路由层级——无法为下一班人员留档、无法升级处理，还会让发件人成为频道本身。
• **有条件删除：**当 Q2 为单个会场或单天、Q3 为一位撰稿人时，删除矩阵和按受众细分的层级——没有消息类别只与该会场有关。

**有一条继承而来、不得重新推导的路由规则：**事件发生后，公开声明只能由一位获授权的发布者发布，其他任何人都不得在任何频道发布相关内容。samber/dev-event-organizer-skills@event-code-of-conduct 完全负责这条规则；在此重述会让团队出现两份规则，产生分歧。应让每个频道都遵守这条规则：矩阵中应设置事件声明一行，发布者指定为该授权方，不得以追求更快为由设置本地例外。

菜单 3 - 多位撰写者保持一致

多位撰写者如何共同执行同一套规范而不偏离。规范本身已在别处固定。这里不会创立任何规范。

• 价值：活动期间实际发出的消息在一致性方面的表现：编辑审核 > 预先编写的消息库 > 每个渠道指定负责人 > 共享速查指南 > 临时撰写
• 价值：时效性强的消息无需等待特定人员即可发出：预先编写的消息库 > 临时撰写 > 共享速查指南 > 每个渠道指定负责人 > 编辑审核
• 工作量（活动前所需小时数加上活动期间的协调）：编辑审核 > 每个渠道指定负责人 > 预先编写的消息库 > 共享速查指南 > 临时撰写
• 效率：共享速查指南 > 预先编写的消息库 > 每个渠道指定负责人 > 临时撰写 > 编辑审核

第一条价值轴刻意限定为_活动期间实际发出的消息_，主要是可预测的类别。就这一数量而言，冻结的模板胜过会偏离规范的人。若将其扩大到“曾经写过的每一条消息”，消息库和负责人这两档的先后顺序就会颠倒，因此在重新排序之前，请先说明指的是哪一数量。

这四种排序、五个档位以及所有晋升条件，都是此技能自行制定的内容，并非经过测量的排名。请参阅 references/menu-ranking-rationale.md，了解此范围所保护的支配关系。

• 共享速查指南（默认）——一页内容，将规范浓缩为注意事项和实例。由于思考工作已经完成，几乎无需投入精力。如果 Q3 表示撰写者以前从未为此活动撰写过内容，则升一档。
• 预先编写的消息库——为已知即将出现的消息类别准备模板（延迟、房间变更、场地变更、失物招领、最后提醒、闭场、取消）。将规范冻结为准确的消息，供时间紧迫时发送。对于每届活动都会按可预测时间重复发送的提醒——场地闭场警告、餐点已备好的通知、“3 分钟后开始”的提醒——不妨比准备好备用模板再进一步：提前根据具体时间戳写好全天的完整脚本。这样就不必有人一边运行活动，一边记着在特定时间撰写并发送消息。活动结束后也一样：组织者会自动发送活动后满意度调查。在活动开始前，先在闭场渠道安排调查消息，并记下发送时间。调查问题属于 samber/dev-event-organizer-skills@event-feedback；此技能只负责安排并调度附带调查链接的消息。
• 每个渠道指定负责人——每个渠道的输出由一人负责。这能弥补消息库无法覆盖的一致性问题，代价是负责人不在时消息发送会更慢。event-social-media 负责公共社交媒体账号。
• 临时撰写——没有共享参考。在效率排序中排第四，而非最后：几乎不费力，实际速度快，但投入产出比不佳——它唯一的优点，通过消息库可以更好地实现。
• 发布前编辑审核（资源最少的一档）——一致性最高、工作量最大、速度最慢，而现场活动最受速度影响。若该届活动会被录制、直播或媒体报道，赞助合同要求逐字使用固定措辞，或 Q3 表示大多数撰写者从未见过这套规范，则应升档；即便如此，也要将时效性强的消息类别豁免，交由消息库处理。
• **删除，绝不降级：**由各渠道撰写者自行编造的渠道专属规范。event-cultural-identity 已对此作出决定：身份固定，只有表达方式会调整。

菜单 4 - 活动结束后的收尾

Q7 对一次性或持续累积的回答决定了此菜单，因此在排序前先询问。

档位：

• 保持所有内容开放。
• 只读归档。
• 导出，并在注明的保留期限结束后按计划删除。
• 移交至长期运营的社区空间。

排序：

• 价值：参加者若在下一届回归，仍然可以联系到：移交 > 保持开放 > 只读归档 > 导出 + 按计划删除
• 价值：活动不再维护的内容，不应继续以活动的名义发声：导出 + 按计划删除 > 只读归档 > 移交 > 保持开放
• 工作量（收尾所需的小时数、协调工作，以及之后需要持续关注的人）：移交 > 导出 + 按计划删除 > 只读归档 > 保持开放
• 合规成本（触发的审查，以及撤销操作的成本）：导出 + 按计划删除 > 保持开放 > 移交 > 只读归档
• 效率：只读归档 > 导出 + 按计划删除 > 移交 > 保持开放

在六组比较中，有五组的可联系性与免责性彼此冲突，因此没有任何一组占优。效率这一项依赖下文对各档位的比率论证和 Q7，而非支配性检查。完整论证请参阅 references/menu-ranking-rationale.md。

这五种排序、四个档位和合规成本这一维度均为本技能自行构建，并非实测排名。但这不代表合规成本可以轻描淡写。切勿将其简化：

• 导出并删除的合规成本最高：这是唯一无法撤销的档位，也是唯一要求你在采取行动_之前_就明确合法依据和保留期限的档位。
• 保持开放位居第二，原因恰恰相反：它完全不会触发审查，而问题就在这里——该空间仍需履行行为准则方面的义务，却无人负责。
• 移交涉及征求同意，因为将人们移至新空间意味着用途发生变化。
• 只读归档的合规成本最低：内容保留在原发布位置，适用已接受的条款，也不会新增内容。

不要提及任何司法管辖区，不要引用任何保留期限，并将实际的保留期限决定交由组织者自己的法律顾问处理：这取决于司法管辖区、平台条款和年份。

各档位说明：

• 只读归档 - 默认选项：冻结发布，保留内容可见，并发布通知，说明空间已关闭以及可转去哪里。以最低成本结束持续的管理义务，且不会销毁任何内容。
• 导出 + 按计划删除 - Q7 表示活动为一次性时的默认_升级_选项：导出数据，提前在频道公布删除日期，然后删除。一次性活动的成员名单是一项负担，因为没有下一届活动可供利用。
• 移交至长期运营的社区空间 - 不受重视的档位：可联系性最高，工作量也最大。升级条件必须同时满足两项：Q7 表示会持续累积，并且已有长期运营的空间，或已有明确指定的人承诺负责运营。移交到无人负责的空间，无非是多了几个步骤的保持开放。与 samber/dev-event-organizer-skills@event-community-building 协调；该技能负责接收端，并会在下一届活动开始筹备时交还活跃成员名单。
• 保持所有内容开放 - 效率排名最后：收尾时成本几乎为零，但也是唯一会让持续义务永无止境的档位。
• 删除，而非降级 - 悄无声息地收尾。 不告知频道成员就关闭或清空频道。这会摧毁人们对在那里发布的公告的信任，而下一届活动的频道从一开始就处于不利位置。
• 有条件地删除 - 当 Q8 表明关闭日期后无人值守时，保持所有内容开放。 以活动名义运营却无人管理的空间，意味着承担行为准则方面的义务，却无人响应；数字骚扰警示对此同样适用，正如活动期间一样。

失败模式

• 没有明确用途的频道。 因为类似活动有频道，于是也创建了一个；到了第二周就无人问津，之后却承载了那条真正重要的信息。每个频道都必须说明用途和负责人，否则就不创建。
• 创建了无人负责发帖的频道。 真正触达参与者的是频道的 人员安排，而不是频道的 存在——请参阅 references/channel-roster-and-platform-notes.md，了解此问题所源自的已发布混合活动案例。
• 由声音最大的人决定信息发往何处。 谁手边有手机，谁就发到自己已经加入的地方。发布者所在之处必须有明确的路由规则，否则就等于没有规则。
• 把聊天空间当成免费的。 设置需要一小时。整个活动期间都需要持续有人负责管理，并承担与现场相同的行为准则职责。
• 只在参与者已经聚集的地方发布突发情况。 需要收到场地变更消息的人还没到场，也没有关注聊天。突发情况应按类别升级到能主动推送消息的频道，而不是图方便选择频道。
• 等活动结束后再决定如何收尾。 到那时，原本负责收尾的人已经回家了，频道会意外地继续开放，而不是经过有意决定后继续开放。
• 每个频道都重新打造一种语气。 Menu 3 的删除规则已涵盖此问题。其表现是整场活动听起来像四场不同的活动。

衡量方式

以下所有阈值均由你自行设定，并非经过测量的基准值。请在活动前确定每一项，切勿等数据出来后再定。

• 重复发送率（自设）：因第一条消息未触达而必须在第二个频道重发的消息占比。每次重复发送都意味着路由规则有误，或频道无人负责。请预先设定上限。
• 未路由问题（自设）：没有负责人接收的问题，例如个人私信、社交媒体回复或演讲者的收件箱。统计数量并记录问题最终出现的位置。这就是你缺少的频道或目录条目。
• 频道静默（自设）：任何频道在预先设定的一段时间内没有组织者发帖。静默频道是下一届活动的删除候选项，而不是管理问题。
• 按计划发送调查消息（二元）：活动后的调查链接在预先设定的时间，通过路由规则指定的频道自动发出。回复率归入 samber/dev-event-organizer-skills@event-feedback。
• 完成收尾（二元）：每个已开放的频道都有关闭状态和日期，并在计划收尾当天完成。这里仅有这一项关卡可以明确判定通过或未通过。
• 参会者满意度和回归率应针对整场活动衡量，而不是针对频道。它们归入 samber/dev-event-organizer-skills@event-feedback 和 samber/dev-event-organizer-skills@event-market-fit。

调用示例

• “我们有 400 名已注册参会者，活动当天有两条议程。需要建群聊空间吗，还是电子邮件就够了？”
• “活动期间我们三个人会发布更新，但听起来总像不同的人在说话。怎么在不增加审批瓶颈的情况下解决？”
• “活动开始前两周，场地变更了，结果有一半参会者没收到通知。那条消息本该发到哪里？”
• “会议一个月前就结束了，聊天空间却还开着，而且没人看管。我们该怎么处理？”

预期输出：一套频道架构，包含：

1. 频道名册，每个频道都注明用途、负责人和开放日期。
2. 消息类别清单，以及所选详细程度下的路由规则。
3. 矩阵中所选级别对应的升级层级。
4. 一致性流程；达到银行级或更高级别时，还应提供书面模板。
5. 将频道名册交给 event-marketing-plan 的频道目录，而不是另建一个与之竞争的页面。
6. 数字空间的行为准则检查，以及指向 CoC 同级技能的路径。
7. 每个频道的收尾决定和日期，并在活动前确定。

每项自设内容都应明确标注。按章节逐一呈现，供人审核。

参考资料

• references/channel-roster-and-platform-notes.md - 已发布的频道列表、各频道的职责、从黑客马拉松迁移到会议时不适用的内容、数字空间行为准则，以及平台类别说明。
• references/message-class-matrix-and-message-bank.md - 消息类别体系、包含升级层级的路由矩阵示例、反面示例，以及 8 个消息库模板。
• references/wind-down-and-status-page.md - 每个阶段的 4 份收尾清单、交由法律顾问审阅的事项列表，以及状态页模式和不适用的内容。

全文引用的相关技能：参见 § 相关技能各司其职，以及 samber/dev-event-organizer-skills@event-cultural-identity（用于设定各频道所表达的语域；请先运行此技能）。