プロダクトレッドセールス（PLS）とは？｜セルフサーブに営業をいつ足すかを設計する考え方

PLGの次に来る壁

無料トライアルやフリーミアムを入り口にして、利用者自身が価値を確かめてから有料化する。この成長モデルはプロダクトレッドグロース（PLG）と呼ばれ、セルフサーブの計測設計はこの連載でも何度か取り上げてきました。

ところがPLGだけで会社を伸ばそうとすると、あるところで成長カーブが鈍ります。個人や少人数のチームは自分でクレジットカードを登録して契約してくれますが、複数の部署をまたぐ大きな契約や、社内のセキュリティ審査が必要な取引は、製品の画面だけでは完結しないからです。

一人法人やAIを駆使したインディーハッカーであっても、事情は大きく変わりません。ノーコードやAIエージェントを組み合わせて作った製品が評判を得ると、思ったより大きな企業から、導入前に話を聞かせてほしいという連絡が来る瞬間が訪れます。

この壁にぶつかったとき、多くのB2B SaaS企業が選ぶのがプロダクトレッドセールス（PLS）という設計です。セルフサーブの入口はそのまま残しつつ、ある条件を満たした利用者にだけ、人の営業担当が声をかける仕組みを重ねます。

この記事では、PLSの定義とPLGとの違い、営業を足すタイミングの決め方、そして陥りやすい失敗までを順に整理します。似たテーマとして、PLGの計測設計やPQLも合わせて参考にしてください。

プロダクトレッドセールス（PLS）とは何か

PLGとの違い

プロダクトレッドセールスとは、製品の利用データを起点にして、営業がいつ・誰に・何を提案するかを決めるGTM（Go To Market、市場への出し方）の設計手法です。獲得はセルフサーブに任せ、拡大や大口化の局面だけ人の営業を挟む、という役割分担が核にあります。

PLGは製品そのものが営業担当の代わりをすることを目指すモデルで、理想形は営業がゼロでも収益が伸びる状態です。PLSはこれを否定するのではなく、PLGの上に「ここから先は人が動いた方が速い」という線を引く発想だと捉えると分かりやすいでしょう。

つまりPLSは、PLGと従来型の営業主導のどちらかを選ぶという二択の話ではありません。同じ製品の中に、両方の入口を用意しておくという発想に近く、利用者がどちらの入口を通るかは、契約規模や組織の複雑さによって自然に決まっていきます。

セルフサーブとPLS、そして昔ながらの営業主導型を並べると、それぞれの得意分野の違いが見えてきます。

セールスレッド（営業主導型）との違い

従来の営業主導モデルでは、見込み客のリストを作るところから契約までのすべてを営業担当が動かします。展示会や紹介、広告からリードを集め、商談を重ねて契約に至る流れで、これは今でも高額な戦略的契約には向いた進め方です。

PLSが従来型と違うのは、最初の接触をすでに製品側が済ませている点です。営業が声をかける頃には、相手はすでにログインしてボタンを押し、機能を試した経験を持っています。ゼロからの製品説明ではなく、使ってみて感じた疑問に答える会話から始められるのが強みです。

この違いは、営業担当に求められる動き方にも影響します。従来型の営業が、まだ製品を知らない相手に価値をゼロから説明する役割だとすれば、PLSの営業はすでに価値を知っている相手の背中を押す役割に近く、必要なスキルセットも自然と変わってきます。押し売りの言葉より、相手がつまずいている箇所を一緒に確認する姿勢の方が、成果につながりやすいという声もよく聞かれます。

コストの構造も対照的です。従来型の営業主導は、一件あたりにかける工数が大きい代わりに成約単価も大きく、少数の大口案件を確実に仕留める設計に向いています。対してPLSは一件あたりの営業工数を小さく保つことが前提になっており、声をかける相手を絞り込む仕組みそのものが利益率を左右します。

なぜ今、PLSという設計が必要とされるのか

セルフサーブが得意なこと・苦手なこと

セルフサーブの製品は、少人数のチームや個人が今すぐ試したいというタイミングを逃さない点で強みを発揮します。クレジットカード登録から数分で使い始められる体験は、比較検討に時間をかけたくない層にとって大きな魅力になります。

