代币发行营销检查清单：T-60 至 T+30

代币发行营销检查清单应管理哪些内容？

代币发行营销检查清单应管理决策、负责人和就绪关卡，而不仅仅是发布日期。首先定义发行范围：发行什么、哪些受众需要准确信息、哪些渠道已获批、以及谁有权批准公开声明。

创建一个包含以下字段的单一事实来源文档，用于每个工作项：

• 交付物： 资产、提交内容、公告或运营任务。
• 负责人： 对完成负责的一个人，并为发行周指定一名后备人员。
• 审批人： 在任何内容发布或提交前所需的审核人。
• 依赖项： 必须首先完成的决策或输入。
• 证据： 显示完成的链接、截图、确认或注明日期的备注。

将已确认的事实与计划中的功能和未决决策分开。代币供应量、分配细节、合约地址、销售条款、产品可用性以及交易所或平台状态应有明确的来源和审批负责人。如果某个事实发生变化，记录谁负责更新网站、置顶的社区信息以及已安排的内容。这可以减少跨渠道的矛盾陈述。

在每个阶段使用一个发行关卡：只有在必要的信息和审批到位时才继续，或者记录未解决的项目及其负责人。有关发行规划的更全面概述，请参阅代币发行与增长。

T-60 至 T-31：团队应首先确定什么？

在 T-60 时，在委托制作大量宣传材料之前，先确定项目叙事、审核职责和发行限制。这是识别可能改变代币公开解释或发行顺序的决策的时候。

在此阶段准备：

• 简洁的项目描述、受众定义和经批准的产品事实。
• 一份代币信息表，涵盖供应量、分配、归属或解锁细节（如适用），以及每个数据的来源。
• 渠道清单：网站、社区空间、社交资料、媒体联系人和计划中的平台提交。
• 沟通审批路径，包括谁可以暂停或修改已安排的内容。
• 针对可能的问题、运营中断和不准确的公开声明的风险与应对登记表。

请相关的法律和合规顾问在相关司法管辖区审阅项目计划的沟通和分发。营销人员不应自行做出法律决定。如果某个决策悬而未决，将其标记为“待定”，并将依赖该决策的文案保留为草稿，而不是将假设当作已确定的事实呈现。

只有在团队就目标及其能够证实的内容达成一致后，再选择活动形式。如果项目是 Meme币，请使用量身定制的 Meme币发行指南 来检查额外的社区和披露注意事项。在此阶段结束时，团队应了解其能准确说什么、在哪里说以及谁批准每条信息。

T-30 至 T-8：如何准备发行渠道？

从 T-30 到 T-8，将经批准的项目信息转化为一致且可审核的渠道材料。目标不是一次性在所有地方发布，而是确保每个目标渠道准确、就绪并配备人员，然后发行日程才会密集起来。

准备一个内容矩阵，包含渠道、受众、格式、负责人、审批状态和预期的发布窗口。包括主要公告、产品和代币的简短说明、通俗易懂的风险解释、社区管理回复以及用户验证官方信息的途径。确保网站、社交资料和社区渠道中的声明保持一致，并删除依赖未解决的产品或上线细节的草稿。

对于社区就绪，确认管理员覆盖范围、升级联系人、置顶信息以及纠正过时帖子的流程。Telegram 社区增长指南 可以帮助团队规划社区运营，而不会将持续参与与发行日的峰值混淆。如果创作者或 KOL 是计划的一部分，请记录交付物、披露期望、审核窗口和发布状态；请参阅加密 KOL 活动指南。

将平台提交作为一个单独的工作流进行准备。在提交前，检查相关平台当前的申请说明、所需项目信息和状态显示。上线准备不等于批准；在平台确认状态之前，保持公开措辞精确。指派某人保留提交记录并监控澄清请求。

T-7 至发行日：哪些内容必须再次检查？

在发行周，再次验证运营事实和审批，而不是依赖之前准备的草稿。最终就绪审核应将网站、社交帖子、社区置顶、项目文档和任何发行说明与最新的批准信息进行核对。

使用一个“执行/不执行”检查清单，涵盖：

• 跨公共渠道的正确官方链接和账户所有权。
• 最终批准的文案、创意资产和已安排的发布窗口。
• 社区管理、技术升级和公共更新的指定负责人。
• 如果项目细节发生变化，发布更正的经过测试的路径。
• 项目团队、沟通支持和技术联系人之间确认的交接。

保留一份单一的发行日运行表，包含时间窗口、负责人、依赖项和状态字段。实时记录完成情况；避免仅依赖聊天消息作为审计追踪。如果外部平台尚未确认上线或功能，不要暗示其已确认。如果发行时间或技术细节发生变化，暂停受影响的内容，更新事实来源，然后重新批准修改后的信息。

在 MegaSatoshi，发行就绪审核会同时检查负责人分配、已批准的声明、渠道一致性和未解决的依赖项。这为团队在预定沟通上线前提供了一份具体的更正清单，而不是在公开后发现矛盾的材料。

