一人チームのためのSaaS市場参入戦略

購入者が価値にたどり着く道筋を選ぶ

モーションとは、最初の関心から利用と購入に至るまでの道筋です。創業者主導のモーションでは、あなたが課題の診断を手伝い、製品をデモし、購入判断を導きます。セルフサーブでは、購入者はあなたの関与なしに評価し、利用を始め、支払いまで進められます。ハイブリッドは、特定の障害となる箇所に人のサポートを置き、それ以外はセルフサーブのままにします。

まず暫定的な顧客プロファイルを1つ決めます。役割、繰り返し発生するワークフロー、そして今変える理由です。次に、最初の価値を得るイベントを観察可能な形で定義します。「アカウント作成」はセットアップの一段階にすぎません。購入者がアウトプットを使って実際のタスクを完了することのほうが、より有用な候補です。この2つのイベントの間に何が起きなければならないかを問いましょう。

• 購入の摩擦：この人は購入を承認できますか？それとも、セキュリティ、調達部門、または別の予算責任者の関与が必要ですか？
• 導入の摩擦：この人は、カスタム連携なしで必要なデータを用意し、結果を理解できますか？
• 信頼：デモやサンプルで試すのに十分な信頼を築けますか？それとも、誰かが権限や制約を説明する必要がありますか？
• キャパシティ：製品を保守しながら、何件の評価とサポート依頼に対応できますか？

約束は製品の現在の機能の範囲内にとどめる

実際に動作する機能と購入者のタスクを結びつける一文を書きましょう。製品の中で人が確認できることと、それがもたらすことを期待している改善とを分けて考えます。承認待ちの項目を表示するツールなら、その可視性をうたうことはできます。しかし、支払いが早くなるという主張には、支払い結果に関する証拠が必要です。

現在の回避策を、あなたのオファーと並べて記録します。スプレッドシートですでに十分に回っているなら、現在の手段にない機能があるというだけでは、乗り換える理由にはならないかもしれません。競合分析で事実を集め、ポジショニングのワークシートでどの違いが重要になりうるかを判断しましょう。関連する証拠が得られるまで、価格、パッケージ、支払い意欲は暫定のままにしておきます。

実例：同じSaaSに対する2つのモーション

この例に出てくるものは、製品、観察、価格、時間、日付を含めてすべて架空です。これらは計画上の仮定であり、ベンチマーク、顧客の成果、Soloopのタスクによる出力ではありません。

ReviewQueueを想像してください。クライアントの承認待ちの成果物を一覧表示し、レビューリンクを共有し、承認の判断を記録する、エージェンシー向けの小さなツールです。請求書の作成や代金の回収は行いません。この架空のシナリオでは、創業者はデモでそれらの機能を確認していますが、購入や継続利用の証拠はありません。以下の2つの案は、どちらも同じエージェンシーのオペレーション責任者を対象にしています。

この2週間の計画演習では、創業者はGTMの作業に10時間を確保し、現金支出の上限を$100とします。製品の保守には別の時間を割り当てています。問いは、限定的なサポート付き評価とサポートなしのトライアルのどちらが、次のテストとしてより適しているかです。

計画を創業者一人の1週間に収める

準備、配信、サポート付き評価、サポート対応、振り返りに時間の予算を割り当てましょう。これらの作業が使える時間を超える場合は、同時に進める評価の数を減らすか、オファーを簡素化します。無料トライアルだからといってサポートも無料で済むとは考えないでください。現金と時間には、それぞれ別の上限が必要です。

上の架空の選択では、2件の評価はキャパシティの上限であり、需要を証明するサンプルサイズではありません。1人の購入者のサポートだけで確保した3時間をすべて使い切った場合は、評価を増やすのをやめて原因を調べましょう。オンボーディングの問題、購入者のミスマッチ、機能の不足は、それぞれ異なる次の一手を意味します。

SaaSの市場参入計画をコピーする

このワークシートを選択して、自分のドキュメントにコピーしてください。アカウント登録は不要です。まず計画の列を埋め、次にそれを変えうる証拠を洗い出します。小さな画面では、表を横にスクロールすると2列目が表示されます。

チャネルを拡大する前にモーションを振り返る

各ステップで何が起きたかを記録しましょう。対象となる人に届いたか、オファーが理解されたか、セットアップが始まったか、最初の価値に到達したか、購入判断がなされたか。件数と情報源のメモを残してください。2件の好意的な返信からは、信頼できるコンバージョン率はわかりません。購入は、関心の表明とは異なる種類の証拠です。

ReviewQueueの場合、購入者がサポートなしでセットアップを完了すれば、サポートを必須にする根拠は弱まります。購入者が承認の要件で行き詰まるなら、その依存関係を解消するか、対象を変えるべきだと示唆されます。招待を受け取らなかったクライアントと、ツールを試したうえで採用しなかったクライアントとでは、残る疑問が異なります。これらのケースは分けて扱いましょう。

モーションが明確になったら、下の「最初のSaaS顧客」ガイドを使って、見込み客の選定、アウトリーチ、対話を進めてください。こうした実行作業は、この計画の制約に従うべきです。チャネルを追加するのは、既存のチャネルから何を学んだかを説明でき、それに伴う作業量を支えられるときだけにしましょう。

製品とこのGTMブリーフをSoloopに持ち込む

このワークシートは単独でも使えます。Soloopで続けるには、ブリーフを会話にコピーしてください：私の製品は[URL]です。購入者は[役割]、購入の摩擦は[事実]、最初の価値は[イベント]、キャパシティは[時間]、予算は[上限]です。[モーション]を比較し、不足している証拠を明示し、レビュー用に次のアクションを1つ提案してください。

Soloopのマニュアルでは、メインの会話での計画立案と、個別に承認されるリサーチタスクについて説明しています。提案されたアクションの範囲とコストは必ず確認してください。キャンペーンの設定と支払い手続きを完了すると、SoloopはGoogle広告キャンペーンを準備して開始できます。このブリーフだけでキャンペーンが開始されることはありません。「Soloopを試す」リンクは公開の入口を開くため、ワークシートはご自身でお持ちください。