「すべてのクライアントがコミュニティを望む：作る前にスコープを決めるガイド」

概要

最初のキックオフコールで、ほぼすべてのメンバーシップクライアントが「コミュニティが欲しい」と言います。その言葉は、いつの間にかプロジェクトを、フォーラム、イベント、コース、ライブルームを備えたポータルへと膨張させ、ローンチ時には誰も使わないことになります。この記事は、その曖昧なリクエストを小さくてリリース可能なメンバーシップサイトに変えるための、再現可能なスコーピングの会話をエージェンシーに提供します。まず「メンバーが支払うのは、___を得るためだ」という文章テストから始め、クライアントを1つのビジネスモデルに集中させ、実際のオーディエンスができるまでコミュニティ機能を延期し、すべての機能リクエストを変更依頼として扱います。この記事には、完全なコミュニティを望んだクライアントが、検索可能なアーカイブと毎月のライブQ&Aを立ち上げたという実例も含まれています。また、エンゲージメントを約束することへの警告もあります。ドアを提供することはできても、人々にそのドアをくぐらせることはできません。その結果は、救出ミッションではなく製品ラインとなり、クライアントはあなたが拒否したものに対して感謝します。

最初のキックオフコールで、クライアントは「コミュニティが欲しい」と言います。あなたはうなずき、メモにその言葉をタイプし、ロードマップが静かに2倍になるのを感じます。なぜなら「コミュニティ」は、フォーラム、プライベートチャットグループ、ペイウォール、コースライブラリ、イベントシリーズ、メンバーディレクトリ、またはそのすべてを意味し得るからです。そのすべてを意味するままにしておくと、誰も使わないものを作るのに四半期を費やし、それを使っていないのを見たクライアントに請求することになります。修正は、より賢いプラットフォームではありません。それは、毎回同じ方法で行われる、より正直な会話です。そうすれば、次の7人のクライアントそれぞれが一回限りの特注プロジェクトになることはありません。

この記事は、私たちがこの仕事で実際に答え続けている質問を中心に構成されています。「どのツールを使うべきか」ではなく、それらは後回しで、プロジェクトが時間通りにリリースされ、収益性を維持し、クライアントに「あなたは何をしているのか分かっている」と感じてもらえるかどうかを決定する質問です。

「コミュニティが欲しい」——実際に私たちは何を販売しているのか？

プラットフォームの話をする前に、クライアントに一文を完成させてもらいましょう。「メンバーは、___を得られるから私たちにお金を払う」。それだけです。具体的な内容で空白を埋められないなら、プラットフォームを選んだり、ページを設計したり、価格を提示したりする準備はできていません。メンバーシップサイト全体（ペイウォール、ティア、オンにしておく機能）は、その答えのための配信メカニズムにすぎません。

「コミュニティ」と言うとき、ほとんどのクライアントが実際に購入しているものは、4つのカテゴリに分類される傾向があります。再現可能なスコーピングを行うとき、私たちはその決定をそのうちの1つに絞り込みます。

メンバーが支払うもの	実際に構築する部分	安全に延期できる部分
コンテンツ（コース、アーカイブ、ツール）	ゲート付きライブラリ、支払いフロー、基本プレーヤー	ライブルーム、イベントカレンダー、証明書
アクセス（製品、サービス、ツール）	メンバーログイン、権利、アカウントゲート	公開フォーラムとソーシャルフィード
つながり（仲間、説明責任、ネットワーキング）	1つのディスカッションスペース、プロフィール、招待	完全なコースプラットフォーム、コンテンツドリップ、証明書
ステータス（インサイダー、早期アクセス、限定特典）	段階的アクセス、バッジ/ラベルロジック、シンプルな特典	フォーラム、ユーザー生成コンテンツ、ライブイベント

その表はスコーピングのチートシートであり、メニューではありません。クライアントは1つのカテゴリを選びます。2つを統合しようとしたら、手を挙げてペースを落とすべきです。なぜならコストが上がるからです。罠は、1人のクライアントのために4つすべてを行い、それを「エンゲージメントの高いコミュニティプラットフォーム」と呼ぶことです。それは製品ではなく、ポータルです。そしてポータルは時間通りにリリースされません。

この表は意図的に小さくしています。メンバーシップサイトを一度に4つのものにしてしまった瞬間、あなたは製品を作るのをやめ、小さなメディア企業を運営し始めています。クライアントがメディア企業を望むことはめったにありません。彼らが望むのは継続的な収益です。収益モデルがホームページから見える程度にスコープを小さく保ちましょう。

クライアントが同じ文の中で「コース」と「フォーラム」と言ったら、どちらが収益を生むのか尋ねてください。答えが「両方」の場合、実際にはまだ自分が何を売っているのか分かっていないクライアントを見ていることになります。そのうちの何人かはスコーピングの過程でそれを理解し、より明確な提案を持って戻ってきます。理解できないクライアントは、まだ準備ができていないことを伝えています。それは提案書を書く前に知るべきことであり、書いた後ではありません。

