%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
PLGとPLSを組み合わせる際は、ユーザーが自分で進められる範囲と、営業の支援が必要になる場面を分けて設計します。プロダクトの利用が増えたという事実だけで提案を始めず、利用状況から何を確認でき、何がまだ分からないかを見極めることが重要です。
PLGとPLSを組み合わせる際は、ユーザーが自分で進められる範囲と、営業の支援が必要になる場面を分けて設計します。プロダクトの利用が増えたという事実だけで提案を始めず、利用状況から何を確認でき、何がまだ分からないかを見極めることが重要です。
「プロダクト主導でユーザーを増やしたいが、大きな組織への提案には営業が必要」「無料プランの利用者はいるが、有料プランを案内する判断が難しい」「プロダクトと営業のどちらに投資すべきか決められない」——こうした課題には、利用者の行動を営業の確認事項へ変える手順が必要です。
PLG（Product-Led Growth）は、ユーザーがプロダクトを使いながら価値を確かめ、利用を進める考え方です。PLS（Product-Led Sales）は、その利用状況を営業の判断材料に使う考え方です。本記事では、両者の違いから始め、営業へ引き継ぐ条件、CRMで扱う情報、運用後の見直し方まで整理します。「HubSpot営業・CS活用ガイド」の関連記事です。
この記事でわかること
PLGとPLSの使い分け・両立を設計したいプロダクト・営業の責任者に向けて、次の判断を順に扱います。
- PLGとPLSの定義と違い — ユーザーが自分で進められる購入過程と、営業が支援する過程を対比します
- ハイブリッドが有効な条件 — 無料利用の有無だけでなく、営業が解決すべき課題が生じるかを確認します
- 移行トリガーの設計 — 利用データが示す事実と、営業が確認すべき意向を分けて考えます
- 組織とKPIの設計 — Growth・Sales・CSが同じ利用者に重複して対応しないための役割と見直し方を示します
読み進めながら、自社の利用者がどこで判断に迷うか、その迷いをプロダクト内で解消できるかを確認してください。営業が必要な場面が見えたら、対象となる利用行動と担当者の次の動きを決められます。
PLGとPLSの定義と違い
違いを捉える起点は、顧客が購入を決めるまでに必要な支援です。利用開始からプラン変更まで自分で判断できるなら、プロダクト内の案内を整える余地があります。利用が進んでも、組織内の調整や個別の要件確認が残るなら、営業が関わる理由があります。
| 比較項目 | PLG | PLS |
|---|---|---|
| 獲得チャネル | プロダクト（フリーミアム・トライアル） | プロダクト利用＋営業アプローチ |
| 営業の関与 | なし〜最小限 | 利用データに基づくターゲット営業 |
| ターゲット | 個人・小規模チーム | 中堅〜エンタープライズ |
| 成約の形 | セルフサーブ（自分でアップグレード） | 営業介入によるアップグレード |
この表は顧客を規模だけで固定的に分けるためのものではありません。同じ組織でも、利用開始時はセルフサービスで進み、利用範囲が広がった段階で支援が必要になることがあります。反対に、利用者が増えても購入判断に迷いがなければ、営業からの連絡を増やす必要はありません。まず購入までの過程をたどり、顧客が止まる場面を特定します。
PLGの強みと限界
PLGを検討するときは、ユーザーが営業と話す前に価値を確かめられるかを確認します。利用開始に必要な設定、成果を確かめるまでの操作、プランの違いをユーザー自身が理解できるなら、プロダクト内で次の行動を案内できます。途中で止まる場合は、その理由を見ます。操作が分からないなら案内やオンボーディングを見直し、購入条件が分からないならプラン説明を見直すのが先です。
一方、利用者が価値を感じていても、導入を決める人が別にいる場合があります。セキュリティ要件、導入支援、カスタマイズの要否などを組織として確認する必要があれば、プロダクト内の案内だけでは判断が完結しません。この場合に営業が担うのは、利用量に応じて一律に上位プランを勧めることではなく、残っている判断事項を聞き取り、関係者が検討できる形に整理することです。
PLSを組み込む前に、利用者が止まった理由を区別してください。機能を使っていない人には使い方の支援が適するかもしれません。すでに使っていて、組織での展開方法を相談したい人には営業の関与が適するかもしれません。この分岐が曖昧なまま利用回数だけで通知を出すと、担当者は連絡の目的を決められません。
ハイブリッド戦略が有効な条件
PLG×PLSが適するかは、無料で使えるかどうかだけでは判断できません。利用を始めやすい経路があり、その先に顧客だけでは解決しにくい購入上の判断があるかを確認します。次の特徴は検討の手がかりになります。
- フリーミアムまたはトライアルがある：無料で始められるプロダクトがある
- 小規模と大規模の両方がターゲット：小さなチームは自己解決し、大企業は営業が対応する
- 利用量ベースの料金体系：ユーザー数や利用量の増加が自然に上位プランへの移行を生む
- チーム利用から組織へ広がる：個人→チーム→部門→全社と利用が拡大する
これらに当てはまっても、すぐに営業へ引き継ぐとは限りません。例えば利用人数が増えた場合、利用者が必要としているのは管理方法の案内か、契約条件の相談かを分けて確かめます。前者ならプロダクト内の説明やCSの支援を先に検討し、後者なら営業が確認する項目を用意します。利用上限への到達も同様です。上位プランの説明だけで判断できるならセルフサービスを整え、組織での利用範囲や導入条件を相談したいなら営業につなぎます。
適合性を判断する際は、過去に顧客から受けた質問を見返すと具体化できます。質問が操作方法に集中しているなら、まず利用体験を改善します。複数部門での利用、購入手続き、個別要件に関する相談があるなら、その相談が生じる前後の利用行動を調べます。対応が必要な場面と、利用データから確認できる場面が重なるところが、トリガー設計の出発点です。企業様によって最適な形は異なります。
PLGからPLSへの移行トリガー設計
トリガーは「営業に知らせるべき出来事」を表します。ただし、通知を受けたことと、顧客が提案を望んでいることは同じではありません。利用データで分かるのは、誰がどの機能を使い、どこで利用が変化したかです。購入意向や導入上の懸念は、顧客の問い合わせや担当者の確認を通じて判断します。
設計するときは、まず営業が支援できる場面を言葉にします。次に、その場面に先立つ利用行動を探します。最後に、通知を受けた担当者が何を確認し、どの回答なら提案へ進み、どの回答なら案内やCS支援へ戻すかを決めます。行動だけを先に選ぶと、通知後の対応が一律になりやすいためです。
PQL（Product Qualified Lead）の考え方
PQLは、プロダクトの利用状況を手がかりに、営業が確認する対象を整理する考え方です（参考：How to Define PQLs - ProductLed）。自社で定義するときは、「利用が進んでいる状態」と「営業が支援できる課題が見えている状態」を分けます。
例えば、機能の利用は価値を試している手がかりになりますが、それだけでは購入の相談が必要とは言えません。利用上限への到達はプランを見直すきっかけになりますが、追加利用を予定しているかは別に確認が必要です。管理者の追加は組織内での利用範囲を確かめるきっかけになりますが、全社展開が決まったことを意味しません。それぞれの行動について、観測できる事実、まだ分からないこと、次に確認する質問を対にしておきます。
営業への引き継ぎ条件は、対象となる行動が起きたかだけでなく、担当者が顧客にとって意味のある確認をできるかで決めます。確認事項が見つからない行動は、すぐに営業通知へ使わず、利用状況の観察やプロダクト内の案内に回します。
トリガーの例
| トリガー | 具体例 | 営業アクション |
|---|---|---|
| ユーザー数の閾値超過 | 無料プランでの利用人数が増加 | 有料プランの提案 |
| 利用上限への到達 | 無料枠の上限に達する | アップグレード提案 |
| 高度機能の利用 | 自動化やAPI連携を試行 | 上位プランの提案 |
| 利用頻度の急増 | アクティブ利用が急上昇 | CSによる支援＋営業提案 |
| 管理者の追加 | 新しい管理者が登録される | 組織展開の支援提案 |
営業アクションへ進む前に、連絡の目的を確認します。利用上限に達した顧客には追加利用の予定と現在の使い方を、高度機能を試した顧客には実現したい業務と試行中に困った点を、管理者が増えた顧客には管理の担当者と利用を広げたい範囲を尋ねます。回答をもとに、現在の使い方で対応できるか、プランや支援の検討が必要かを整理します。追加利用や利用範囲の拡大を予定していない場合は、変更を前提とした提案を控えます。
トリガーを選ぶ際は、発生しやすさだけで優先しないでください。担当者が理由を説明でき、顧客の次の判断を助けられる行動から扱います。同じ顧客に複数のトリガーが重なる場合も想定し、連絡の窓口と目的を一本化しておきます。
CRMでのトリガー実装
CRMでは、利用データ、判定理由、担当者の対応結果をつなげて扱います。通知だけを自動化すると、営業が何を根拠に連絡するのか、対応後に条件を見直すべきかが分かりません。実装前に、各トリガーについて対象レコード、更新される情報、通知先、タスクの完了条件を決めます。
- プロダクトの利用データをCRMのカスタムプロパティへ連携する
- ワークフローで閾値到達を検知し、営業担当へ通知する
- タスクを自動作成し、営業のアクションキューへ追加する
利用データを取り込む前に、行動した顧客を識別できるか、個人の行動と組織全体の利用を区別できるかを確認します。識別できない場合は、連絡先を決める通知の対象から外します。次に、各プロパティが示す出来事と更新のきっかけをそろえ、通知する行動と対象外の行動を明記します。担当者がタスクを開いたときに「何が起きたか」「誰の行動か」「連絡前に何を確かめるか」を読めるようにします。
次の画面は、HubSpotのワークフロー一覧の例です。自動化を検討する際は、一覧に並ぶ処理の名称だけで判断せず、対象となるレコード、起動条件、通知先、作成されるタスクの内容をそれぞれ確認します。
運用を始めた後は、通知を受けた担当者が顧客の課題を確認できたかを記録します。確認できない通知が続くなら、条件が広すぎないか、記録する利用行動が適切かを見直します。反対に、顧客から相談を受けて初めて重要な利用変化に気づくなら、必要な行動が記録されているかを調べます。PQLスコアを使う場合も、点数だけを引き継がず、対象となった行動と営業が確認する事項を残します。
組織設計とKPI設計
ハイブリッド型の役割分担
| チーム | 役割 | KPIの例 |
|---|---|---|
| Growth | PLGのファネル最適化・無料から有料への転換改善 | 無料ユーザー数・有料転換率・セルフサーブ売上 |
| Sales | PQLへのアプローチ・大型案件のクロージング | PQLからの商談化率・大型案件の売上 |
| CS | オンボーディング・定着・アップセル | 継続率・ヘルススコア・解約率 |
役割は、どの部門が数字を持つかだけで決めず、顧客の問いに誰が答えるかで決めます。利用開始後の操作や定着に関する課題はGrowthやCSが扱い、購入条件や組織での導入判断はSalesが扱う、といった分担を具体的な問い合わせに当てはめます。問い合わせが複数の部門にまたがる場合は、顧客への窓口と社内で相談する順序を決めます。
担当を引き継ぐときは、利用履歴だけでなく、顧客が何を実現しようとしているか、すでに何を案内したかを共有します。これが欠けると、利用者は同じ説明を繰り返すことになります。営業が連絡した後に操作上の課題が分かった場合は、提案を続ける前に適切な支援へ戻せるようにします。
部門横断のKPI
PLGとPLSをまたぐため、個別の活動量だけでなく、顧客が次の判断に進めたかを見ます。
- 全体：総売上・獲得コストの回収期間・継続率
- PLG側：サインアップ数・アクティベーション率・セルフサーブ経由の売上
- PLS側：PQLの発生数・PQLからの転換率・営業介入後の顧客単価
指標を読む際は、増減をすぐに施策の効果と結びつけず、対象となる顧客や集計条件をそろえて比較します。例えばPQLの発生数が増えても、営業が確認できる課題が増えたとは限りません。商談につながらなかった理由を見て、トリガーが早すぎたのか、連絡内容が顧客の状況に合っていなかったのかを分けます。セルフサービスで購入した顧客が増えた場合も、営業が必要な顧客への対応が滞っていないかを合わせて確認します。
初期アプローチを誰が担い、どの条件で別の担当へ引き継ぐかは、自社の体制に合わせて決めます。案件の規模だけで機械的に分けず、顧客の検討事項に対応できる担当者へつなぐことが大切です。見直しの場では、Growthは利用中に止まる場面、Salesは購入判断で止まる場面、CSは導入後に止まる場面を持ち寄り、案内・トリガー・担当分担のどこを直すか決めます。
あわせて読みたい
プロダクトで生まれた関心を、顧客ごとの購入判断へどうつなぐかを考える際は、次の記事も参考になります。ツール選定の観点を整理したい場合はMAのガイド、組織内の関係者や課題を把握したい場合はアカウントプランニングのガイド、HubSpotの活用範囲を確認したい場合は完全ガイドをご覧ください。
まとめ
PLG×PLSの設計では、プロダクト内で解決できる迷いと、人による確認が必要な判断を分けます。利用行動は営業へ引き継ぐきっかけになりますが、行動だけで購入意向を決めつけず、顧客に確認する内容まで定めます。
最初は、次の順序で対象を絞ると、通知後の対応を具体化できます。
- 顧客が利用中または購入前に止まる場面を洗い出し、操作上の課題と購入上の判断を分ける
- 営業が支援できる場面について、観測できる利用行動、まだ分からないこと、顧客に確認する質問を決める
- 対象の行動をCRMで確認できるようにし、通知を受けた担当者の対応と結果を記録する
運用後は、連絡が顧客の判断を助けたかを確かめます。課題を確認できない通知が多ければ条件を見直し、必要な相談を拾えていなければ観測する行動や引き継ぎ方を見直します。PLG・PLSの設計やCRM連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
よくある質問（FAQ）
Q1. PLGを始めるにはフリーミアムプランが必要ですか？
フリーミアムに限らず、トライアルを通じて利用者が価値を確かめる方法もあります。選ぶ際は、利用者が試したい業務を購入前に実行できるか、その結果を自分で判断できるかを確認します。試用しても設定や評価方法が分からない場合は、プランの形を決める前に案内を整えます。
Q2. PLSの営業はインサイドセールスとフィールドセールスのどちらですか？
顧客が確認したい内容と、自社の担当体制に合わせて決めます。最初の連絡で利用目的や検討事項を確かめ、その担当者が解決できない導入上の論点が出たら、対応できる担当へ引き継ぎます。担当を替える条件と、引き継ぐ際に共有する情報を先に決めておくと、顧客への説明が途切れません。
Q3. CRMにプロダクト利用データを連携する方法は？
プロダクト側からCRMへ情報を渡す方法、中間のデータ管理基盤を経由する方法、連携ツールを使う方法などを、自社で扱える情報と運用体制に照らして比較します。最初に、営業判断に必要な利用行動と、その行動をどの顧客の記録へ結びつけるかを決めます。そのうえで更新の遅れや重複が起きたときに確認できる方法を選び、担当者が判定理由を読める状態で運用を始めます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
