セルフサーブと営業の併走｜PLGの計測設計

自分で登録して勝手に使い始める人と、フォームから営業に連絡してくる人。同じサイトの上に、性格の違う入口が二つ並んでいます。

どちらも必要です。ただ、どこまでを製品に任せて、どこから人が出るのか。

これを数字で説明できるチームは、思ったより多くありません。

境界が曖昧なままだと、営業は手当たり次第に声をかけ、製品側は誰が本当につまずいているのか見えなくなります。両方が忙しいのに、どちらの成果も伸びない。

この記事では、セルフサーブと営業を併走させるときの計測設計を扱います。用語の説明は短めにして、境界を決めるために何をどう測るかを中心に書きます。

PLGは、製品が最初の営業をやる状態

PLG（Product-Led Growth）とは、製品そのものが集客と定着の主役になる売り方のことです。無料で試せて、価値を感じた人が自分の判断で有料に進みます。

対になるのがセールス主導の売り方。デモを見せ、商談を重ね、人が説明して契約に至る流れですね。

現実には、どちらか一方で完結する会社のほうが少数派です。小さいチームは自分で登録して使い始め、大きな会社は稟議やセキュリティ確認があるので必ず人が出てきます。

なおこの記事でGTMと書くときは、製品を市場に届けるための活動全体、つまりマーケ・営業・カスタマーサクセスをまとめて指しています。RevOpsは、その三つの運営と数字を一本につなぐ役割のことです。

併走が難しいのは、同じ人が両方の入口を見ているから

ややこしいのは、セルフサーブと営業が別々の顧客層を担当しているわけではない、という点です。同じ会社の同じ担当者が、無料で触りながら料金ページも見ています。

だから経路を単純に二分すると、実態と合いません。いちばん多いのは、まず自分で試して、社内を通すために営業を呼ぶという順番です。

この順番を前提にすると、測るべきものが変わります。どちらの入口から来たかではなく、いつ人が出るべき状態になったかを測ることになります。

境界は行動で引く。その前に現状を三つに数える

いきなり基準づくりから入ると、だいたい揉めます。現状が見えていないので、それぞれの印象で語ることになるからです。

まずは一ヶ月分でいいので、次の三つを数えてください。

• 誰にも接触されずに有料化したアカウント数
• 最初から営業が接触して有料化したアカウント数
• 自分で登録したあとに営業へ問い合わせたアカウント数

三つ目が、併走を考えるうえでいちばん大事な数字です。ここが厚いなら、製品と営業は取り合う関係ではなく、前後に並ぶ関係にあります。

そしてこの三つ目は、抜け落ちやすい数字でもあります。営業側の記録に残るのは商談の開始日だけで、その前に本人が自分で登録していた事実は、プロダクト側のログにしか残らないからです。

数え方は難しくありません。有料化したアカウントの登録日と、営業の初回接触日を並べて、どちらが先かを見るだけです。

重なりを数えないと、成果の取り合いになる

仮に、月の有料化が100件、うち無接触が55件、営業接触ありが45件だったとします。そしてこの45件のうち30件は、実は先に自分で登録していた。

このとき営業の貢献をゼロにするのも、100%にするのも正しくありません。先に製品が温め、最後に人が押したという共同作業だからです。

アトリビューション、つまり成果をどの接点に割り振るかという考え方は、ここで完璧を狙うと必ず止まります。割り振りの精度を上げるより、重なりの件数そのものを毎月見るほうが実務では効きます。

30件という数字が毎月出ているだけで、会話はずいぶん変わります。営業が製品の邪魔をしているのではなく、製品が営業に良い状態を渡している、と全員が確認できるからです。

企業規模で線を引くと、たいてい外れる

境界を決めるとき、よくあるやり方は、従業員数や想定席数で線を引くことです。何人以上なら営業が出る、という基準ですね。

運用は簡単です。ただ、規模が大きいだけで本気では検討していない会社にも人が出てしまいます。

逆に、規模は小さいのに毎日使い込み、メンバーを招待し、権限設定まで触っている会社もあります。受注が近いのは、どう考えても後者です。

そこで使われるのがPQLという考え方。Product Qualified Leadの略で、製品の使われ方から見て、いま人が接触する価値があると判断できる状態を指します。

似た言葉にMQLがあります。こちらはMarketing Qualified Leadで、資料請求やセミナー参加といったマーケ側の反応から見込みありと判断したリードのことです。

違うのは判断材料です。MQLは興味の表明を見ますが、PQLは実際に製品を使った事実を見ます。

引き継ぎのルールづくりそのものはMQLの引き継ぎ設計｜マーケと営業が揉めない基準づくりに整理してあるので、あわせて読んでみてください。

定義は、集計できる形まで書き切る

活用度が高いアカウント、では人によって解釈が割れます。だから最初から、そのまま集計に落とせる形で書きます。

PQL定義（v1 / 2026-08 適用）

