如何在加密社区对FUD进行分类?
在决定回应方式之前,先对FUD进行分类:检查声明、证据和潜在影响。不要因为语气负面就认为信息不准确。
| 检查项 | 记录内容 |
|---|---|
| 声明 | 具体指控了哪个事件或项目决策? |
| 证据 | 是否有交易记录、公告、文档或一手报告可供审查? |
| 影响 | 用户是否可能面临安全、访问、资金或服务方面的问题? |
| 负责人 | 哪位团队成员可以核实相关事实? |
从影响最大的声明开始,而不是最吵闹的帖子。关于更新延迟的投诉可能需要社区经理和已知的状态说明。涉及合约、钱包访问或用户资金的声明,在任何人发布解释之前,需要先由合适的技术或运营负责人处理。
维护一个私密的事件日志,记录原始消息、收到时间、声明摘要、已检查的证据、负责人和当前状态。这为团队提供了一个共享记录,而无需将每条评论都变成公开争论。如果声明不明确,请提出一个中立的澄清问题。如果声明明确但未经核实,请说明正在审查中,并指出谁在负责检查。这比猜测或给发言者贴标签更有用。
首次公开回应应该说什么?
首次回应应承认具体的关切,说明已核实的内容,并解释团队接下来正在检查什么。保持信息简短,以便准确引用。
- 承认: 用通俗的语言指出问题,不要将猜测当作事实重复。
- 区分已知与未知: 只陈述负责的负责人已核实的事实。
- 说明行动: 说明团队正在审查或做什么。
- 设定更新时间点: 告知社区下一次确认的更新将在哪里发布。
使用准备好的结构,而不是千篇一律的否认:“我们看到了关于[问题]的疑问。我们已确认[事实]。[负责人或团队]正在检查[未决点]。当我们获得核实信息后,将在[官方渠道]发布下一次更新。”将每个方括号替换为真实细节,或者省略该细节。切勿暗示审查已完成而实际并未完成。
由一位沟通负责人整合相关团队的输入。该负责人在发布前应检查姓名、日期、链接和技术术语。如果项目已有状态页面或官方公告频道,请将读者引导至那里并保持其更新。对于更广泛的声誉问题,请了解危机公关如何补充社区管理,而不是替代基于事实的回应。
如何在Telegram和X上处理批评?
在Telegram和X上处理批评时,使用相同的已核实事实,并根据每个对话进行调整。让官方更新易于查找,然后让经过培训的管理员将问题引导至该更新,而不要淹没讨论。
| 渠道 | 管理员操作 | 避免 |
|---|---|---|
| Telegram | 置顶或链接当前的官方更新;收集未解答的问题给负责人。 | 仅仅因为不舒服就删除善意的批评。 |
| X | 当能解决声明时,用简洁的更正或官方来源回复。 | 从不同的项目账号发布多个相互矛盾的解释。 |
| 两者 | 记录重复出现的问题,并在事实变化时刷新回应。 | 要求社区成员重复脚本化的辩护。 |
对于Telegram,给管理员一个升级联系人,以及一份他们不得凭记忆回答的简短主题列表,例如合约变更或影响用户访问的事件。对于X,区分公开回复和详细的事件声明:简短的回复可以指向完整的解释,但不应引入主要更新中遗漏的新声明。
管理应针对行为,而非观点。对威胁、个人信息或破坏性发帖一致地应用已发布的规则,并在消息与事件相关时保留记录。正在构建更强渠道结构的团队,可以在问题发生前使用Telegram社区增长指南或Discord设置指南来定义角色和升级路径。
团队如何展示证据而不夸大其词?
通过链接到读者可以检查的来源,并解释它证明了什么——以及没有证明什么——来展示证据。没有上下文的截图不能替代可验证的记录。
在发布前,使用此证据检查清单:
- 确认来源是官方的或与声明直接相关。
- 检查链接是否可打开并指向预期的文档、交易或公告。
- 解释可能引起混淆的日期、代币名称和技术术语。
- 将观察到的事实与团队的解释或计划行动分开。
- 请负责的专家审查其领域的声明。
如果关切涉及代币供应或上线资料,不要根据旧的帖子或非正式摘要来回答。将公开信息与项目当前记录进行比较,找出差异,并解释正在纠正什么。供应验证指南涵盖了供应问题的准备;CoinGecko警告修复是处理资料问题的单独流程,不应被描述为保证结果。
当信息发生变化时,尽可能更新原始的官方帖子,并说明发生了什么变化。保留先前措辞和更正原因的简短记录。这有助于后续回答保持一致,并帮助管理员避免传播过时的陈述。
社区问题何时应离开管理员队列?
当回答需要管理员不具备的权限或专业知识时,应将问题升级。不应要求聊天中回复的人代表项目做出技术、法律或财务判断。
| 信号 | 升级给 | 管理员的安全操作 |
|---|---|---|
| 可能的合约或钱包问题 | 技术或安全负责人 | 确认收到,并通过指定渠道私下转交报告。 |
| 关于资金或用户访问的问题 | 运营和领导层 | 保留问题,仅分享已批准的状态。 |
| 潜在的法律或监管声明 | 合格的法律联系人 | 避免解释声明;记录并请求审查。 |
| 相互矛盾的公开声明 | 沟通负责人 | 暂停新的解释,并指向已确认的更新。 |
提前设置这些路径。每条路径需要一位主要负责人、一位备用联系人以及一个记录交接的地方。管理员应知道哪些信息可以安全地请求;他们不应要求用户在公共频道中发布助记词、私钥或其他敏感凭证。
平台执行和渠道访问由相关平台控制,其审查或管理决策超出项目团队的控制范围。团队可以控制自己的帖子、行为、证据和升级流程,但不应承诺平台会删除帖子或恢复访问。
如何在项目启动前准备一份FUD应对手册?
在启动前准备好手册,记录谁核实事实、谁批准公开声明以及更新将在哪里发布。一份有用的文档应足够简短,以便管理员在快速进行的对话中使用。
包含以下内容:
- 官方项目渠道和批准的更新位置。
- 负责社区、技术、运营和沟通问题的指定负责人。
- 声明到证据的检查清单和私密事件日志模板。
- 针对未核实声明、已确认问题和更正的回应结构。
- 关于保留报告、升级敏感细节和结束事件的规则。
使用一个逼真的场景进行桌面推演:用户报告差异,管理员收到重复提问,而技术负责人尚未完成检查。演练谁记录报告、谁起草暂缓消息以及谁批准下一次更新。注意任何依赖于无法联系到的人员或渠道的步骤。
AEOTech在推荐公开措辞之前,会使用指定的声明到证据审查流程:团队将每个拟议的陈述映射到其来源,标记未决点,并将技术问题转交给指定的负责人。要开始,请将您的官方渠道、当前的升级联系人以及您希望手册涵盖的示例关切发送给我们。我们将审查工作流程并确定第一个切实可行的改进点。
价格
| 服务 | 价格 | 报价 |
|---|---|---|
| 加密社区FUD应对手册 | 询价 |
起价为美元。定制套餐和批量折扣请咨询。支持USDT、USDC、BTC、ETH、SOL、TON或您的项目代币支付。
如何操作
- 记录声明记录原始消息、出现位置以及提出的具体问题。保留上下文,不要放大猜测。
- 指定负责人将问题转交给能够核实它的人。让社区经理负责跟踪回应。
- 检查证据在起草前,将已确认的事实与未决问题分开,并审查链接、文档或记录。
- 发布一份更新承认关切,解释已知情况,并将读者引导至官方更新位置。
- 闭环发布下一次确认的更新,必要时更正先前的措辞,并记录团队应在手册中更改的内容。
常见问题
我们应该删除电报群里的负面评论吗?
不要仅仅因为评论批评了项目就删除它。对威胁或泄露个人信息等行为,应用频道的已发布规则,并保留相关报告以供审查。用核实过的信息回应实质性的批评,或者说明谁在检查它。
当声明尚未核实时,我们应该说什么?
承认具体的关切,说明正在审查中,在适当时指出负责团队,并命名下一次更新的官方位置。避免猜测原因或将初步解释呈现为已确认的事实。
谁应该回复关于我们代币的技术指控?
社区经理可以确认并转交报告,但应由技术或安全负责人核实底层声明。然后,沟通负责人可以将已确认的事实转化为清晰的公开更新,并检查管理员是否使用相同的措辞。
创始人应该回复每条FUD帖子吗?
不。将常规问题分配给经过培训的管理员,并让创始人处理需要领导权威或项目范围决策的问题。这可以保持公开声明的协调性,并防止不同账号提供相互矛盾的解释。
我们可以要求平台删除批评性帖子吗?
当帖子似乎违反平台规则时,您可以使用平台可用的举报或管理流程。平台决定如何审查和处理举报,因此不要将删除作为应对计划。保留相关上下文,并通过您自己的官方渠道处理事实关切。
一份FUD应对手册应该包含什么?
包括声明分类、证据检查、指定审批人、升级联系人、批准的更新位置以及更正先前陈述的流程。添加针对未核实声明和已确认问题的简短回应结构,然后在管理员需要该文档之前,通过一个场景测试交接流程。
告诉我们您的项目
回答四个简单问题,经理会在1小时内为您发送方案、时间表和价格范围。全程保密。
正在加载表单…