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

なぜトークンローンチチェックリストを使うべきですか？

チェックリストは、トークンローンチ計画を、チームがローンチ前、ローンチ中、ローンチ後に検証可能な作業に変えます。コミュニケーション、プラットフォームへの提出、コミュニティサポートが、矛盾した情報を持つ別々のプロジェクトとして扱われるのを防ぎます。

タスク、担当者、期限、依存関係、承認ステータス、完了の証拠というフィールドを持つ、一つの共有ドキュメントを使用してください。証拠としては、レビュー済みの告知、提出確認のスクリーンショット、テスト済みのリンク、公開済みのサポート回答などが考えられます。誰かがタスクを開始したという理由だけで、タスクを完了とマークしないでください。

日付を割り当てる前に、ローンチ時刻と、Tが何を指すのか（トークン生成、取引開始、または別のマイルストーン）について合意してください。その定義をドキュメントの先頭に記録します。次に、各タスクをそのイベントから逆算して、最初の1ヶ月先までマッピングします。

このチェックリストは、市場でのパフォーマンスを約束するものではありません。これは、チームが不足している決定を早期に発見できるようにするための調整ツールです。より広範なトークンローンチと成長計画と併用し、作業バージョンを最新に保つ責任者を一人決めてください。

T-60からT-31：最初に何を確定すべきですか？

まず、ローンチの事実と意思決定プロセスを確定してください。マーケティングは、変更中のトークンデザイン、不明確なローンチメカニズム、未承認の主張を、チャンネル間で一貫させることはできません。

プロジェクトの説明、トークンの目的、チェーン、コントラクトステータス、公開用に承認された供給情報、ローンチメカニズム、公式リンクを網羅した、唯一の情報源となるブリーフを作成します。最終決定でないものはすべて内部専用としてマークします。ユーティリティ、監査、パートナーシップ、利用可能性に関する主張は、公開コピーに掲載される前に、関連するプロジェクトオーナーにレビューを依頼してください。

この段階で、チームは以下も行う必要があります：

• 公開声明を承認する責任者と、その責任者が不在の場合の代行者を指名する。
• ユーザーが公式サポートに連絡する方法と、チームがなりすましの試みを特定する方法を確認する。
• プロジェクトがどのオーディエンスと地域を対象としているかを決定し、それに応じて言語とチャンネルを適応させる。
• 予定されているプラットフォームへの提出物をリストアップし、チームが検証するための現在の要件を把握する。

CoinGeckoのプロフィールや上場を計画している場合は、プロジェクト情報を準備し、現在のCoinGecko上場プロセスを確認してください。申請は、ローンチの宣伝の自動的な結果としてではなく、独自の担当者を持つ別のワークストリームとして扱ってください。

T-30からT-15：どのローンチアセットを準備すべきですか？

人々がローンチを理解し、次の安全なステップを踏むために必要なアセットを準備してください。行き先のページ、トークンの詳細、サポート手順が未完成であれば、洗練された告知だけでは十分ではありません。

承認済みのプロジェクト説明、ロゴファイル、ウェブサイトとソーシャルリンク、ローンチ説明資料、短いFAQ、チャンネル別の告知ドラフトを含む、コンパクトなアセットパックを構築します。コントラクトとトークン情報の正規版を一つ保持します。一貫した命名を使用し、オーディエンスが使用しそうなデバイスタイプで全てのURLが正しく動作することを確認してください。

各アセットについて、そのオーディエンス、公開者、承認ステータス、意図された送信先を記録します。例えば、短いソーシャル投稿はより詳細なローンチページを指すことができ、コミュニティメッセージにはサポートと安全性に関するガイダンスを含めることができます。プラットフォームの制限に応じたバリエーションを準備しますが、それらの間で中核的な事実を変更しないでください。

クリエイターやKOLを使用する場合は、彼らが行ってもよい主張、行ってはならない主張、開示に関する期待、レビュー連絡先を記載した書面によるブリーフを渡してください。選定プロセスは、単にオーディエンスの規模だけで選ぶのではなく、キャンペーンの目標に合わせてください。この暗号資産KOLキャンペーンガイドは計画と調整をカバーしています。チームが成果物をレビューできるよう、早い段階で使用してください。

T-14からT-7：チャンネルはどのように連携すべきですか？

一つの正確な情報源を中心にチャンネルを調整し、各オーディエンスに合わせてフォーマットを調整します。目標は、プロジェクトの事実を見つけやすくし、質問を適切にルーティングすることであり、文脈なしに同じメッセージをどこにでも公開することではありません。

