実際にローンチできるメンバーシップサイトの立ち上げ

概要

クライアントがメンバーシップサイトを求めたとき、彼らが挙げる機能はほとんど製品そのものではありません。製品とは、特定の何かと引き換えに繰り返し支払われるもの — そしてそれ以外のすべては、機能を装った遅延にすぎません。エージェンシーにとって、それはローンチの会話を標準化することを意味します: 価値交換を一文で定義し、それを支える最小の機能セットを洗い出し、プラットフォームがすでに提供している配管のためにカスタムビルドを行うことを拒否します。この記事では、クライアントや内部ステークホルダーから聞かれるであろう反対意見を取り上げ、タイムラインを正直に保つための反論を示します。'コミュニティ' や 'コースホスティング' をローンチ要件として扱うのをやめれば、メンバーシップサイトを四半期ではなく数週間でローンチできます。

なぜすべてのメンバーシップサイトのプロジェクトが9か月の大作になってしまうのでしょうか?

それは、私たちが常にローンチをクライアントの全ビジョンが公開される瞬間として扱っているからです。実際は決してそうではありません。ビジョンとは、プラットフォームのセールスページにある機能のスプレッドシートであり、ローンチとは誰かがお金と引き換えにアクセスを得る最初のポイントです。エージェンシーにとって、年間3つのメンバーシップサイトをリリースできるか1つしかできないかの違いは、その区別をクライアントに損をさせたと感じさせずに、何度も声に出して伝える能力にかかっています。

これは特定のプラットフォームへのガイドではありません。それは、あなたに対して使われるであろう反論と、タイムラインを食い荒らそうとするエッジケースへのフィールドガイドです。

「完成したと感じるまでローンチできません。」

まずクライアント自身の言葉から始めましょう。「第一印象を与える機会は一度きりです。」これはブランドに関しては真実ですが、機能リストに関してはそうではありません。初日にバッジシステムがなかったから解約するメンバーはほとんどいません。彼らが解約するのは、支払ったものが届かなかったからです。実際には、彼らのほとんどは静かに去っていくだけですが、それは別の記事の話題です。

メンバーシッププラットフォーム市場は、この反対意見をさらに悪化させるようにできています。標準的な製品メニューには、ディスカッションスペース、ライブビデオルーム、メンバープロフィール、イベント管理、分析、コースホスティング、決済処理、段階的アクセスが含まれており、すべてが1つのサブスクリプションにまとめられています。それぞれが正当な機能です。しかし、そのどれもがローンチ要件ではありません。空白のプロジェクトを開いて「何を含めるべきか?」と尋ねれば、クライアントは「全部」と答えるでしょう。それはスコープの問題ではなく、メニューの問題です。

だから、フレームをひっくり返しましょう。ローンチは製品が完成したと感じる瞬間ではありません。ローンチはループが閉じる瞬間です: メンバーが支払い、メンバーが求めてきたものを手に入れ、メンバーが次の支払いにも価値があると感じる。それ以外はすべて後続のイテレーションです。

これを伝えるのに役立つ方法は、3列のテーブルです:

プラットフォームのメニューが約束するもの	ローンチに実際に必要なもの	後回しにできるもの
フォーラム/ディスカッションスペース	コアコンテンツを届ける確実な方法	誰かが実際に質問し始めたとき
ライブビデオルーム	スケジュールとホスト役	人が集まることが証明できたとき
メンバープロフィール/ディレクトリ	機能するログインと着実に支払われる決済	オーディエンスが十分に大きくなったとき
分析	更新が行われているかどうかを示す1つのダッシュボード	まだ読む準備ができていない残りのデータ

これは毎回同じ動きです: プラットフォームのマーケティングが与えた機能リストを取り、「今すぐ公開」「次の四半期に公開」「おそらく公開しない」に分類します。実際のローンチリストが恥ずかしいほど短いことに気づくでしょう。それが目標です。

「でも、あなたのプロセスでは、私たちのメンバーの特性に対応できないでしょう。」

すべてのクライアントが、自分たちのメンバーは特別だと思っています。専門職協会はB2B SaaS企業とは異なるものを「必要としており」、クリエイターも「必要としています」。プラットフォーム自体が、協会向け、SaaS企業向け、クリエイター向けにメッセージを分けて、この考えを強化しています。セグメンテーションは現実的ですが、結論はそうではありません。