一方で、複数の部署が関わる契約や、社内の法務・セキュリティ審査を通す必要がある取引は、画面の中だけでは完結しません。誰が最終的な決裁者かも分からず、公開されている価格表にはない条件を交渉したい相手もいます。ここに、製品だけでは埋まらない溝があります。

契約規模の偏りというもう一つの理由

多くのSaaS製品では、契約金額を安い順に並べると、少額の契約が数多く存在し、ごく一部に極端に大きな契約が混じるという偏った分布になりやすいことが知られています。この偏りそのものが、単一の営業戦略では扱いにくい理由になります。

すべてを同じセルフサーブの導線で扱おうとすると、大口になりうる相手を取りこぼします。逆にすべてを営業主導にすると、件数の多い小口の相手に人手をかけすぎて割に合いません。PLSは、この偏った分布の両端に別々の扱いを用意する現実的な折衷案だと考えると理解しやすくなります。

裾野に広がる小口の契約はセルフサーブの導線に任せ、長い尾の先にいる大口候補だけを人の目で拾い上げる。この住み分けができているかどうかが、PLSがうまく機能しているかを判断する一つの目安になります。

溝を埋めるのは情報ではなく人

この溝を埋めるのは、追加の機能やより丁寧なオンボーディングメールではなく、多くの場合は人による会話です。相手の組織構造や意思決定の進め方に合わせて提案を調整できるのは、今のところ人間の営業が最も得意とする領域だからです。

だからといって、すべての利用者に営業を当てるのは非効率です。無料利用者の大多数は、そもそも大きな契約に育つ見込みがなく、営業をかけても双方の時間を消費するだけに終わります。行動データをもとに見込みの濃さを絞り込むという発想を、営業をかける・かけないの線引きにもそのまま応用するのがPLSの実務です。

ここで前提になるのが、誰がどのページをどう使ったかという行動の記録そのものです。招待人数やログイン頻度がアンケートや自己申告ではなく、実際の操作ログとして残っていて初めて、閾値を機械的に判定できるようになります。逆に言えば、計測の土台が粗いままPLSの仕組みだけを整えても、声をかけるタイミングは勘に頼ったままになります。

PLSに共通する3つの介入パターン

業界で観測されるPLSの導入パターンを一般化すると、営業が声をかけるきっかけはおおむね3つに整理できます。特定の企業の実績としてではなく、多くのB2B SaaSに共通して見られる型として捉えてください。

• 利用の急拡大: 招待人数、保存データ量、API呼び出し回数などが短期間で急に伸びたとき
• 組織の広がり: 同じ企業ドメインから複数のアカウントが次々と登録されたとき
• 機能の壁: 無料枠の上限や、上位プランでしか使えない機能に利用者が触れたとき

利用の急拡大と組織の広がり

一つ目のきっかけは、あるチームの使用量が短期間で急に伸びた瞬間です。招待した人数や保存したデータ量が閾値を超えたら営業に通知が飛ぶ、という設計がよく使われます。急拡大は、その利用者がすでに製品から価値を得ている強いサインでもあります。

二つ目は、同じ企業ドメインから複数のアカウントが登録された局面です。一人で使っていたツールに同僚や他部署のメンバーが次々と参加し始めたら、それは組織的な採用が始まった合図と読めます。この段階で声をかけると、社内の複数の利用者が同時に恩恵を実感しているぶん、話がまとまりやすい傾向があります。

機能の壁にぶつかったタイミング

三つ目は、無料枠の上限や、上位プランでしか使えない機能に利用者が触れた瞬間です。この瞬間は本人の関心が最も高いタイミングでもあるため、価格の話を持ちかけても嫌がられにくいという特徴があります。

いずれのパターンも、利用者が製品の中で実際に取った行動が起点になっている点が共通しています。営業側の都合ではなく、利用者側の状況変化に合わせて声をかけるのがPLSの基本姿勢です。逆に言えば、こうした行動の変化を検知できる計測の仕組みがなければ、PLSはそもそも成立しません。

PLSを設計する4つのステップ

ステップ1〜2: 閾値と担当を決める

最初のステップは、どの指標がどこまで伸びたら営業が動くかという閾値を決めることです。ここでは仮の例で考えてみます。以下の数値はすべて説明用の仮定であり、実在の統計ではありません。