しかし、彼らはすでに「コミュニティ」を100回も言っている

ここからが逆説的な部分ですが、これは謙遜でも自慢でもありません。ほとんどのメンバーシップサイトは、コミュニティ機能をまったく使わずにローンチすべきです。「コミュニティ」は機能ではありません。それは、小さなグループの人々が互いに継続的な価値を得るときに生まれる行動であり、どのプラットフォームもそれをオンデマンドで生み出すことはできません。この言葉は「購読収益」の代わりとして使われるようになり、だからこそすべてのクライアントがそれを言うのです。それを翻訳し直すことで、あなたは彼らにとってより役立つ存在になるでしょう。

スコープを広げる前に、コミュニティの現実確認を行いましょう。3つの質問をしてください。

1. 最初の1週間で、新しいメンバーに具体的にどのような行動をしてもらいたいですか？（「エンゲージする」ではなく、「自己紹介を投稿する」「コメントを残す」「最初のレッスンを終える」など。）
2. 最初の1か月、あなたのチームの誰がこのスペースに時間を費やし、返信し、導き、雑音を整理しますか？
3. この問題を抱え、お互いを知っている人々がすでに数人いますか？それとも、ウェブサイトが存在するからといって、見知らぬ人がチームになることを期待していますか？

3つの質問すべてに曖昧な答えが返ってきたら、あなたはコミュニティを構築しているのではなく、空の部屋を建ててそれを建築と呼んでいるのです。実際的な動きは、すべてのコミュニティ機能を延期し、代わりにメンバーシップの骨格をローンチすることです。ディスカッションスペースは後からいつでも追加できます。そして、参加する理由をすでに持っているグループに追加すれば、機能する可能性があります。この問題全体にはもっと深い考察が必要ですが——コミュニティは実際のメンバーができてから——一言で言えば、オーディエンスが存在する前に円形劇場を建ててはいけない、ということです。

最小限でうまく機能するものは何か？

オファーを分類したら、ローンチを骨格として設計します。1つの支払いオプション、1つのティア、1つのゲート付きアセット、1つのコミュニケーションループ。プラットフォームの機能リストを見て、他のすべてをオフにしてください。確かに、プラットフォームはライブビデオルーム、メンバープロフィール、イベント管理、アナリティクスダッシュボードを実行できます。それが問題なのです。

あるクライアントが、B2B SaaS製品のための完全なコミュニティビジョンと呼ぶものを持って私たちのところに来ました。彼らはフォーラム、イベントカレンダー、リソースライブラリ、「メンバースポットライト」セクションについて話していました。スコーピングの過程で、私たちは彼らに「メンバーは、___を得られるからお金を払う」という文章を完成させました。彼らの答えは、創業者のアドバイスの検索可能なアーカイブと、毎月のライブQ&Aでした。だから私たちはそれをローンチしました。フォーラムも、メンバープロフィールも、イベントカレンダーもありません。その直後、アーカイブは使われ、Q&Aには常連ができ、クライアントはプライベートディスカッショングループを求めました。メンバーがすでに製品の外で互いに話していたからです。グループは、存在する理由ができた後に構築されました。それが機能する順序です。

完全なビジョンを構築していたら、私たちは遅れてローンチし、可動部分が増え、どれが実際に習慣を生み出したのかを判断する方法がない状態になっていたでしょう。アーカイブは実際の行動を示すことができましたが、使われることのなかったライブルームは単なる請求書になっていたでしょう。教訓は退屈ですが信頼できます。ローンチが小さければ小さいほど、クライアントは実際に何が機能しているかを伝えられる可能性が高くなります。スリムな製品はまた、次のことをうまく行う余地を与えてくれます——ティアを追加する、フォーラムを開く——を、ローンチ月に詰め込んだ急ごしらえの追加ではなく、意図的な変更依頼として行えます。ティアと収益構造について再現可能な考え方を探しているなら、継続収益のためのメンバーシップティアに関する記事がありますが、スコーピングが先です。

リクエストが積み重なったらどうするか？

ほとんどのメンバーシッププロジェクトがどのようにして終わるのか、正直に話しましょう。無能さからではなく、「もう一つ」からです。クライアントは競合他社のコミュニティのデモを見て、同じ機能を望みます。正しい対応は「はい」でも「いいえ」でもなく、「延期リストに追加しましょう」です。

延期機能リストをプロジェクトの第一級の成果物にしてください。提案書に入れ、見える場所に置き、スコープ外のリクエストをすべて追加します。各項目にトリガー条件を設定します。「いつか」ではなく、「200人のアクティブメンバーが1か月間スペースにいたらリリースする」とか、「クライアントが毎週2時間のスタッフ時間をモデレーションに割り当てたら」などです。あなたは厄介なことをしているのではなく、機能に存在する理由を与えているのです。