クライアント間で実際に変わるのは、価値交換であり、仕組みではありません。メンバーシップサイトは、どのような場合でも、何かの周りに置かれたペイウォールです。プラットフォームのまとめ記事では、専門職協会に適したプラットフォームやクリエイターに適したプラットフォームがあると紹介されており、その多様性は有用ですが、それは最初の決定ではなく、最後の決定です。

再現可能なエージェンシーのプロセスは、プラットフォームの比較を1つも開く前に、一文を書くことです。「メンバーは毎月支払って [X] を得る。」もしクライアントがその文を完成できなければ、どのプラットフォームを選んでも救えません。完成できれば、Xを届けることに集中してローンチ全体をスコープし、Xに関係のない機能を無視できます。

また、ここで価格設定の会話は脇に置きます。月額サブスクリプション、年間メンバーシップ、一回限りの支払い、コースバンドル、プレミアムティア — これらはすべて収益化のオプションであり、Xに対して課金するさまざまな方法にすぎません。年会費を請求するためにコミュニティフォーラムを必要とする人はいません。クライアントにモデルを「サブスクリプション + コミュニティ + コース」と定義させた瞬間、1つの製品ではなく3つの製品を引き受けたことになります。ちなみに、これは古典的な非技術系の上司にメンバーシップサイトを提案するがうまくいかない理由でもあります: 誰もが価値交換ではなく機能を売ろうとするからです。

「クライアントがカスタムビルドを希望しました。」

カスタム開発に費やそうとしていた時間を、クライアントが答えられない1つの質問に使いましょう。「これらの機能のうち、どれが製品で、どれが包装でしょうか?」ほとんどのカスタムリクエストは、メンバーシッププラットフォームがすでにチェックボックスとして提供している包装のためのものです。カスタム作業は、クライアントを市場で実際に差別化する製品の部分だけに取っておくべきであり、業界で並べ替えるだけのメンバーディレクトリのために使うべきではありません。

具体例を挙げると、あるクライアントが、認定ディレクトリ、ライブQ&Aルーム、四半期ごとのバーチャルサミット、カスタムマッチングツールを含むリストを持ってきました。マッチングツールが製品であり、ディレクトリ、Q&Aルーム、サミットはすべて包装でした。私たちはカスタム作業をマッチングツールに限定し、シンプルなメンバーログインと支払いページでローンチし、残りは18か月間「後で」リストに載せておきました。クライアントはディレクトリが無関係になるのを見守り、6桁の費用をかけずに機能する製品を手に入れました。その教訓はアカウントチーム全体に残りました。

ただし、注意点があります。クライアントが、プラットフォームの標準機能が市場に真に適合しないニッチな業界にいる場合 — たとえば、異なる承認ワークフローを持つ何百もの支部レベルのメンバーに請求する必要がある協会など — その場合、カスタムビルドはプラットフォームと戦うよりも正当に安価になり得ます。しかし、それはニッチなケースであり、デフォルトではありません。デフォルトは、カスタム開発が、メンバーが決して見ないものにお金を費やすためにメンバーシッププロジェクトが行き着く場所です。

「コミュニティを運営できません。」

いいですね。それなら、コミュニティを立ち上げないでください。

これまで読んだすべてのエンゲージメントに関する記事は、コミュニティが定着の鍵だと言っていますが、それはその通りです — 最終的には。しかし、コミュニティは定着のための機能であり、ローンチの機能ではありません。3か月間誰も投稿しないフォーラムは、フォーラムがないより悪いです。それは誰に対しても「この場所は死んでいる」と伝えます。空のライブビデオルームは、よく設計されたメールコースより悪いです。クライアントに、毎週数時間を費やして質問に答えたりディスカッションを開始したりできる担当者がいない場合は、まずコンテンツ面をローンチし、活気を感じられるほどのクリティカルマスができたときにコミュニティを追加しましょう。

これは逆説的な部分です: エージェンシーにとって、「コミュニティを運営できません」というのは反対意見ではなく、贈り物です。それは、クライアントに予算化されていない運用コストを負わせずにローンチできることを意味します。後で、メンバー数が十分に大きくなり、人々がすでにお互いに話したいと尋ねてきたとき、メンバーシップコミュニティのエンゲージメントを高めることができます。それを運営する担当者がいる機能を使えば。

