危机公关为您的团队提供清晰的第一声
当事件引发的问题超出常规社区更新范畴时，危机公关能帮助Web3团队做出回应。我们与您的人员合作，将已确认的信息转化为面向成员、合作伙伴和媒体的简洁、有用的信息。
通常，首要选择是在一份简短的暂缓声明和一份更全面的解释之间做出。暂缓声明可以承认问题，说明已确认的内容，并引导人们关注下一次更新。当您的项目负责人已核查足够细节来描述影响或行动时，更全面的解释才合适。我们帮助您避免用猜测来填补信息空白。
首先，收集事件时间线、原始材料、当前的公开帖子以及能够批准措辞的人员姓名。如果讨论主要是社区困惑，我们的指南如何处理加密社区中的FUD可能会有所帮助。对于紧急回应之后的更广泛工作，在线声誉管理可以处理持续的公众疑问。我们专注于清晰的沟通；您的技术和法律负责人仍对其专业发现负责。
围绕三项核查构建首次回应
一个有用的首次回应，应区分已知信息、正在核查的内容以及读者下一步该做什么。我们利用这个简单的结构，帮助您的团队从一堆信息中提炼出人们能理解的措辞。
- 核查来源。 确定谁报告了问题，以及有哪些主要证据可用。保存截图、通知或技术说明，并附上其来源和接收时间。
- 标记事实。 将已确认的细节归为一组，将未解决的声明归为另一组。将每个未决点分配给能够核实它的人员。
- 设定下一次更新。 商定官方信息将在哪里发布，以及由谁批准。如果您无法给出下一次更新的具体时间，请说明触发它的事件或确认条件。
假设一份下架通知到达您的团队，而成员们正在分享相互矛盾的解释。我们会首先将通知与项目自身的记录进行比对，然后起草一份简短的回应，说明已确认的内容。如果原因仍不清楚，措辞应直截了当地说明，而不是提供一种推测。当情况需要正式的媒体分发时，我们可以将已批准的信息与新闻稿分发服务对接。
当事件是漏洞或下架时，信息如何调整？
沟通计划会随着您的团队能够确认的事实以及人们需要回答的问题而变化。我们确保每条信息都与其来源、受众和审批路径紧密关联。
对于漏洞或疑似安全漏洞
让技术事件负责人设定公开细节的边界。声明可以说明受影响的产品，描述调查状态，并且仅在负责团队批准后，才分享用户操作步骤。不要包含未经批准的私人用户信息或运营细节。如果原因或影响仍未知，请说明正在审查的内容，但不要暗示结论。
对于下架新闻
确认通知、受影响的资产或服务，以及相关平台提供的面向用户的指引。项目可以解释其已采取的行动，例如联系平台，但仅在该行动已发生并获得披露批准之后。将关于平台理由的猜测排除在官方声明之外。
对于FUD和公开批评
将声明分类，判断哪些需要事实纠正，哪些需要直接回答，哪些更适合提供支持渠道。一个带有证据的简洁回复可能有所帮助；但重复每一个未经支持的声明可能会分散人们对有用信息的注意力。当您的团队拥有稳定的事实和明确的发言人时，我们的公关与媒体服务可以为后续解释提供支持。
让回答问题的人员保持信息同步
您的社区不仅通过声明，也通过人员来接收回应。我们帮助管理员、创始人和支持人员共享一份经批准的措辞来源。每个人都知道该回答什么，以及将更难的问题转交给谁。
设想一个Discord服务器，有一位兼职管理员，正处于测试网和主网之间。当项目团队正在核查一个事件时，出现了一条令人担忧的帖子。我们会帮助管理员使用一条简短、经批准的回复，并将成员引导至官方更新频道。我们会将技术问题发送给指定的负责人。
一个实用的交接可以包括：
- 给管理员和支持人员的简短回复。
- 给创始人或经批准的发言人的谈话要点。
- 一份清晰标注未解决问题的问题与解答。
- 一份显示官方更新所属频道的列表。
例如，假设合作伙伴要求解释，而社区成员想要即时的用户指导。我们可以根据相同的已确认事实准备不同的版本。两者都应指明相同的官方来源，同时各自回答受众的真实问题。您的团队在措辞发布前进行批准。
随着事实变化，保持公开记录的有用性
一个强有力的回应始终与证据保持联系，随着事件的发展而更新。我们可以准备声明、谈话要点、问题与解答以及商定的外联，然后保留审批记录、发布链接和后续问题。当新事实改变先前的信息时，请使更正清晰可见，并引导读者查看当前说明。
交易所或其他平台会自行决定是否进行下架审查。新闻编辑室会决定是否报道事件以及如何报道。社交平台控制帖子的可见性和审核；我们可以执行您批准的沟通工作，但无法左右这些决定。
在紧急交流平息后，请将原始声明、后续更新及其来源整合在一起。记录哪些问题仍未解决，并指定每个后续答案的负责人。如果事件需要更深入的解释，创始人访谈与专题报道可能适合下一阶段。您的团队应准备好公开发言。
要开始，请向Brand Community发送一份简短的事件时间线、相关通知或帖子、已确认的事实以及您的审批人姓名。我们将与您的联系人一起审查这些材料，确定需要解决的首要信息缺口，并就您的团队所需的信息达成一致。
如何操作
- 分享当前情况发送时间线、原始材料、公开信息以及负责核查事实的人员的联系方式。标记哪些是敏感信息或未经批准不得分享的内容。
- 区分事实与未决问题我们与您指定的负责人合作，将已确认的细节与仍在审查中的问题分类。每个未决问题在您方都有明确的负责人。
- 为需要答案的人起草信息我们用平实的语言准备经商定的声明、谈话要点或问题与解答。每条信息都反映其受众和渠道。
- 获得正确审批您授权的发言人和相关顾问审阅文案。未经您的团队要求的批准，任何内容都不会发布。
- 协调并保留记录我们帮助在商定的渠道上协调已批准的更新，并记录发布链接、外联活动和后续问题。
常见问题
在您起草首次更新之前，我们应该发送什么？
发送一份简短的时间线、引发关注的通知或帖子、您的团队已确认的内容以及仍未知的信息。包括任何已分享的回应，并注明能够核查技术细节和批准措辞的人员姓名。例如，一份下架通知及其来源有助于我们区分官方通知和社区讨论。
当漏洞报告仍不清楚时，您能提供帮助吗？
可以。一份暂缓声明可以承认该报告，仅分享事件负责人已确认的信息，并将读者引导至官方更新频道。它不应猜测原因或影响。我们可以清晰标记未解决的问题，然后在您的技术负责人批准新事实后修改信息。
如何让下架回应听起来不像是最终结论？
我们描述已确认的状态，但不暗示平台做出了不同的决定。如果您的团队已联系平台或正在审查后续步骤，声明可以在该行动得到确认后如实说明。在已知状态和未来行动之间划清界限，有助于成员理解发生了什么。
我们应该回复Discord或X上的每一条批评帖子吗？
不。我们帮助将帖子分类，判断哪些需要事实纠正，哪些需要支持性回答，哪些最好不予放大。例如，关于某个用户操作的重复问题，可能更适合放在一条置顶的官方更新中，而不是许多单独的回复里。然后，管理员可以将成员引导至该来源。
您的团队能多快开始审查事件？
当项目联系人分享现有证据时，我们就可以开始。他们还应让我们与能够核实事实和批准信息的人员建立联系。工作节奏随后取决于这些核查和审批。如果细节仍然缺失，我们可以在起草依赖这些细节的措辞之前，先确定未解决的问题。
您能让交易所或新闻编辑室改变其决定吗？
不能。相关平台控制其自身的下架决定，每个新闻编辑室自行决定是否发布。我们可以准备准确的材料，协调经批准的外联活动并记录后续情况，但无法保证逆转、报道或删除他人的帖子。我们的承诺仅限于与您的团队商定的沟通工作。
告诉我们您的项目
回答四个简单问题，经理会在1小时内为您发送方案、时间表和价格范围。全程保密。
正在加载表单…