トークンローンチチェックリスト：T-60からT+30

トークンローンチマーケティングチェックリストは何を管理すべきですか？

トークンローンチマーケティングチェックリストは、実用的な管理文書です。公開ストーリー、ローンチオペレーション、各決定の責任者を結び付けます。市場の反応を約束するものではありません。その価値は、チームが何が準備できていて、何がブロックされていて、次の活動を開始する前に誰がそのブロックを解決しなければならないかを把握できることです。

ライブレビューで使用できるよう、文書は簡潔に保ちます。各タスクについて、責任者、期限、承認連絡先、依存関係、完了の証拠を記録します。証拠としては、承認済みのアナウンス、動作するリンク先、提出済みのプラットフォームプロフィールなどが考えられ、他のチームメンバーが検証できるものでなければなりません。

4つのワークストリームから始めます：

• 準備状況： 承認済みのプロジェクト説明、トークン詳細、ドキュメント、連絡経路。
• コミュニケーション： オーディエンス、メッセージ、チャネル、言語、承認責任者。
• オペレーション： ローンチ当日の役割、エスカレーション経路、最新情報のソース。
• フォロースルー： コミュニティの質問、修正、パートナー連携、ステータス更新。

運用上の決定はプロモーションコピーから分離します。トークン配布、コントラクト詳細、ローンチタイミングが変更された場合は、公開資料を更新する前に、それを承認する権限のある人にその変更を回します。TGEに関する作業の全体像については、トークンローンチと成長およびトークンローンチマーケティングを参照してください。

T-60からT-31：ローンチの基盤を確立する

最初のフェーズは調整のためのものであり、公開を急ぐものではありません。T-60で、ローンチで何を達成するのか、どのオーディエンスが重要か、どの事実が外部使用として承認されているかを合意します。今、明確なブリーフを作成することで、後になってチャネルごとに異なるプロジェクト説明がされるのを防ぎます。

プロジェクト概要、トークンの目的、チェーン、関連リンク、ローンチシーケンス、チーム連絡先、想定される質問への承認済み回答を含む、単一の情報源を構築します。確認されていないことは、仮定で埋めるのではなく「保留中」とマークします。プロジェクトリーダーに、製品ステータス、トークン配布、タイミングに関する主張を承認できる人を特定するよう依頼します。

次に、依存関係に基づいて作業をマッピングします。例えば、公開アナウンスには承認済みの文言と動作するランディングページが必要な場合があり、クリエイターへのアウトリーチには確定したブリーフと明確な開示指示が必要な場合があります。誰かがドラフトを作成したという理由だけでタスクが完了したように見えないよう、依存関係を可視化します。

この期間に役立つチェック項目：

• プロジェクトの公開説明と主要な用語を確認します。
• 各ワークストリームに1名の責任者と1名の最終承認連絡先を割り当てます。
• チャネルマップを準備します：オーディエンス、目的、責任者、計画されたコンテンツタイプ。
• 創業者、法務、または技術的な対応が必要な質問を特定します。
• レビューのリズムを設定し、決定事項を同じ文書に記録します。

上場が計画に含まれている場合は、プロフィール準備と承認の前提を分離します。CoinGecko上場準備とCoinMarketCap上場準備の実践的な手順を確認し、提出とフォローアップを個別のタスクとして追跡します。

T-30からT-8：公開ストーリーを使いやすくする

このフェーズでは、承認されたプロジェクトの事実を、一貫性があり、レビューしやすく、選択したチャネルで使用できる状態の資料に変換します。目的はどこにでも公開することではなく、計画された各コミュニケーションを正確にし、明確な次のアクションに結び付けることです。

短いプロジェクト説明、より詳細な紹介、確認済みのローンチ情報、よくある質問への回答を含むメッセージセットを準備します。主張はプロジェクト資料に遡って確認できるようにします。製品がまだ開発中の場合は、将来の機能がすでに存在するかのように書くのではなく、現在の状態を正確に説明します。各項目に責任者と、ドラフト、レビュー、承認済み、スケジュール済みなどのステータスを付けます。