チャンネルオーナー、オーディエンス、公開目的、エスカレーションパスを記載したチャンネルマップを作成します。告知期間中は、コミュニティスペースにモデレーターまたはサポート連絡先を割り当てます。公式リンク、ローンチタイミング、不審な活動を報告するためのルートを含むピン留めメッセージを準備します。ウェブサイトとソーシャルプロフィールが同じ承認済みの送信先を指していることを確認します。

チームが維持できるものに基づいて配信を選択します。自社チャンネルは直接的な更新を提供します。クリエイターコンテンツは外部の声を追加しますが、明確なブリーフが必要です。有料プレイスメントは定義された可視性を提供しますが、プラットフォームとクリエイティブのチェックが必要です。Telegramが中心的な場合は、モデレーション、オンボーディング、繰り返し発生する回答を事前に計画してください。Telegramコミュニティ成長ガイドは、その作業の構造化に役立ちます。

ドラフト、レビュー、公開のチェックポイントを含む公開カレンダーを維持します。ローンチのタイミングや承認済みの事実が変更された場合に、予定された投稿を一時停止できる責任者を確認します。ローンチチャンネルは、チームが最初の告知後もその情報を正確に保つことができる場合にのみ有用です。

T-6からT-1：ローンチの準備態勢はどのように確認しますか？

告知からユーザーサポートに至る経路をテストする準備態勢レビューを実施します。チームは、承認済みの情報を公開し、人々を正しい送信先に誘導し、詳細が変更された場合に一貫して対応できる必要があります。

指名された担当者とともに以下をレビューします：

• ウェブサイト、ソーシャルプロフィール、コミュニティリンク、ローンチ資料が同じ承認済みの事実を示していること。
• すべての公開リンクが正しく開き、チームがどの送信先が正規の情報源であるかを特定していること。
• モデレーターが最新のFAQ、エスカレーション連絡先、古いメッセージを修正するためのプロセスを持っていること。
• スケジュールされたコンテンツに、承認された変更後にそれを一時停止または修正できる担当者がいること。
• プラットフォームへの申請とプロフィール詳細が正確であり、提出ステータスが想定ではなく記録されていること。

簡単なリハーサルを実施します。コアチーム以外の誰かに公開リンクをたどってもらい、新しいユーザーが尋ねるであろう質問をしてもらいます。混乱するステップを記録し、ローンチ前に修正します。CoinMarketCapやCoinGeckoへの上場が計画の一部である場合は、その申請を別途追跡し、関連するCoinMarketCap上場ガイドを確認してください。提出済みの申請を承認済みの上場として提示しないでください。

T：ローンチ当日は何をすべきですか？

ローンチ当日は、調整されていない投稿の連続ではなく、管理された順序に従うべきです。承認された情報源に対して各公開更新を確認する指名されたリーダーがいる、単一のオペレーターチェックリストを使用します。

実用的な順序は以下の通りです：

• ローンチステータスと公開が許可された正確な情報を確認する。
• 主要な告知を公開し、その送信先リンクが機能することを確認する。
• 自社チャンネルとピン留めされたコミュニティ情報を、承認されたコピーから更新する。
• モデレーターに、繰り返される質問、壊れたリンク、エスカレーションが必要な報告を監視させる。
• 各公開更新と重要な修正を記録し、チームが信頼できる記録を保持できるようにする。

運用上の遅延に備えて短い保留声明を用意しますが、権限のあるリーダーが事実を確認した場合にのみ公開します。タイミングについて推測したり、チームが実証できない主張をしたりしないでください。技術的な問題は、それを解決する能力のある人にルーティングします。モデレーターは、コントラクトの動作やユーザー資金について即興で回答すべきではありません。

ローンチにDEXでの可視性目標が含まれる場合は、プラットフォームの準備態勢をマーケティングコミュニケーションから分離してください。プラットフォーム固有の準備については、関連するDEXScreenerトレンドガイドまたはDEXToolsトレンドガイドを確認し、チームの公開更新は事実に基づいたものにしてください。

T+1からT+7：チームは何を監視すべきですか？

最初の1週間は、正確な更新、迅速なサポート、そしてチームが公開した内容の明確な記録を優先します。ローンチ告知はコミュニケーション作業の始まりに過ぎません。

コミュニティの質問、ウェブサイトとリンクの問題、クリエイターの成果物、プラットフォームプロフィールの正確性について、定期的なレビューポイントを設定します。質問をトピックごとにグループ化して、チームが同じ問題に一貫性なく回答するのではなく、FAQを改善できるようにします。重要な事実が変更された場合は、まず正規の情報源を更新し、次にチャンネルのコピーを修正し、担当者に何が変更されたかを伝えます。

