开场前留一张应急安排表
邀请确认后，社区运营还要拿到内容授权和联络信息。只写“嘉宾已答应”不足以决定临场怎么处理，可把以下字段放在同一张表里：
- 可回答范围：本次覆盖的功能、适用版本、公开资料链接，以及由谁批准这些内容。未发布计划、个别账户问题和其他受限资料列在范围之外。
- 原定嘉宾与替补联系人：分别填写姓名、职责、联系渠道、可联系的时间范围。联系人负责找到合适回答人；是否能作为替补嘉宾发言，仍要确认本人职责及授权范围。
- 现场决策人：写明谁能批准继续、调整议题、延期或取消。主持人负责宣布已经作出的决定，不自行改变活动安排。
- 通知草案：保留原定主题、变动原因的可公开表述、当前处理方式、提问入口、后续更新位置。新时间未确认就留空，不把拟议日期放进通知。
例如，嘉宾临时无法参加但尚未确定后续安排，可使用草案：“原定产品嘉宾今天无法参与。本场先收集相关问题，已公开的信息仍可查阅置顶资料；新的问答安排确认后将在此处更新。”如果收集环节也取消，通知应直接写明活动取消及问题保留方式，不能让成员继续等待。
Discord 的 AMA 指南对提问入口给出一个可选安排：
You may also want to add a questions channel
Discord AMA 与社区问答指南
这是收集问题的入口建议，不是嘉宾缺席时由谁作答的授权。活动改为收集问题后，仍要确认问题去向与公开范围。
主持、内容批准和后续联系可参照公开社区协作中的角色分工分别记录，避免几个角色共用一个模糊的“运营负责人”。
每个问题都说明当前能答到哪里
现场遇到“这个功能下周会不会开放”之类的问题，先查可公开的资料，而不是根据日常聊天判断。问答记录可分三种情况处理：
- 已有批准的公开内容：注明资料日期与适用范围，按原意转述，并提供原文入口。资料只讲当前版本，就不延伸到未来版本。
- 尚待确认的问题：保留成员原话和必要背景，标记“待产品负责人确认”。主持人可以追问使用场景，不给出倾向性结论，也不把“已转交”写成“已解决”。
- 不能公开的资料：说明该部分不能在社区讨论；如涉及个人账户，指向已经确认的私下支持入口。内部记录只保存跟进所需信息，公开汇总不带敏感细节。
决定是否继续时，看的是剩余议题有没有合适回答人。公开资料足以回答的基础问题可以继续；主要问题都依赖缺席嘉宾，则应尽早结束问答部分。主持人无需用连续追问撑满原定时长。活动日期、入口和置顶信息的维护，可以放进Discord 社区日常运营安排一起检查，保持成员看到的通知一致。
结束后让未答问题有去处
建立未答问题表，至少保留问题原文、提出位置、公开范围、实际负责人的姓名与职责、转交记录、当前状态和答复入口。若负责人尚未接收，状态应是“待接收”，不能先写成“正在处理”。内部联络方式不放进面向成员的表格。
后续状态可以使用“待接收、待确认、已答复、无法公开答复”。每次变更都记录实际更新时间及依据。负责人确认答复后，运营人员按授权内容回到原提问位置，或链接至公开汇总；问题没有答案，也保留其状态，不把记录改写成已完成。
复盘时逐条查看问题有没有去向、责任人是否接收、成员能否找到更新。没有成员提问就如实记录，不补写互动；嘉宾没有回应就保留未答状态，不编写专家回复。下一场邀请前，再根据未答问题收窄议题，确认需要哪些回答人到场。
想先看你的品牌现在在 AI 搜索里被怎么说?
领取免费增长诊断