ここでのアクションステップは、例外なくすべてのクライアントに適用されるチェックリストです。提案されたすべての機能について、「ローンチ後は誰がこれを担当しますか?」と尋ねます。答えが、カレンダーに時間のある指名された人物でなければ、その機能は公開されません。メンバープロフィール? プロフィールを承認する人が必要です。ライブビデオ? ホストが必要です。ディスカッションフォーラム? モデレーターが必要です。プラットフォームは配管を提供できますが、雑用を提供することはできません。

「ローンチ前にすべてを移行しなければなりません。」

移行は、几帳面な人々のお気に入りの遅延です。クライアントには何千人ものメール購読者、10年分の記事、PDFコース、アクセス期限付きの古いメンバースプレッドシートがあり、それらすべてが新しいシステムに入っていなければ誰にも請求できないと確信しています。

そんなことはありません。ローンチに必要なのは3つだけです: 支払う人々、お金を受け取る方法、そして彼らが支払っているコンテンツです。それ以外はすべて、サイトが稼働している間に移行できます。毎週の切り替え、「この日以降のアーカイブを新規メンバーに提供する」、週末に実行されるインポート — これらのいずれも、データクレンジングの栄光を待つローンチよりはましです。

これがエージェンシーの動きです: 移行切り替え日を設定し、それを守ります。最小限の実行可能なデータセットでローンチします。クライアントが古いメンバーに古いコンテンツへのアクセスを保持させなければならないと主張する場合、それは「今回のローンチには含めない」リストの機能です — プラットフォームはほぼ確実にアクセスレベルをサポートしているので、古いシステムを読み取り可能なままにし、新しいメンバーを新しいシステムに案内できます。移行期間中に2つのシステムを持つことは許されています。完全なデータが稼働中の製品を妨げることは許されません。

「すべてをこなすプラットフォームが必要です。」

この時点で、コール中の誰かが、メンバーシップ機能、コミュニティフォーラム、コースホスティング、決済処理、カスタムランディングページの「ワウ」なデザインを組み合わせたツールを求めるでしょう。これをオールインワンの罠と呼びます: それはビルドを検索に変え、その検索は決して終わりません。なぜなら、単一の製品がすべての点で客観的に優れているわけではないからです。

これを解決するには、プラットフォームをオールインワンの万能として評価するのをやめ、このクライアントのローンチで実際に最も遅く、最もリスクの高い部分は何かを尋ねます。リスクが決済とアクセスなら、それらに関して退屈なほど信頼できるプラットフォームを選びます。リスクがメンバーシップ自体の販売なら、優先事項はコンバージョンするランディングページとまともなチェックアウトであり、そのためにプラットフォームの10番目の機能は必要ありません。メンバーシッププラットフォームを選ぶ前に尋ねる重要な質問は、いつか使うかもしれない機能ではなく、ローンチについて尋ねるべきです。

そして、ここにスキップしがちな部分があります: 機能検索がデザインを遅らせる手段になってはいけません。クライアントが「ブランドを反映したモダンで洗練されたプレゼンスを望んでいます」と言うとき、それは本当のニーズです。しかし、ローンチページはプラットフォームがあらゆることに優れている必要はありません。交換条件を明確に説明し、価格を示し、邪魔にならないことが必要なだけです。エージェンシーにとって、「ローンチ後に再設計します」という言葉は、品質の妥協ではなく、ローンチへのコミットメントです。

結論: 人々が支払ってくれる最小のものを公開し、月曜日に追加する。

継続的な収益は完全なビジョンを構築することへの報酬ではありません。完全なビジョンは継続的な収益で構築されます。その一文を常に心に留めておけば、反対意見は自然に解消されます。「完成したと感じるまでローンチできない」は「完成は動く標的なので、最小限をローンチして学び始める」になります。「私たちのメンバーは特別だ」は「素晴らしい、それなら価値交換が違うのだから、その一文を書きましょう」になります。「カスタムが必要だ」は「カスタムは製品のためのものであり、配管のためではない」になります。「コミュニティを運営できない」は「有料のコアをローンチし、担当者ができたらコミュニティを追加する」になります。「まず移行しなければならない」は「支払う人々を移行し、残りは後で」になります。

その規律こそが、あなたが実際に販売しているサービスです。クライアントはメンバーシップサイトを購入していると思っています。彼らが実際に購入しているのは、本物の継続的な収益ループと、製品のように見えてそれを遅らせるだけの機能を分離するあなたの能力です。ピッチでそれをうまくやれば、次のクライアントにも同じことを提供できます — エージェンシーにとっては、それがすべてのポイントです。