意味のあるマイルストーンに基づいて、小さなコンテンツカレンダーを作成します。誰が公開するか、誰がリンクを確認するか、質問はどこにルーティングされるか、基盤となる情報が変更された場合の対応を含めます。クリエイターやKOLの作業には、対象オーディエンス、必要なコンテキスト、提供形式、承認プロセス、開示の期待事項を記載した書面のブリーフを使用します。暗号資産KOLキャンペーンガイドはその作業の構成に役立ちます。KOL審査ガイダンスを使用して、潜在的なパートナーのレビューを計画します。

何かをスケジュールする前に、別の担当者が名前、トークン詳細、日付、リンク、連絡経路を情報源と照合して確認します。承認済みのバージョンを1つチームで利用できるようにし、古いドラフトは誤って再利用されないように廃棄します。

T-7からローンチ：誇大広告ではなく、引き継ぎをリハーサルする

ローンチ前の最後の期間は、引き継ぎを確認し、計画が変更されたときにチームが冷静に対応できるようにするためのものです。公開、質問への回答、修正の承認、技術的またはプロジェクトリーダーへの連絡を行う人々と一緒に、ローンチシーケンスをリハーサルします。

散在するチャットメッセージに頼るのではなく、時間枠を設定したローンチ当日のランシートを使用します。計画された各アクションについて、責任者、承認ステータス、公開場所、リンク先、バックアップ連絡先を示します。アクションを進める前に何が起こらなければならないかを別の行に記録します。例えば、スケジュールされた投稿は、そのテキストとリンクが現在の承認済み情報と照合されるまで公開されるべきではありません。

実用的な最終レビューでは以下を確認します：

• 新しい読者が、最初の公開説明からプロジェクトが何をするのか理解できますか？
• 計画されたすべてのリンクは、意図された現在のリンク先に正しく誘導されますか？
• コミュニティはどこで質問し、公式アップデートをどのように見つけるか知っていますか？
• チームは修正やタイミング変更を承認できる人を特定できますか？
• 運用上の詳細が未解決の場合の、一時停止とエスカレーションの明確な経路はありますか？

DEX向けの可視性計画については、キャンペーンとプラットフォームの決定の違いをチームが理解していることを確認します。ローンチコミュニケーションに含める前に、DEXScreenerとDEXToolsの準備ノートを読んでください。これらのタスクは、可視性の配置を確認し、そのステータスを報告できる責任者に割り当てます。

ローンチ当日：単一の情報源を維持する

ローンチ当日は、マーケティングリーダーが承認されたコミュニケーションを調整し、プロジェクトの技術的および意思決定リーダーがそれぞれの責任を処理します。チームには、ステータスのための現在の情報源、明確なエスカレーション連絡先、公開情報を修正するためのプロセスが必要です。

時間枠、アクション、責任者、ステータス、計画を変更した決定事項を記録したシンプルなライブログを保持します。何が公開され、どこで確認できるかを記録します。詳細がまだ確認されていない場合は、古いドラフトがそれを公開された主張に変えてしまわないようにします。質問を回答権限のある人にルーティングし、承認されたら共有情報源を更新します。

ローンチリーダーは、コミュニティの反応を有用で一貫性のあるものに保つ必要もあります。繰り返し発生する質問をグループ化し、承認された説明を参照するよう誘導し、技術的またはアカウント固有の質問は適切な連絡先に送ります。これは、すべてのチャネルに同じメッセージを繰り返すよう求めるよりも価値があります。エラーがあった場合は、関連するリンク先を修正し、適切な公式チャネルを通じて修正内容を説明します。

MediaStrategyがサポートするキャンペーンの場合、シニアアカウントリーダーはキックオフチェックリストを使用して、作業開始前にブリーフ、承認連絡先、チャネル計画、レポート形式を確認します。実行中、チームは完了した作業と可視性の配置の証拠を簡潔なステータスレポートに記録し、未決定の事項をクライアントに黙って決めるのではなくフラグを立てます。