対象: トライアル中、または無料プランのアカウント
条件: 直近14日間に、以下をすべて満たす
  1. 管理者以外のメンバーが2名以上ログインした
  2. コア機能Aの実行が合計10回以上
  3. 料金ページまたは請求設定を1回以上開いた
除外: 自社ドメイン、既存契約企業の別部署、テスト用アカウント
判定: 毎日 09:00 (JST) にバッチで再評価
通知: 該当アカウントの担当営業へSlack通知（未通知のもののみ）

三つ目の条件が入っている理由はわかりますか。使い込んでいる状態と、お金の話を考え始めた状態を分けるためです。

除外条件と判定タイミングまで書いて、はじめて来月も同じ数字が出せます。ここが曖昧だと、件数が増えたのか基準が変わったのか判別できなくなります。

経路ごとに、見る数字を変える

三つの経路を同じ会議で混ぜて話すと、まず噛み合いません。それぞれ責任者も打ち手も違うからです。

分けて置くと、こういう形になります。

経路ごとに担当と数字を分けるだけで、議論はかなり整理されます。全社で一つのCVRを追うのをやめる、と言い換えてもいい。

行動から見込み度を組み立てる具体的な手順は行動データで精度を上げるリードスコアリングで扱っています。

仮の数字で、人が出る閾値を決める

定義ができたら、次は厳しさの調整です。ここは実際に運用する前に、机の上で決められます。

たとえば月の新規登録アカウントが800、営業は2名、1人が丁寧に追えるのが月40件だとします。つまり、月80件までしか人は出られません。

この制約から逆算します。条件を厳しくすれば件数は減って質が上がり、緩めれば逆になります。

数字はすべて仮の例ですが、形は現場感に近いはずです。緩めても期待商談数はほとんど増えず、対応工数だけが2.5倍になっています。

しかも210件は、月80件という対応上限をはるかに超えています。溢れた分は放置されるので、実際の商談数は表の値よりさらに下がります。

この表を先に作っておくと、営業が出る基準の議論が好みの言い合いでなくなります。まずは標準で3ヶ月回して、商談化率を見ながら動かすのが現実的です。

上限を超えた月の落とし方も決めておく

閾値を決めても、件数が跳ねる月はあります。キャンペーンを打った翌月などですね。

そのとき何を後回しにするかを先に決めておかないと、担当者が個人の判断で選び始めます。スコア上位から順に、上限までという単純な規則で十分です。

こぼれた分は放置するのではなく、製品側の案内に戻します。人が出ないだけで、体験そのものは続いていると考えてください。

計測は、サイト側とプロダクト内側を分けて置く

ここでつまずくチームが多いので、先に線を引いておきます。必要なデータは、置き場所の違う二種類に分かれます。

一つはログイン前のサイト側。どこから来て、どのページを見て、登録フォームまで到達したかです。

もう一つはログイン後のプロダクト内側。誰が何回どの機能を使ったか、メンバーを招待したか、という利用の記録になります。

PQLの条件は、ほとんどプロダクト内側で判定します。一方で、その人がどの広告や記事から来たのかはサイト側にしかありません。

だから両方を、共通のアカウントIDでつなぐ設計が要ります。イベント名を先に決めておくと、後から揃えるより圧倒的に楽です。

# サイト側（ログイン前・匿名）
pageview            path, source, device, country
cta_click           label = free_signup | contact_sales
signup_form_submit  plan_intent = free | pro

# プロダクト内側（ログイン後・アカウント紐付け）
account_created     account_id, plan, seats
member_invited      account_id, invited_count
core_action_done    account_id, feature, count
billing_page_view   account_id
pql_reached         account_id, score, rule_version

最後の行にrule_versionを入れているのがポイントです。基準を変えた前後で、件数と質を比べられるようにするためですね。

流入元を正しく分けるには、広告やメールに付けるパラメータの設計も先に揃えておく必要があります。ここが崩れていると、PQLはどこから来ているのかと聞かれたときに答えられません。

この構成でStrideが担うのはサイト側、つまりログイン前の行動を測る層です。流入元の自動分類やファネルの到達と離脱、訪問者一人の行動をセッションをまたいで追う分析まではカバーしますが、CRMのように個人を特定して商談を管理したり、スコアを書き戻したりする機能はありません。

したがって実務での組み合わせは、サイト側はウェブ解析、ログイン後の利用と商談はプロダクトのイベント計測とCRMという分担になります。どの数字をどこから取るかを最初に決めておくと、後から数字が合わないという揉め事がかなり減ります。

完全な突合は諦めて、粒度を落とす

共通のIDでつなぐと書きましたが、正直に言えば全部はつながりません。ログイン前は匿名ですし、スマホで記事を読んで会社のPCで登録する、といったことも普通に起きます。

ここで一件ずつの完全な紐付けを目指すと、設計が重くなって途中で止まります。個人単位の突合を諦めて、週や月の集計レベルで重ねるだけでも、判断には十分間に合います。