閾値は最初から精緻である必要はありません。むしろ粗くても早く動かし始め、後から見直す方が現実的です。次に、この連絡を誰が担当するかを決めます。件数が少ないうちは既存の営業チームが兼務できますが、対象が増えてきたら、利用データ起点の商談だけを専門に扱う担当を置く企業も見られます。

この閾値は、製品側だけで決めて営業側に押し付けると機能しません。製品と営業が同じ数字を見ながら合意するプロセスを挟まないと、通知が来ても動かない営業と、動かない営業に不信感を募らせる製品側という、社内の対立構造ができあがってしまいます。

ステップ3〜4: 引き継ぎの基準と計測

三つ目は、マーケティングや製品からの見込み客を営業にどう引き継ぐかという基準です。MQLの引き継ぎ設計で扱った揉めない基準の考え方は、PLSにおける利用データの引き継ぎにもそのまま当てはまります。

数字の解釈がマーケと営業で食い違ったままでは、せっかくの良いシグナルも現場では信用されません。最後に、営業が介入した案件と、セルフサーブのまま契約に至った案件を分けて計測する仕組みを用意します。

両者を混ぜて追ってしまうと、営業の貢献度も、セルフサーブ単体の実力も、どちらも正しく評価できなくなるためです。RevOps入門で触れた、マーケ・営業・カスタマーサクセスをまたぐ役割分担の考え方は、この計測の切り分けを設計する土台としてそのまま役立ちます。

一人法人・少人数チームでの実践とよくある失敗

大きな会社だけの話ではありません。専任の営業担当を雇う余裕がない一人法人や少人数チームでも、PLSの考え方そのものは応用できます。一方で、規模に関わらず陥りやすい失敗の型も共通しています。

相談枠から始める、という軽い一歩

いきなり営業チームを作る必要はありません。利用が急拡大したアカウントの担当者宛てに、創業者自身が15分の相談枠を提案するだけでも、立派なPLSの実践です。相手にとっては売り込まれたのではなく、困りごとを聞いてもらえたという体験になりやすく、少人数のうちはむしろこの距離の近さが強みになります。

近年は、利用データの変化を検知してメールの下書きを用意したり、よくある質問への一次回答をAIエージェントに任せたりする運用も増えています。ただし価格交渉や契約条件の調整のような、相手の状況に応じた判断が必要な場面は、最終的に人が引き取る設計にしておくのが無難です。AIに任せきりにすると、相手の事情を無視した機械的な提案になり、かえって信頼を損ねる恐れがあります。

規模を問わず起きやすい失敗

閾値の設計や役割分担を誤ると、PLSはセルフサーブの良さを壊す方向に働いてしまいます。特によく見られる失敗を3つ挙げます。

• 閾値を低く設定しすぎて、営業が見込みの薄い相手への連絡に忙殺される
• セルフサーブの画面に営業担当の連絡先を前面に出しすぎて、自己解決したい利用者の体験を壊す
• 営業が介入した後もセルフサーブの請求やアップグレード導線を残し、二重の窓口で利用者を混乱させる

いずれの失敗も、根っこにあるのは「営業を足すこと」自体を目的化してしまうことです。PLSはあくまで、セルフサーブでは埋まらない溝を人の力で補うための設計であり、溝がない相手にまで営業を当てる理由にはなりません。

自社サイトでこうしたシグナルを見るには、一人の利用者の行動を時系列で追う視点と、多数の利用者を俯瞰して急拡大や離脱を見る視点の両方が必要です。MonaLensのような解析ツールで両方を同じ画面から確認できれば、閾値の見直しや担当者への引き継ぎも机上の空論で終わりにくくなります。

まとめ：どこから始めるか

PLSは、PLGを捨てて営業に戻ることでも、すべての利用者に電話をかけることでもありません。セルフサーブの良さを保ったまま、人の判断が必要な局面だけを見極めて手を差し伸べる設計です。

最初の一歩としては、過去に大きな契約へ育った案件を振り返り、契約の直前にどんな利用シグナルが出ていたかを洗い出すのが現実的です。派手な仕組みを最初から作る必要はありません。

そこから閾値の仮説を立て、小さく試しながら、社内で追っている他の指標と矛盾しない形に育てていくとよいでしょう。セルフサーブと営業、どちらか一方を選ぶ話ではなく、利用者の状況に合わせて両方を使い分ける設計だと捉えることが、PLSを長く機能させる鍵になります。