T+1からT+30：ローンチ活動をフォロースルーに変える

ローンチ後の最初の1ヶ月は、コミュニケーションの正確性を維持し、未解決の質問をクローズし、運用計画のどの部分に注意が必要かを学ぶためのものです。チェックリストは最初のアナウンス後もアクティブに保つ必要があります。そうしないと、チームはローンチ週に行ったコミットメントを見失います。

コミュニティの質問、公開プロジェクト情報、パートナーの成果物、未処理の上場やプロフィール提出を定期的にレビューするスケジュールを設定します。各問題を責任者と次のアクションとともに記録します。公開説明を更新するときは、人々が詳細を確認するために誘導される場所にその変更が反映されていることを確認します。

完了した作業と観察された反応を分けた短いレポートを使用します。有用な形式には以下が含まれます：

• 納品済み： 承認されたコンテンツ、アウトリーチ、またはキャンペーンタスクが完了しました。
• 確認済み： チームが直接確認したリンク、投稿、または配置。
• 未処理： 保留中の承認、未回答の質問、未処理の提出。
• 学んだこと： 繰り返し発生するオーディエンスの混乱や明確化が必要な情報。
• 次へ： 未解決の各項目に対する責任者と次のアクション。

注目を、準備やコミュニティの理解の代わりとして扱わないでください。人々が繰り返し同じ質問をする場合は、単に投稿数を増やすのではなく、情報源とルートを改善します。ローンチ期間後のより広範な活動については、コミュニティ成長とエンゲージメントの次のステップと、プロジェクトの継続的な議論をサポートする実際の能力を比較してください。

プラットフォームの決定はチェックリストのどこに位置づけられますか？

チェックリストは準備と説明責任を向上させますが、プロジェクトに独立したプラットフォームのレビューや表示決定をコントロールする力を与えるものではありません。CoinGeckoとCoinMarketCapは独自のプロセスで提出を評価し、提出されたプロフィールは承認された上場と同じではありません。同様に、DEXScreenerやDEXToolsの可視性配置は、実際に合意された作業と配置を超えて、それらのプラットフォームが何を表示するかを確立することはできません。MediaStrategyは提出を記録し、可視性のある成果物を検証しますが、プラットフォームのレビュー結果をコントロール可能なキャンペーン結果として表現することはありません。

この区別は計画を形作るべきです。チームがコントロールする情報、チームが行える提出、プラットフォームに属する決定について、別々のチェックリスト項目を維持します。ステータスを監視しリクエストに対応する責任者を割り当てますが、ローンチコミュニケーションを未確認の承認に依存させないでください。注意が必要なプロフィール問題については、CoinGecko警告修正とCoinGeckoでの供給検証を別の準備トピックとして確認してください。

チェックリストを実際に役立てるために、MediaStrategyに目標のローンチ期間、現在のプロジェクト資料、対象オーディエンス、計画チャネル、承認連絡先を送信してください。アカウントリーダーがブリーフをレビューし、依存関係と不足している決定を特定し、チームが承認するための順序立てた作業計画を返します。

料金

開始価格はUSD表示です。カスタムバンドルやボリュームディスカウントはご相談ください。USDT、USDC、BTC、ETH、SOL、TON、またはプロジェクトトークンでのお支払いが可能です。

仕組み

1. ローンチブリーフを設定する目的、対象オーディエンス、ローンチ期間、承認済みのプロジェクト事実、未決定事項を確認します。
2. 責任者と依存関係を指名する各ワークストリームに責任者と承認連絡先を割り当てます。各タスクを進める前に何が準備できている必要があるかを記録します。
3. 資料を準備しレビューする情報源からチャネル固有のコンテンツを作成し、承認前に主張、リンク、連絡経路を確認します。
4. ローンチ期間を調整する共有ランシートを使用して、アクション、責任者、ステータス、エスカレーション連絡先を追跡します。変更は同じ記録に残します。
5. 報告しフォロースルーするローンチ後、納品された作業を確認済みの証拠、未処理項目、各責任者に割り当てられた次のアクションから分離します。