たとえば、今月PQLになったアカウントの登録日を並べ、その前後の週にサイト側でどの流入元が伸びていたかを見る。厳密な一対一ではありませんが、どのチャネルが厚いのかの当たりはつきます。

精度を上げる作業と、意思決定に使う作業は別物です。前者に時間をかけすぎると、後者がいつまでも始まりません。

セルフサーブ側の到達率そのものを上げる話はオンボーディング改善｜最初の体験で離脱させない設計にまとめました。

人が出るまでの時間と、AIを入れる場所

閾値の次に効くのが速度です。PQLになった時刻と、営業が最初に触れた時刻の差を測ってください。

ここが数日空いていると、条件を丁寧に作った意味がほとんど消えます。使い込んでいる最中に触れるから価値があるわけですから。

測り始める前に、何を初回接触と呼ぶかも決めておきます。自動送信のウェルカムメールまで接触に数えると、時間だけは短く見えて実態は何も変わりません。

人が個別に書いたメッセージか、電話がつながった時点。それくらい厳しめに定義しておくと、数字が縮んだときに本当に速くなったと言えます。

そして速度が効くこの領域は、自動化と相性のいい場所でもあります。高頻度で、手順が毎回ほぼ同じで、遅れるほど価値が落ちる業務は、AIを入れる優先度がとくに高いからです。

入れ方のコツは、AIをチャット画面の中に閉じ込めないことです。人が思い出したときに質問しに行く道具ではなく、条件が揃ったら自動で動き出す処理として置きます。

そしてもう一つ。成績のいい担当者の判断手順を、先に文章で書き出すという下ごしらえを飛ばさないことです。

書き出せない判断は、エージェントにも写せません。逆に言えば、明文化の作業そのものに価値があります。

どこに人間の承認を残すか

全部を自動にする必要はありません。外に出るものと社内で終わるものを分ける、というのが基本の線引きです。

社内向けの下書き生成や要約は自動で構いません。顧客へ送るメール、価格の提示、契約に関わる変更は、人が確認してから出します。

導入の順番も、ほぼ決まっています。まずはシャドーモードで、AIの提案を実行せずに記録だけ取る。

そのうえで過去の案件を使ったテストセットを作り、人の判断とどれだけ一致するかを見ます。一致率だけでなく、外したときの外し方（惜しいのか、まったく的外れなのか）まで見てください。

評価項目も、精度ひとつでは足りません。誤って人が出てしまった件数と、出るべきだったのに出なかった件数を分けて数えます。

前者は顧客の体験を損ない、後者は売上を落とします。どちらをより許容するかは事業判断なので、先に決めておきましょう。

承認の置き方やガードレールの詳しい設計はGTMにAIエージェントを入れる｜人間承認とガードレールの設計で扱っています。

集計の手間を下げておく

地味ですが効くのが、数字を出す手間そのものを軽くしておくことです。集計に30分かかる作業は、忙しい週から順に飛ばされていきます。

StrideはMCPに対応しているので、先月PQLになったアカウントの初回流入元の内訳を出して、といった依頼をClaudeなどのAIから自然言語で投げることもできます。定例の前に数字を揃える作業が数分で終わるなら、運用は続きます。

誰か一人の善意で回っている集計は、その人が休んだ週に止まります。仕組みで回るようにしておきたいところです。

着手の順番

一度に全部はできません。順番を間違えると、たいてい途中で止まります。

現実的な進め方はこうです。

• 一ヶ月分の有料化を、無接触・営業主導・併走の三つに数え分ける
• PQL定義を、除外条件と判定タイミングまで含めて一枚に書く
• 対応上限から逆算して閾値を決め、3ヶ月は動かさない
• PQL到達から初回接触までの時間を毎週見る
• 自動化は、通知と下書きの生成だけから始める

最初の一つを飛ばさないでください。現状の内訳を知らないまま基準を作ると、ほぼ確実に作り直しになります。

そして基準を変えたら、必ず日付とバージョンを残す。これがないと、数ヶ月後に効果を確かめられません。

まとめ

セルフサーブと営業の併走は、どちらを選ぶかという話ではありません。同じ人が両方を通る前提で、いつ人が出るかを決める設計の話です。

境界は企業規模ではなく行動で引きます。使い込みの度合いと、お金の話を考え始めた合図の両方を条件に入れるのがコツでした。

閾値は対応できる件数から逆算し、仮の数字で期待値を並べてから決める。緩めても商談はさほど増えず、工数だけが膨らむことが多いからです。

計測はログイン前とログイン後を分けて置き、共通のIDでつなぐ。この分担を最初に決めておくと、後の揉め事が減ります。

AIを入れるなら、速度が効く場所から。外に出るものだけ人が承認する、という線引きで十分に回りはじめます。

まずは先月の有料化を三つに数え分けるところから、始めてみてください。