トークンローンチマーケティングチェックリスト：T-60 から T+30

T-60 から T-31 までに何を準備すべきですか？

この段階では、プロジェクトを一貫したバージョンで説明可能にします。短い説明文、長めのプロジェクト概要、トークン情報、想定される質問への回答をドラフトします。主張はチームが検証できる事実に基づいてください。未解決の製品、供給、ローンチの詳細は、仮定で埋めるのではなく記録します。

ウェブサイト、ソーシャルプロフィール、コミュニティチャネル、上場申請用の、信頼できる唯一の情報源ドキュメントを作成します。確認済みの公式トークンとコントラクトの参照情報、および修正担当者の名前を含めます。公開文言を承認する人と、時間に敏感な編集をできる人を決めます。チームが TGE と別のローンチ構造のどちらかをまだ検討中の場合は、チャネルカレンダーを作成する前に、判断基準と担当者を文書化します。トークンローンチと成長ハブ が関連作業のマッピングに役立ちます。

有用なアウトプットは大量のドラフトではありません。承認済みのストーリー、未解決の決定事項のリスト、およびそれぞれを解決するための明確な道筋です。納品責任者が使用可能であると合意するまで、日付を発表しないでください。

T-30 から T-8 でチャネルをどのように準備しますか？

1. 各チャネルに役割を割り当てる：発見、教育、コミュニティサポート、またはローンチ更新。
2. 各チャネルに担当者と承認パスを割り当てる。
3. 製品、トークン、参加に関する質問への再利用可能な回答を準備する。
4. 公開プロフィールと提出資料を信頼できる唯一の情報源と照合する。

これは、実用的なチャネルミックスを選択する時点であり、可能なアカウントをすべて開設する時点ではありません。各チャネルに定義されたオーディエンスと次のアクションを与えてください。コミュニティチャネルには、モデレーションプランと、技術的またはアカウント関連の質問をエスカレーションする経路が必要です。ソーシャルコンテンツには、公開責任者と、古い情報を修正する明確な方法が必要です。Telegram の計画については、仮想通貨 Telegram コミュニティの成長ガイド を参照してください。

上場およびプロフィール資料は、提出前にレビューできるよう十分早く準備してください。プロジェクトの説明、リンク、トークン識別子、ビジュアルアセットの一貫性を保ちます。CoinGecko と CoinMarketCap には独自の申請およびレビュープロセスがあります。該当する公式の指示に従い、要求された変更はマーケティングコピーの問題としてではなく、解決すべき作業として扱ってください。CoinGecko の申請パスについては、CoinGecko に上場する方法 を参照してください。

毎日を発表で埋めるのではなく、コンテンツテーマと承認チェックポイントを含むカレンダーを作成してください。この段階が終了する前に、計画された各プレースメントまたはクリエイターコラボレーションには、概要、成果物、公開期間、検証方法が必要です。クリエイター作業については、仮想通貨 KOL キャンペーンガイド を使用して概要を形成し、レビューを行ってください。

T-7 から T-1 のローンチチェックリストには何を含めるべきですか？

1. ローンチ期間と、変更を公開する権限のある人物を確認する。
2. リンク、名前、トークン詳細、スケジュールされたすべてのコピーをレビューする。
3. 各チャネルを監視する担当者と、問題がエスカレーションされる場所を確認する。
4. ローンチ詳細が変更された場合に備えて、保留用の更新を準備する。

この段階を使用して、あいまいさを排除します。すべての公開アセットを、最新の承認済み情報源と比較します。これには、固定されたコミュニティメッセージ、クリエイター概要、プレス資料、スケジュールされたソーシャル投稿が含まれます。オーディエンスが公式プロジェクトチャネルと無関係のアカウントを区別できることを確認してください。未確認のコントラクト詳細を配布したり、申請、上場、プレースメントが承認されていないのに承認されたと暗示したりしないでください。

公開、モデレーション、プロジェクトの質問への回答を行う担当者と、短い引き継ぎレビューを実施します。シーケンスをウォークスルーします：何が最初に公開されるか、どの更新がそれに続くか、各アイテムが公開されたことを誰が確認するか、スケジュールされたコンテンツを誰が一時停止できるか。ローンチ調整用に単一の内部チャネルを設定し、修正が別々の会話で失われないようにします。

AEOTech は、キャンペーンが公開される前に、承認済みメッセージ、チャネルスケジュール、公開責任者を比較するローンチ準備レビューを使用します。現在のローンチ期間、トークンとチェーンの詳細、公開リンク、ドラフトアセット、未解決の質問をそのレビューに持参してください。詳細が未決定の場合は、依存関係としてマークし、担当者が確認するまでスケジュールされた主張から除外してください。

ローンチ当日、チームはどのように調整すべきですか？

1. 合意された公式アカウントと承認済み資料からのみ公開する。
2. 各公開アイテムを確認し、その公開リンクを記録する。
3. 未回答の質問と修正の可視キューを維持する。
4. 技術的または事実上の問題をプロジェクトオーナーにエスカレーションする。

ローンチ当日は、調整された公開とサポートとして扱い、主張を即興で行う理由としては扱いません。チームは、どの発表が参照点であるか、ユーザーが最新情報をどこで見つけられるか、誰が修正を発行できるかを把握している必要があります。スケジュールされたアイテムが計画通りに公開できない場合は、依存する投稿を一時停止し、隣接するチャネルの責任者に更新します。

検証を簡単なログに記録します：計画アイテム、担当者、公開ステータス、ライブリンク、必要なフォローアップ。これにより、リーチや市場活動と完了した作業を混同することなく、チームに使用可能な記録が提供されます。回答は短く、事実に基づき、承認されたプロジェクト情報と一致するようにしてください。トークンの詳細に関する質問は、公の場で推測するのではなく、回答する資格のある人物に回してください。

