ローンチ後のフォローアッププレイブック

最初の告知は、チームが人々に何に気づいてほしかったかを教えてくれる。返信は、人々が実際に何を理解したかを教えてくれる。アクセス、ユースケース、価格条件、技術的な限界についての質問を集めよう。真の買い手からの質問と、返答を必要としない反応を区別すること。

製品に関する質問は、正確に答えられる人に渡そう。有用な公開回答は多くの沈黙している読者の助けになるかもしれないが、型通りのお礼では何も解決しない。会話を捏造したり、独立したユーザーを装うようクリエイターに求めたりしてはいけない。

次の波は情報を加えるべきだ。ローンチが成果物を示したのであれば、フォローアップはワークフローを示せる。そのツールが自分の環境で動くかどうかを人々が尋ねたのであれば、対応しているセットアップとテスト済みの例を公開しよう。アクセスが限定されていたのであれば、現在利用できるものを説明すること。

すべての製品に対して固定の第二波のタイミングを押し付けないこと。有用なデモンストレーション、回答、本当の更新を待つこと。異なる形容詞で同じ告知を繰り返すだけでは、再訪する視聴者が注目する理由はほとんど生まれない。

許可を得た上で、クリエイターのデモ、技術的な手順解説、正確な引用を小さなリファレンスライブラリーにまとめよう。閲覧者が文脈を確認できるよう、元のリンクと日付を残しておくこと。スポンサー関係には表示をつけ、クリエイターの発言をより強い推薦の言葉に書き換えることは避けること。

キャンペーンの証拠はケーススタディの形で残すこともできる。AISCが何を行ったかを述べ、利用可能な投稿の指標を示すこと。検証済みの製品上の成果があれば、その測定期間と出典を含めること。閲覧数とエンゲージメントしかない場合は、帰属された収益を暗示するのではなく、そのように述べること。

製品の導入サイクルに基づいてレビューの時点を選ぼう。インストール可能な開発者向けツールとエンタープライズ向けプラットフォームは、同じスケジュールでは転換しない。最初の波の後、遅れて発生する登録や直接の問い合わせとあわせて、トラフィック、アクティベーション、リピート利用を振り返ること。

基準値と比較し、同じ期間に起きた他の出来事を記録しよう。フォローアップのレポートは、観測された結果とまだ検証が必要な説明を区別すべきだ。有用なレポートには、二度と繰り返さないであろう配置も含まれ得る。

どのオーディエンスを維持するか、どの質問に製品面の修正が必要か、どのデモンストレーションがフォローアップに値するかという短い意思決定リストでレビューを締めくくろう。各アクションに担当者を付けること。意思決定を変えないレポートは、学びのループではなく単なるアーカイブだ。

ローンチは終わりのない勢いの約束ではない。持続的な情報発信には、新しい製品の価値、信頼できる説明、そしてチームが維持できるペースが必要だ。フォローアップの目的は、適切な人々に戻ってくるもう一つの有用な理由を与えることだ。