これが、すべてのクライアントのために同じメンバーシップサイトを作り直すのをやめる方法です。つまり、すべての新規クライアントを、意図的に構築しなかったもののリストを含む、すでにリリースした骨格の設定として扱います。機能が延期リストにあるなら、それは将来のプロジェクトであり、将来の収益でもあります。そのように提示すれば、クライアントは通常同意します。

空のフォーラムについてクライアントに責められないようにするには？

何を制御できて何を制御できないかについて、早い段階で文書化して期待値を設定する必要があります。支払いフロー、ゲート、メール自動化、デザインは提供できます。しかし、人々が互いに話し合うことを決める、ということは提供できません。クライアントの「エンゲージメント問題」は構築の問題ではなく、運用の問題であり、それはクライアント自身の責任です。

これは重要です。なぜなら、クライアントはローンチから3週間後に「コミュニティが静かだ」と静かに尋ね始めるからです。最初に境界線を設定していれば、インセンティブとシーディングについて建設的な会話ができます。設定していなければ、壊れていないプラットフォームをデバッグすることになります。これを正式にする実用的な方法：メンテナンスリテーナーに「コミュニティ運営とシーディング」の項目を別途含めるか、プロジェクトキックオフに含まれるシーディングチェックリストをクライアントに渡します。重要なのは、分業を明確にすることです。ツールはリテンション戦略ではありません。プラットフォームに営業を任せようと期待する場合、メンバーシップサイトの神話が通常の原因です。

それでもコミュニティを主張する場合、何をオンにするか？

クライアントが現実確認を通過し、実際にコミュニティを運営しているなら、ディスカッションフォーマットを1つだけオンにしてください。3つではありません。フォーラムはスレッド形式で、検索可能で、非同期です。ライブルームは即時的で、一時的で、スタッフが多く必要です。少人数のチームで両方をうまくモデレートすることはできません。そうしようとすると、クライアントに「コミュニティ」とは絶え間ない活動を意味すると教えることになり、それは約束すべき基準ではありません。

実用的なルール：1つのスペース、1つのフォーマット、1人の指名されたモデレーター。現実確認で特定した行動に合うフォーマットを選びます。望ましい行動が「質問して答えを得る」なら、フォーラムから始めます。「火曜日の正午に集まって課題を話し合う」なら、ライブイベントから始めます。そして、最初の90日間の軽量なメトリクスを設定します。総メンバー数やサインアップ数ではなく、ターゲット行動を少なくとも2回行ったメンバーの数です。活動が2回言及されれば、そのスペースが生きているのか、それとも博物館なのかを知るのに十分です。

これを製品ラインとして価格設定し、救出ミッションにしないには？

ディスカバリーの会話自体を請求可能な製品にします。スコーピングコール、骨格の構築（ええ、本当に）、支払い設定、1回の改訂を含む、固定料金のメンバーシップサイトセットアップパッケージを作成します。それを超えるもの（コミュニティデザイン、カスタム機能、モデレーション時間、統合）はすべて、別の作業明細書です。それがすべてのコツです。各オプション機能を変更依頼として見積もると、クライアントは突然優先順位を学びます。すべてを1つのエスカレーションする見積もりにまとめると、あなたは彼らに「スコープが増えるのは無料だ」と教えています。

再現可能なプロセスは次のようになります：コール前に送るアンケート、固定価格の1ページの作業明細書、チームが以前に実行した構築スケジュール、延期機能リストのテンプレート。デザインムードボードが存在する前に、クライアントに稼働日を伝えられるはずです。また、より良い会話も得られます：クライアントは、最低限のコスト、コミュニティの追加コスト、そして自分たちの時間のコストを目にします。彼らが骨格に支払うのをためらうなら、それが痛みを伴う前に学ぶことになります。

誰も聞きたがらない部分

すべてのメンバーシップサイトは、継続的な行動への賭けです。プラットフォームは単なる封筒です。多くのクライアントのためにこれを構築する者としてのあなたの仕事は、誰も手作業でライブパフォーマンスを届ける契約をしていないことを確認しながら、封筒に宛先を書いて切手を貼ることです。コミュニティを実現させることはできません。条件を作り、可能な限り最小のバージョンを選び、何を構築しないかの明確なリストをクライアントに渡すことはできます。

その最後の部分があなたの本当の価値です。クライアントは、何を省くべきか見えないからあなたを雇ったのです。だから、自信を持って、意図的に、文書化して、彼らの代わりに省いてください。スコープを定めてしまえば、提供はほぼ退屈なものになります。メンバーシップサイトのローンチは実際にリリースされる、それが小さく、決定が事前に行われている場合です。空のフォーラムや広大なカスタムポータルは高くつきます。時間通りに提供される骨格は、決してローンチされなかった「強力なコミュニティプラットフォーム」よりもはるかに価値があります。