ローンチメッセージは、読者をプロジェクトがサポートできる次のステップ（ドキュメントの閲覧、公式チャネルへの参加、プロジェクト更新の確認など）に誘導する必要があります。公開前にリンク先を確認してください。コミュニティメンバーに同一のメッセージを繰り返すよう求めないでください。役立つ回答と、明確で自発的な参加を優先してください。

T+1 から T+7 まで、マーケティングは何を監視すべきですか？

1. 寄せられた質問をレビューし、繰り返されるテーマをグループ化する。
2. チャネルとプロフィール全体で古い情報を修正する。
3. 約束されたコンテンツとプレースメントが公開されていることを確認する。
4. プロジェクトに意味のある新しい事実がある場合に更新を送信する。

ローンチ後最初の1週間は、サポートと一貫性のフェーズです。公開された質問を FAQ およびドキュメントと比較します。同じ点が混乱を引き起こしている場合は、すべてのスレッドで新しい説明で返信するのではなく、ソース資料を改善してください。未解決の質問、責任者、次に必要な更新を記録しておきます。

プロフィールの説明、トークン参照、固定情報がプロジェクトの現在のステータスと一致していることを確認します。サードパーティの上場またはプロフィールが不完全な場合は、公開されたプロセスに従い、自社のコミュニケーションでは申請ステータスを明確にしておきます。リクエストや提出フォームは、承認された上場と同じではありません。上場と検証ハブ には、CoinMarketCap 上場ガイダンス を含む、関連する準備パスがまとめられています。

合意された概要に対してキャンペーンの納品をレビューします：どの資料が公開されたか、どのリンクが有効か、何を修正する必要があるか、何がまだスケジュールされているか。簡潔なステータスノートをチームと共有します。観察可能な作業と解釈を分離します。注目、コミュニティでの会話、プラットフォーム上の表示を、製品採用の証拠として提示しないでください。

T+30 までローンチ計画を有用に保つにはどうすればよいですか？

1. 定義されたオーディエンスと担当者がいるチャネルのみを維持する。
2. 繰り返される質問を、より明確な常設情報に変える。
3. 検証済みの製品およびプロジェクトマイルストーンに基づいて更新をスケジュールする。
4. ローンチ計画に合わなくなったタスクをクローズするか再割り当てする。

T+8 から T+30 までは、ローンチ当日の強度を、管理可能なコミュニケーションリズムに置き換えます。実際のプロジェクト更新、ユーザーが必要とする説明、または製品の有用なデモンストレーションがある場合に公開します。コミュニティの質問と製品の進捗状況に基づいてトピックのバックログを維持し、適切な担当者がスケジュール前に各アイテムを検証するようにします。

チームが実際に検査できる証拠（完了した成果物、公開された回答、繰り返されるサポート質問、リンクステータス、対象オーディエンスに明確な次のステップがあるかどうか）を使用して、チャネルミックスをレビューします。チャネルが明確な目的を果たさずに作業を生み出している場合は、その役割を改訂するか一時停止します。初期計画に含まれていたという理由だけでフォーマットを維持しないでください。

短い週次レポートを使用して、完了した作業、未解決の決定事項、公開された問題、および担当者名を含む次のアクションを示します。承認されたコピーと資料の変更の記録を保存し、将来の貢献者が文言が変更された理由を理解できるようにします。ローンチ後にコミュニティ活性化やクリエイター作業を検討しているプロジェクトは、計画をゼロから再開するのではなく、次の概要をコミュニティ成長とエンゲージメントハブ または KOL とクリエイターキャンペーンハブ に接続してください。

チームの制御外にあるローンチの結果はどれですか？

1. チームが公開する資料、タイミング、作業を制御する。
2. サードパーティのレビューステータスと可視プレースメントを別々に追跡する。
3. ローンチ期間の変更に備えてフォールバックメッセージを用意する。

プロジェクトは正確な申請を準備し、公開された指示に従うことができますが、CoinGecko や CoinMarketCap は独自のレビューとプロフィール決定を制御します。DEXScreener と DEXTools は、インターフェースに何をどのくらいの期間表示するかを決定します。キャンペーンは特定のトレンドポジションや継続的な可視性を約束することはできません。合意された作業を記録し、提出や計画されたプレースメントをプラットフォームの決定として扱うのではなく、公開されているものを確認します。

決定ログを使用して、各外部依存関係、その担当者、次のアクションをマークします。プラットフォームが説明を求めてきた場合は、検証可能なプロジェクト情報で回答し、チームのステータスノートを更新します。ローンチ期間が変更された場合は、古いタイミングを現在のものとして提示するコミュニケーションを一時停止します。これにより、サードパーティのレビューや表示が変更された場合でも、チェックリストは有用なままです。

料金

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

仕組み

1. ローンチの基本情報を設定するローンチ期間、チェーン、プロジェクト説明、トークン詳細、公式リンクを共有します。確認されていないものはマークし、公開コピーに含めないようにします。
2. 作業と承認を割り当てるメッセージング、デザイン、コミュニティ対応、提出、公開の担当者を指名します。時間に敏感な変更を承認できる人を合意します。
3. 資料を準備しレビューするチャネルカレンダーとアセットセットを、信頼できる唯一の情報源から構築します。スケジュール前にリンク、主張、プラットフォームの指示、引き継ぎをレビューします。
4. 公開を調整する合意されたローンチシーケンスに従い、公開リンクを確認し、問題を記録します。事実上または技術的な質問は、適切なプロジェクトオーナーに回します。
5. 報告し適応する完了した作業、未解決の決定事項、次のアクションを共有します。T+1 から T+30 の計画を、検証済みのプロジェクト更新とユーザーの質問に合わせて調整します。