アクティビティと成果を区別するシンプルなレポートを使用します。何が提供されたか、どこに掲載されたか、どのような質問が出たか、何を修正する必要があったか、どの次のアクションに担当者がいるかを記録します。注目や投稿数を、ユーザーがプロジェクトを理解している証拠として扱わないでください。人々が公式情報を見つけられるかどうか、そしてチームが矛盾するガイダンスなしに一般的な質問に答えられるかどうかをレビューします。

トークンプロフィールに警告や誤った詳細が含まれている場合は、正確なテキストと、それに対処するために必要な証拠を文書化します。CoinGecko供給検証ガイドは、供給関連のプロフィール情報の準備について説明しています。プラットフォームのレビューが保留中の間は、公開声明は慎重にしてください。

T+8からT+30：ローンチ活動をどのように継続性に変えますか？

最初の月の残りを使って、ローンチ告知から信頼できるコミュニケーションのリズムへと移行します。次の正しいステップは、プロジェクトが何をしているかについての明確な更新であり、ローンチメッセージを延々と繰り返すことではありません。

最初の1週間に収集された質問とサポート問題をレビューします。繰り返し発生する質問をより良いFAQに変え、未解決のドキュメントやプロフィールの問題に担当者を割り当てます。出荷された機能や公開されたガバナンス決定など、検証可能なプロジェクトの進捗に基づいて更新を計画しますが、チームがそれを実証できる場合に限ります。実質的な更新がない場合は、カレンダーを埋めるために作り出さないでください。

期間の終わりに、マーケティング、プロダクト、コミュニティ、ローンチオペレーションの関係者でレビューを開催します。計画された作業と提供された作業を比較し、承認や引き継ぎがチームを遅らせた箇所を特定し、何を維持し、修正し、停止するかを決定します。有用なアセットと承認済みの回答を共有ワークスペースに保存し、将来のキャンペーンが散在するドラフトから始まらないようにします。

ローンチサポートのより広い視点については、このチェックリストをTGEマーケティングサービスおよびローンチ後マーケティングオプションと比較してください。これらのページを使用してサポートニーズを特定し、このチェックリストはプロジェクトの運用記録として保持してください。

プラットフォームのレビューとローンチマーケティングで制御できないことは何ですか？

ローンチチームは、提出物の正確性と自社のコミュニケーションの配信を制御できますが、プラットフォームのレビュー決定、順位、表示ローテーションを制御することはできません。CoinMarketCapとCoinGeckoは独自の上場およびプロフィールプロセスを適用します。DEXToolsとDEXScreenerは独自の可視性システムと参加資格ルールを制御します。完了した申請、マーケティングキャンペーン、コミュニティ更新は、承認や特定の配置を強制するものではありません。

このことは、チェックリストの書き方を変える必要があります。各プラットフォームタスクを準備、提出、フォローアップとして記録し、プラットフォームがステータスを確認するまで「承認済み」とラベル付けしないでください。プラットフォームの現在の公式ガイダンスを使用して要件を確認し、チームが提出したものの証拠を保持してください。上場、トレンドポジション、プロフィール警告の結果、オーディエンスの反応、トークン市場の結果を約束しないでください。

外部プロモーションにコミットする前に、書面による範囲（チャンネル、成果物、タイミング、承認手順、レポート形式、ローンチ詳細が変更された場合の対応）を求めてください。警告やプロフィール問題については、プラットフォームの正確な通知を保存し、その記載された原因に関連するプロセスを通じて対処してください。リスティングプロフィール改善ガイドは、プラットフォームが決定を覆すことを示唆することなく、その作業を整理するのに役立ちます。

料金

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

仕組み

1. ローンチイベントを定義するプロジェクトにとってTが何を意味するかを選択し、ローンチ時刻と承認済みの事実を一つの情報源ドキュメントに記録します。
2. 担当者と依存関係を割り当てる各タスクに責任ある担当者、期限、承認ルート、完了を証明する証拠を割り当てます。
3. アセットを準備しレビューするチャンネル対応のコピー、サポート回答、公式リンクを作成し、事実が一貫していることを確認します。
4. ユーザージャーニーをリハーサルする告知から公式情報とサポート連絡先への経路をテストし、混乱点を修正します。
5. ローンチとフォローアップを調整する管理された公開シーケンスを使用し、問題を記録し、T+30まで担当者をアクティブに保ちます。