T+1 至 T+30：如何管理发行后的营销？

从 T+1 到 T+30，将沟通视为一项持续的运营责任，而不是发行帖子的最后冲刺。为产品更新、社区问题和更正建立节奏，每个渠道都有负责人，并对有关可用性或项目进展的声明进行审核流程。

跟踪支持决策的证据：发布了哪些材料、哪些问题重复出现、哪些链接或说明需要更正、以及哪些承诺仍未解决。一个有用的更新日志记录日期、问题、决策、负责人和后续行动。定期分享简洁的内部摘要，以便领导层能够看到已完成工作、用户反馈和未解决的运营问题之间的区别。

审查社区和活动质量，而不仅仅是数量。检查用户是否能找到官方信息，管理员是否能引导技术问题，已发布的内容是否仍然准确，以及活动合作伙伴是否已交付约定的材料。如果计划进行空投或激励活动，请根据项目批准的规则协调其沟通、资格说明和支持流程；不要因社区压力而即兴制定条款。

利用此阶段结束来关闭未完成的发行任务并更新下一个沟通计划。对于特定平台的发现工作，请查阅相关的 CoinGecko 热搜 和 DEXScreener 热搜 指南，并将其不同的要求和状态更新与项目自身的营销日历分开。

客户应准备什么，营销团队应提供什么？

清晰的交接使检查清单可执行：客户提供经过验证的项目输入和决策者，而营销团队将这些输入组织成经批准的交付物和可追踪的时间表。在工作开始前就职责达成一致，这样缺失的事实就不会成为无人负责的发行风险。

客户准备：

• 当前的项目描述、网站和官方渠道链接。
• 经批准的代币信息及其支持性源文件或记录。
• 发行目标、受众优先级、目标市场和已知依赖项。
• 产品、技术、法律和沟通审核的指定决策者。
• 任何现有的平台申请、合作伙伴承诺或已安排的公告。

**营销团队提供：

• 映射到 T-60 至 T+30 的发行日历，包含负责人和审批点。
• 消息和资产清单，将项目标记为草稿、审核中或已批准。
• 基于约定范围的特定渠道文案和运营说明。
• 发行就绪审核、问题清单和已完成工作的报告格式。
• 已发布材料、更正和未决后续行动的发行后日志。

在启动时，就客户审核材料的速度以及当主要联系人不在时谁可以批准更改达成一致。MegaSatoshi 使用一个指定的审核步骤来检查声明是否与提供的项目信息相符，并标记出需要客户解决的差距；项目保留对其事实和最终审批的权力。如果您需要帮助决定哪些工作流应包含在计划中，请将范围与代币发行营销支持进行比较。

平台审核与发行就绪在哪些方面可能不一致？

项目可能已准备好进行沟通，而第三方平台的审核或显示状态仍未解决。在检查清单中将这两种状态分开，并使用平台自己发布的说明和账户通知来管理提交和后续行动。

CoinGecko 和 CoinMarketCap 各自有自己的上线流程和公开状态信息；在平台确认之前，不应将提交、资料更新或更正请求描述为批准。同样，交易界面上的可见性或位置由该平台控制，并且可能独立于项目的内容日历而变化。记录已提交的材料、请求的更改和已确认的状态，然后仅沟通项目能够验证的信息。

一个实用的应急措施是准备两个版本的发行沟通材料：一个用于已确认的平台状态，另一个在不暗示该状态的情况下描述项目。指派一名负责人检查平台消息，并在状态发生变化时更新已批准的文案。相关的 CoinGecko 上线指南 和 CoinMarketCap 上线指南 可以帮助团队组织提交准备工作。

没有营销团队能控制平台的审核决定、时间安排、资格评估或展示轮换；可控的承诺是准备准确的材料、提交约定的工作并报告已验证的状态。将您的发行窗口、项目简介和当前的就绪检查清单发送给 MegaSatoshi 以开始审核；下一步是一份带有负责人和优先级的范围化差距清单。

价格

起价为美元。定制套餐和批量折扣请咨询。支持USDT、USDC、BTC、ETH、SOL、TON或您的项目代币支付。

如何操作

1. 设定发行范围确认发行目标、受众、渠道和仍悬而未决的决策。为每个工作流指定一个负责任的负责人。
2. 验证项目事实收集经批准的代币、产品和分发信息，并为每个实质性声明提供来源。将法律和合规问题转交给客户的顾问。
3. 构建 T-60 至 T+30 日历映射交付物、依赖项、审核人和发布窗口。将平台提交与已确认的平台状态分开。
4. 运行就绪审核同时检查渠道链接、已批准的文案、负责人、升级联系人和未解决的项目。在预定沟通进行前记录更正。
5. 监控并关闭后续事项跟踪已发布的材料、更正、社区问题和未决承诺直至 T+30。使用日志来塑造下一个沟通计划。