パイプライン管理はなぜ機能しないのか|商談ステージとSFA設計の勘所
SFAに登録されている商談を並べると、その多くが決着の間際にある。見積を出した、稟議に上がっている、あとは決裁を待つだけ。一方で、まだ要件を固めている段階の商談はほとんど載っていない。動いていないのではなく、載っていないだけである。
起票の引き金になっているのは、見積や社内承認といった業務上の必要で、それが生じるのは買い手の検討が終盤に入ってからだ。加えて、確度の低い案件を早く出すほど進捗を問われる。出さないほうが個人には合理的で、その合理性が組織の空白をつくる。
パイプライン管理で最初に決めるべきは、ステージの数ではなく入口の定義である。 どの時点で商談として数えるかを決めていないから、判断が現場に残り、業務上の必要が生じるまで登録されない。
本稿で扱うのは、入口・登場人物・確度・権限という4つの設計判断と、自社の営業に案件別の管理が向いているかの判定だ。
パイプラインとは何か
商談とは何か
商談とは、買い手・ニーズ・ソリューションの3つが特定され、金額と時期を記載できる状態になった受注機会である。1つでも欠ければ金額も時期も記載できない。この3条件は Forrester がデマンドユニットの成立条件として挙げるものと同じである。
SFAの構造も符合している。Salesforceの商談レコードでは完了予定日が必須項目で、その指定は外せない。時期を置けないものは、そもそも商談として記録できない作りになっている。
パイプラインの入口はどこか
商談の条件を満たした瞬間が、パイプラインの入口である。 その入口の手前が、セールスファネルといわれる状態である。
本稿の問いは、ほぼすべてセールスファネルとパイプラインの入口に帰着する。3つの条件が揃った時点を入口とするのか、営業が確度を持てた時点を入口とするのか。 後者では、営業が確度を持てるのは買い手が候補を絞り終えて自社が残ったと分かってからなので、登録は必ず終盤になる。逆に手前が入口となれば、金額も時期も分からない商談が並び、追うべき総数だけが膨らむ。設計は入口の定義が重要であり、ステージやその名称はその後で良い。
パイプラインとファネルは、何が違うのか
マーケティングファネル・セールスファネル・パイプラインの3つは、何を数えているかが違う。
| 何を数えるか | 数える単位 | |
|---|---|---|
| マーケティングファネル | 買い手が認知から検討へ進む過程で絞られていく母集団 | 人(購買に関与する個人) |
| セールスファネル | 商談になる前の営業活動(接触・面談設定など)が絞られていく過程 | 営業活動数 |
| パイプライン | ある時点で受注に至りうる商談の集合と、その状態 | 商談 |
数える対象が違えば、打ち手も異なる。マーケティングファネルであれば数えるのは人なので、ターゲットになりうる人の数をいかに伸ばし、その人へどのマーケティング施策を打つかを検討することになる。セールスファネルになると、商談には至っていないが、営業活動をしていく過程を通じてパイプラインの入口が見つかる。この場合は人に対する営業活動数が重要となる。時には1つの営業活動に対して、複数人のお客様が絡むこともでてくる。そして入口の条件が固まって初めて、パイプラインが作られる。ここで数えるのは、パイプラインの本数である。
なぜ、わざわざパイプラインを持つ必要があるのか
目的は予測可能性の獲得だが、昨今、予測は以前より当てにくくなっている。Ebsta と Pavilion の『2025 Go-to-Market Benchmarks Report』がある。65万5,000件の商談・480億ドル規模のパイプラインを分析し、2,000名を超えるCROに調査したものだ。そこでは**2025年にクォータを達成できなかったセラーが78%**に達している(前年69%)。「今期はいけそうです」の積み上げは、もう成立しない。
一方で、副次的な効果もある。ステージを定義する作業は、そのまま「自社の営業が受注に至るまでに何をするべきか」を書き出す作業になる。 まさにプレイブックを作成する作業とも言える。
定義が曖昧なステージだと、担当者ごとに違う意味で使われるからだ。たとえば「提案」というステージで、ある担当者は提案書を送った時点、別の担当者は相手が前向きな反応を返すまで待ち、さらに別の担当者は見積を出すまで動かさない。というように同じ「提案」に3件並んでいても、実際の状態は3つとも違う。 属人化は、ステージの話を一つとっても浮かび上がる。
なぜ、パイプラインは受注直前にしか立たないのか
買い手は、営業に会う前に決め終えている
ワンマーケティングの『2025年度版 BtoB購買プロセス白書』に数字がある。営業担当者との最初の面談の時点で、候補が「ほぼ決まっている」29.2%、「いくつかの候補に絞り込まれている」56.2%。合わせて85.4%が、初回面談の時点ですでに絞り込みを終えている(n=96/購買先面談を自身の担当業務として挙げた回答者)。2020年の同調査では79%だった。
海外でも同じだ。6senseの『2025 B2B Buyer Experience Report』は約4,000名の買い手に聞いた調査だ。そこでは、売り手に接触する時点が購買プロセスの69%から61%へ前倒しになっている。それでも初日のショートリストに載せた4社の中から選ぶ確率は95%で、前年の85%からむしろ上がっている。
営業に会う前に決まっている度合いは、さらに強まっている。つまりパイプラインの入口は、すでに絞り込みが終わった地点にある。 セールスファネルが数えられるのは営業が接触してからの活動なので、その手前で何が起きたかは映らない。だからこそマーケティングファネルが重要となり、セールスファネルだけでは拾えない買い手の接点を捕捉するために存在する。

だから「確度を持てたら登録する」では、受注直前にしか立たない
営業側のパイプライン運用が「営業が確度を持てたら登録する」という登録のタイミングだと、構造上、買い手の意思決定の終盤に固定されるため、予測にならない。
予測とは、まだ確定していないものの着地を見積もる行為。確定に近いものしか載っていない台帳には、見積もる対象がない。確度の高い案件だけが並ぶパイプラインは、予測ではなく報告だ。 しかも指標の上では健全に見える。載っている商談の確度が高いので、通過率も受注率も良くみえる。
とはいえ「ちゃんと入力させる」では直らない
打ち手はたいてい運用の強化になる。入力ルールの明文化、週次の棚卸し、入っていない案件は評価しないという宣言。続かない理由にもデータがある。
UPWARDが営業職370名に行った『フィールドセールス活動実態と業務課題調査』(2026年5〜6月)がある。活動報告ツールへの不満の上位3つは、すべて入力そのものの負荷だった。1位は「手入力・記入が面倒」で27.2%(報告制度がある層 n=265)。そして報告・入力の58.6%が帰社後または帰宅後に行われている。入力は営業活動の外側の別作業で、ルールを増やせばその作業が増える。
入力の負荷と戦い続けるか、入力の判断に依存しない生成の仕組みを作るか。 本稿が採るのは後者である。
出来上がったパイプラインは、こうして崩壊する
入口が早ければ早いほど、商談は長くなる。商談が長ければ長いほど、機会を捕捉するのが困難になり、実態からずれていく。 ここで、よくあるパイプラインが崩壊する3つの要因を紹介したい。
1つめは、クローズデートのスリップ。 予測した期間内に閉じなかった商談の完了予定日が、次の期間へ押し出される現象だ(Clariの定義)。1回の後ろ倒しは正常で、問題は同じ商談で繰り返されるときである。「失注」と記録するには相手に確認するか見切りをつける必要があるが、日付を動かすのは1操作で済む。負荷の差がそのまま行動の差になり、決着していない商談は失注ではなく延期として処理される。
2つめは、ステージの先祖返り。 要件が振り出しに戻る、決裁者が交代する。実務では珍しくないが、問題は戻したときと、戻さないときの両方にある。
戻したとき。Salesforceでは、ステージの滞留期間が遷移と遷移の間の期間として測られる。 前のステージへ戻った商談の、それまでの滞留時間は積み上がらない。つまり先祖返りが起きている商談は、滞留日数が実態より短く出る。 買い手から見れば数ヶ月決着していない商談が、計測上は「最近このステージに入った新しい商談」として並ぶ。最も長く停滞している商談が、最も健全に見える。 戻さないときはもっと単純で、下げると評価が下がるので現場は戻さない。前にしか進まないステージ運用は、滞留を不可視にする。
3つめは、更新の遅れ。 商談の状態は動いたときに更新されるとは限らず、多くの現場ではレビューの直前にまとめて更新される。そのとき営業は記憶をたどり、記憶にはいまの結論が混ざる。更新が遅れるほど、履歴は観測の記録ではなく、あとから引いた線になる。
3つに共通するのは、どれもSFAの標準機能で観測できることだ。商談の金額・確度・フェーズ・完了予定日のいずれかが変更されると、そのつど変更の時点とともにステージ履歴へ新しいエントリが追加される。しかも、この履歴は消さずに残しておける。すなわち崩壊は、起こるべくして起こる設計になっているということだ。
ただし、メディアなどで露出している基準を安易に採用するのはやめたほうがいい。「押し戻しが何回を超えたら要注意」「何日動かなければ滞留」といった閾値は流通しているが、発行元も標本も示されていないものが多い。閾値は自社の履歴から出す。 受注に至った商談は各ステージへ何日とどまり、押し戻しが何回までなら受注に届いたのか。答えはすでに自社の履歴の中にある。
商談ステージを設計し直す、4つの判断
設計すべき対象は4つ。後ろの③④の判断は、前の①②の判断が決まっていないと効かない。
判断① いつ商談を作るか
商談を作るタイミングは、営業の手応えではなく、買い手の検討がどこまで進んだかで決める。 起票の引き金を、売り手側の事情(見積・稟議・確度)から買い手側で起きた事実へ移すということだ。
買い手の検討は、機能や価格の比較として進むわけではない。心理の変容として進む。 ワンマーケティングは、この変容を8つのフェーズで定義している。下へ行くほど、関与する人数は増える。
| フェーズ | 買い手の心理 | 次のフェーズへ移るきっかけ |
|---|---|---|
| 1. 現状防衛 | 今のままで特に問題ない | 上司の一言、年度のタイミング |
| 2. 表層的違和感 | 来期に向けて何かネタを | 目標管理未達、KPI未達 |
| 3. 調査・学習 | やり方の問題だろうか | 手段では解決しないと気づく |
| 4. 真の違和感 | これは根深い問題だ | 放置リスクが可視化される |
| 5. 責任引受 or 回避 | 自分が背負うか(最大の分岐点) | 期限、指示、競合動向 |
| 6. 巻き込み・検証 | 一人では無理。失敗しないか | 勝ち筋が可視化される |
| 7. 合意形成 | 反対は出るが、懸念を潰そう | 判断材料が揃う |
| 8. 決断 | 今やる意味がある | — |
入口をどのフェーズに置くかに、汎用の正解はない。 決めるのは次の4つである。
- 競合状態|早期に囲い込まなければ候補に残れない市場ほど、入口は前へ出す
- コモディティ化の度合い|選定が価格で決まる商材では、前に出ても順位は変わりにくい
- 単価と検討期間|単価が高く検討が長いほど、前に出て関与できる余地が大きい
- 営業リソース|前へ出せば1件あたりの接触は薄くなる。追える本数の上限が線を決める
この4つから、どの時点までに入っていなければ手遅れになるかを出す。手遅れの線が決まれば、入口はその手前に置くしかない。
あとはそのフェーズに入ったと言える条件は何かを洗い出せばよい。それがそのまま、商談を作りにいく条件になる。 手がかりは表の3列目、移行のきっかけである。そのきっかけが自社の側から観測できる事実として現れるなら、条件として書ける。 3条件のうち買い手とニーズは、商談が立つ前から観測できる。そしてその情報は、マーケティング側にすでにある。
線を前に置いた場合、その時点ではソリューションがまだ特定されていない。動かすのは起票そのものではなく、その手前の営業活動の開始である。 対話の中でソリューションが定まり3条件が揃えば、そこで商談が立つ。活動の開始を前に動かせば、起票も一緒に前へ動く。
ただしデータだけで商談かどうかは判定できない。 3条件の確認は対話の中で行うことになる。データが決めるのは判定の結果ではなく、判定を始める時点である。
判断② 誰が決めるのかを、どう見つけるか
前半のフェーズが進んだからといって、商談が進んだことにはならない。 課題が言語化され、調べられ、社内で話題になる。目に見える動きは増えるが、決める人はまだ登場していない。
白書によれば、1,000万円以上の購入における関与者は平均18.3名にのぼる。ただし標準偏差が51.3と大きく、典型的な案件は中央値の5名前後と見るのが妥当だ(n=120/単発購入の最高額ベース)。
この5名は、同じ関心では動いていない。 分けずに扱えば、熱心な一人の反応を商談全体の前進と読み違える。停滞の多くは、その一人の後ろにいる決定者を見つけられていないことで起きている。
購買グループの人物は、レベニューへの影響という観点で4つの役割に分けられる。役割が分かれば、その人に何をすべきかも決まる。
| 役割 | 特徴・ペイン | 動かし方 | 主なアプローチ |
|---|---|---|---|
| 着火役 | 表層課題の処理者。権限はないが違和感を持つ。孤立や失敗を恐れる | 本質課題を社内で使える言葉に翻訳し、武器を渡す | 診断コンテンツ、比較表、上司説明用の資料 |
| 旗振り役 | 課題を背負う責任者。成果と期限を負うが、進め方に不安がある | どう進めれば失敗しないかのロードマップを示す | ワークショップ、壁打ち、稟議用の資料 |
| 番人 | 専門家・ご意見番。止める力を持つ。リスクや前例を重視する。金庫番の片腕としても動く | 説得しようとせず、懸念を先回りして潰す | FAQ、技術資料、PoC、セキュリティチェック |
| 金庫番 | 予算と優先順位を握る決裁者。ROIと経営合理性で判断する | 長く語らず、1枚で投資判断ができる根拠と責任体制を示す | 1枚サマリー、ROI試算、導入後のガバナンス資料 |
着火役は、競合を教えてくれる人ではない。 課題に対して情報を集める立場であり、多くの場合こちらの初回の接点になる。決める権限はなく、どこと比べられているかの全体像も持っていない。
見るべきは、その人が旗振り役へ話を上げる意思を持っているかどうかだ。 集めた情報を旗振り役へ渡し、助言として上げてくれるか。そこが連携すれば商談は動き、上がらなければ情報収集のまま終わる。着火役だけを相手にしていると商談が前半で止まるのは、このためである。
では、それぞれの役割から何を取りに行くのか。語彙としては MEDDPICC(メドピック)が使いやすい。商談の状態を8つの観点で確認する、複雑なBtoB営業向けの案件見極めのフレームワークだ。8つは並列ではない。それぞれ、取れる相手が違う。
| 観点 | 何を確認するか | 誰から取るか |
|---|---|---|
| Metrics | 導入で得られる定量的な効果 | 金庫番 |
| Economic Buyer | 決裁権を持つ人 | 金庫番 |
| Decision Criteria | 買い手が使う評価基準 | 番人 |
| Decision Process | 意思決定に至るまでのステップ | 旗振り役 |
| Paper Process | 意思決定のあと、署名までに通るステップ | 番人 |
| Implicate the Pain | 課題の掘り起こし | 着火役 |
| Champion | 社内で推してくれる人 | 着火役(旗振り役へ上げる意思があるか) |
| Competition | 競合 | 旗振り役 |
埋まらない観点があるなら、その役割にまだ接触できていない。

とりわけ4つめと5つめは、別のものとして分けておきたい。買い手が「導入する」と決めることと、実際に契約書に署名が入ることは同じではない。そして多くの商談は、前者ではなく後者で止まる。Gong Labs は100万件超のメールと約3万件の商談通話(2022〜23年)を分析している。後期段階に法務が関与している商談の勝率は、関与していない商談の2.6倍だ。この場合の法務は番人の一例にすぎない。番人が誰になるかは案件ごとに変わる。 職種で決め打ちせず、その案件で止める力を持っているのは誰かで特定する。
実装上の論点は、この登場人物をどのオブジェクトで持つかだ。Salesforce の「取引先責任者の役割」(Opportunity Contact Role/OCR)は、まさに購買グループを管理するためのものだ。ただし商談に紐づくので、商談の存在が前提になる。 判断①で入口を前へ出すほど、商談が立つ前の登場人物はここに置けないという制約に当たる。
では前段はどこで持つのか。効いてくるのは企業単位・人物単位の名寄せである。表記ゆれや部署違いでレコードが分かれていれば、複数人の動きが複数社の動きに見える。そしてどの単位でグルーピングするかは、狙うターゲット属性によって変わるだろう。 白書も、顧客データを企業 → 部門・プロジェクト → 個人 → 役割の階層で持ち直すよう提言している。個人単位のリードのままでは、複数人が同じ課題に向かっている事実を検知できない。
役割が埋まっていない商談は、動いているように見えても決まらない。 見るべきは接触の量ではなく、4つの役割のうち、いくつを特定できているかである。
判断③ 確度をどう出すか
ここまでを直せば予測も当たる、とはならない。主観が入る経路が2つ残っているからだ。
ひとつめは、確度がステージに紐づいていること。多くの組織で、確度はその商談固有の見立てではなく、ステージに割り当てられた設定値であり、その数字は導入時の初期値のままだ。実測に基づかない確度は、ステージ名を言い換えただけの数字である。
ふたつめは、予測にどう載せるかだ。予測カテゴリは5区分あり、ステージごとにどれへ載せるかを割り当てる。
| 予測カテゴリ | 予測に載るか | 何を表すか |
|---|---|---|
| Pipeline | 載る | 進行中の商談すべて。予測の母数になる |
| Best Case | 載る | 順調に進めば取れる見込み |
| Commit | 載る | 高い確度で今期に閉じると約束するもの |
| Closed | 載る | 受注として確定した分 |
| Omitted | 載らない | 予測から外す。案件別に予測しない領域を置く場所 |
問題は、この割り当てとは別に、担当者が個別の商談を Commit へ動かせることだ。 そこに手をつけなければ、ステージ定義をどれだけ作り込んでも、予測に載る数字は担当者の申告のままである。
では確度をどう出すか。ステージの属性としてではなく、実測の結果として出す。 各ステージを通過した商談がどれだけ受注に至ったかを自社の履歴から算出し、設定値をその実測値に置き換える。ただし実測値が意味を持つのは、履歴が実態を映しているときだけだ。 先祖返りを許さない運用のままでは、後退した商談が前進した位置に留まって集計に入り、転換率は実態より高く出る。
判断④ 誰が、何を動かせるようにするか
3つを決めても、定義書の中にあるだけなら半年後には元に戻る。最後はどこに実装するかだ。実装先は必須項目・入力規則・Path・権限の4つ。定義書やマニュアルではなく、システム下でルール化される方法にしないと、運用は回らない。
完了予定日の後ろ倒しは禁止しない。買い手の都合でずれることは実際にあるからだ。代わりに理由を記録の対象にする。 変更を1操作のままにして理由の選択を1つ足すだけで、回数と理由が履歴に残る。
先祖返りは、実装より先に外すものがある。ステージを下げると評価が下がる運用だ。ただし「評価制度を変えよう」では精神論になる。ステージ履歴は残っているので、期初の見立てと着地の実績を別々に取り出せる。評価の対象を「いま何を持っているか」から「期初の見立てがどれだけ当たったか」へ変えれば、正確に下げたほうが評価が上がる。
予測カテゴリの上書きは禁止せず、誰が上書きできるかを分ける。 決めていなければ、全員が上書きできる状態が既定になる。担当者以外が確認できる事実にだけ、必須化と入力規則をかける。 「顧客の温度感」のように確認できない項目を必須にすると、保存するために埋めるだけの入力が生まれ、項目は増えて、情報は増えない。
その営業に、そもそもパイプライン管理は向いているのか
この判定は、設計に着手する前に済ませておくべきものだ。 向いていない領域に案件別の管理を敷いても、確定直前の商談しか並ばない台帳がもう一つできるだけである。
適合性は、金額と頻度で決まる
商談を1件ずつ管理することに意味があるのは、次の3つが揃うときだ。①毎回、選定が行われる ②検討に時間がかかる ③関与者が複数いる。この3つは、買い手の取引金額と頻度でおおよそ決まる。
| 小口・高頻度(n=154) | 中口・中頻度(n=46) | 大口・低頻度(n=30) | |
|---|---|---|---|
| 1ヶ月未満で契約 | 69.5% | 26.1% | 6.6% |
| 3ヶ月以上かける | 7.8% | 26.1% | 33.3% |
| ほぼ毎回決まった先から | 47.4% | 23.9% | 3.3% |
| 都度選定 | 12.3% | 17.4% | 56.7% |
| 関与人数(平均/中央値) | 7.2人/3人 | 20.8人/5人 | 11.4人/5人 |
※『2025年度版 BtoB購買プロセス白書』。中口・中頻度と大口・低頻度はサンプル数が少なく、白書上も参考値として扱われている。なお関与人数は購買セグメント別の集計で、判断②に挙げた価格帯別の集計とはベースが異なる。
小口・高頻度では、案件別の管理が成立しにくい。 状態を追う前に決着し、選定も行われず前回と同じ取引先に発注している。通過を観測する時間が、そもそも存在しない。 逆に大口・低頻度が最も効く。 案件別の管理が前提としている条件が、そのまま揃っている。難しいのは中口・中頻度で、短期決着と長期検討が同率で並ぶ(参考値)。単一のステージ設計では、どちらかが必ず合わない。
ただし金額と頻度は目安であって、判定そのものではない。 効いているのは1番目——毎回、評価と選定が行われるかどうかだ。高額でも、決まった仕様を定期的に補充する取引なら選定はほとんど起きない。逆に金額が小さくても、競合との提案競争があり内容が都度評価されるなら、毎回勝負が発生しているのでパイプラインが要る。なお区分は買い手の1回あたりの取引金額によるもので、売り手の商材単価とは一致しない。
もっとも、選定が起きない取引というものは存在しない。 決まった先から買い続けているように見えても、買い手がそこから買い続ける保証はどこにもない。代替品の登場も、新規参入も、いつでも起こる。選定が起きていないのではなく、こちらに見えていないだけである。 だから案件別の管理を外す判断は、その取引を追わなくてよいという意味にはならない。選定が起きたときに気づける状態だけは、別に確保しておく。
直販以外のチャネルでも、判定は同じ
チャネルそのものではなく、その案件が個別に動くかどうかで決まる。 パートナーセールスは3条件を満たすので管理は必要だが、商談は存在しているのに自社のSFAに入らない。 課題は適合性ではなく可視性で、間接では登録する動機を設計することになる。それが Deal Registration(案件登録)だ。登録したパートナーは他パートナーや自社直販と競合しない保護や条件面の優遇を受け、売り手はその対価に可視性を得る。インセンティブが生成起点になる設計である。EC・セルフサーブは3条件を満たさないので小口・高頻度と同じ扱いだが、一定金額を超えた注文や個別見積の依頼はそこから個別に動く。どの条件を超えたら商談として立てるかの閾値を決めることになる。直販ではデータ、間接では登録の見返り、ECでは閾値。起点の作り方が違うだけで、設計している対象は同じである。
向かない領域は、どう管理するか
見る単位を、商談からペースに変える。 今月は何件成立し、平均単価はいくらで、先月とどう違うか。過去の成立ペースから翌期を推定する、ラン・レートによる予測だ。
共存の仕組みは、Salesforceにそのままある。予測カテゴリの Omitted——予測に含めない区分である。案件別に予測すべきセグメントは Pipeline・Best Case・Commit に載せ、ラン・レートで見るセグメントは Omitted に置く。商談としては記録するが、積み上げには載せない。これでステージの定義は全社で共通のまま、予測の方式だけをセグメントで分けられる。
分けることには別の意味もある。混ぜて集計すると、判断③の実測転換率が歪む。 1ヶ月未満で決着する商談と3ヶ月かかる商談を平均すれば、どちらの実態も表さない数字が出る。
精度を上げるとは、何を上げることなのか
精度という言葉は、一語のままでは噛み合わない。営業推進が言う精度と、経営が言う精度と、Sales Ops が言う精度は、たいてい別のものを指す。
| 何の精度か | 問い | 崩れているときに出る症状 | 効く判断 |
|---|---|---|---|
| 生成の精度 | 実態のある案件を、実態のあるタイミングで捉えられているか | 決着間際の商談しか載らず、検討中の商談が空白になる | 判断①(入口) |
| 状態の精度 | いま記録されているステージは、買い手の現実と一致しているか | 決定者が特定できていない商談が、後期のステージに並ぶ。先祖返りが記録されず、滞留が見えない | 判断②(登場人物)・判断④(権限) |
| 着地の精度 | この期に閉じると言った商談は、この期に閉じるか | 完了予定日のスリップが繰り返される | 判断③(確度)・判断④(権限) |
多くの組織が「パイプラインの精度」と言うとき指しているのは3つ目だが、着地の精度は最後に出てくる結果であり、最初に手をつける対象ではない。 生成が歪んでいれば母集団そのものが偏っており、どれだけ精緻な予測手法を当てても見通しは出てこない。状態が歪んでいれば集計の分母がずれる。精度の高い手法を、歪んだ母集団に当てているだけになる。
だから順序は生成 → 状態 → 着地である。入口を買い手のフェーズの側から決める(判断①)。決定者まで登場人物を埋め、戻す操作を正常な操作として設計に含める(判断②・④)。そのうえで確度を実測値へ置き換える(判断③)。先の2つを直せば、予測手法を高度化しなくても着地の精度は上がりはじめる。
どの指標で測るか、カバレッジの倍率をどう設計するか、予測モデルをどう実装するかは本稿では扱わない。担当したのはその手前——測る前に、測れる形をSFA上に作ることである。
まとめ
パイプラインが受注直前にしか立たないのは、現場が入力を怠っているからではない。商談を生む起点を「営業が確度を持てたとき」に置いた設計の、当然の帰結である。 買い手は営業に会う前に候補を絞り終えている。その状態で「確度が持てたら登録する」と決めれば、登録は構造上、終盤にしか起きない。入力ルールを厳しくしても直らないのは、直す対象が入力態度ではなく設計だからだ。
では設計を何で決めるか。売り手の都合ではなく、買い手の心理がどこまで動いたかで決める。 買い手の検討は8つのフェーズを踏んで進み、後半に行くほど関与者が増える。どのフェーズを入口にするかに汎用の正解はなく、競合状態・コモディティ化の度合い・単価と検討期間・営業リソースで変わる。決めるべきは「どの時点までに入っていなければ手遅れになるか」で、入口はその線の手前に置く。
入口を前へ動かしたあとに効いてくるのが、誰を見ているかである。 前半のフェーズが進んでも、それは決定者が動いたことを意味しない。購買には複数の役割が関与し、熱心に情報を集めてくれる着火役には決める権限がない。役割ごとに取りに行くものを決め、4つの役割のうちいくつを特定できているかで商談の進みを測る。ここを飛ばすと、活動量は増えているのに決まらない商談が積み上がる。
そのうえで、確度と権限を担当者の手から外す。 ステージに割り当てられた確度は実測ではないので、自社の履歴から出した転換率に置き換える。予測カテゴリを誰が動かせるかを決めていなければ、ステージ定義をどれだけ作り込んでも、予測に載る数字は担当者の申告のままになる。
注意すべきことが3つある。
ひとつは、入口を前へ出すこと自体が目的ではないということだ。前へ出せば1件あたりの接触は薄くなる。追える本数の上限を超えて広げれば、実態のない商談が並ぶだけになる。
ふたつめは、ステージを戻す操作を、異常な操作にしないこと。 下げると評価が下がる運用のままでは、現場は戻さない。戻らないステージの上で集計した転換率は、実態より高く出る。評価の対象を、いま何を持っているかから、期初の見立てがどれだけ当たったかへ移す。
みっつめは、案件別の管理を外した領域を、追わなくてよい領域と取り違えないこと。 選定が起きない取引は存在しない。代替品も新規参入も、いつでも起こる。ペースで見ると決めた領域にも、選定が起きたときに気づける状態は残しておく。
そして、決めていない項目は既定値のまま動いている。既定値とは、たいてい担当者の判断のことである。 入口も、確度も、上書きの権限も、決めなければ現場の裁量として運用される。ステージの数と名称を先に議論しても、この順序は変わらない。
よくある質問
Q. 商談は、いつ作るのが正しいですか。 買い手・ニーズ・ソリューションの3つが特定され、金額と時期を置ける状態になった時点である。ただし、その時点を待って動くのではない。入口を買い手のどのフェーズに置くかは、競合状態・コモディティ化の度合い・単価と検討期間・営業リソースで決まる。 どの時点までに入っていなければ手遅れになるかを先に出し、その手前から活動を始める。
Q. 商談ステージは、何段階が適切ですか。 段数に正解はない。基準は、各ステージに、担当者以外が確認できる通過条件を1つ以上置けるかである。置けない段階は担当者の感覚でしか判定できないので削る。
Q. 確度のパーセンテージは、廃止すべきですか。 廃止ではなく、出所を変える。ステージに割り当てられた設定値をやめ、自社の実績から算出した転換率を使う。数字そのものではなく、その数字がどこから来たかが問題である。
Q. 完了予定日を後ろに倒すのは、禁止すべきですか。 禁止しない。買い手の都合でずれることは実際にあり、禁止すれば別の場所に歪みが出る。見るべきは1回の後ろ倒しではなく、同じ商談で何度繰り返されたかである。
Q. 何から手をつけるべきですか。 設計を変える前に、自社のステージ履歴を見る。外部のベンチマークを探す前に、その答えは自社の履歴に入っている。
次の一手は、Revenue Benchmarkを試す
パイプライン管理の課題を解決するためには、商談の起点を明確にし、営業の手応えに頼らない仕組みを整えることが不可欠です。それが実現できれば、受注予測の精度を大きく向上させることができます。ここで重要なのは、自社の営業プロセスを客観的に評価できる基準を持つこと。Revenue Benchmark Appsを活用し、自社の主要指標を業界ベンチマークと比較して、どこに改善余地があるのかを探ってみてはいかがでしょうか。
APP
Revenue Benchmark で自社の収益力を診断
主要指標を業界ベンチマークと比較し、伸びしろを可視化します。
- 無料で診断
- 業界平均と自動比較
- 改善ポイントを提示
出典情報の詳細
- ワンマーケティング『2025年度版 BtoB購買プロセス白書』(2025年/n=600。設問により n=94〜600)
- 6sense『2025 B2B Buyer Experience Report』(2025年/約4,000名) https://6sense.com/science-of-b2b/buyer-experience-report-2025/
- Ebsta × Pavilion『2025 Go-to-Market Benchmarks Report』(2025年/65万5,000件の商談・349社・CRO 2,000名超) https://www.ebsta.com/2025-b2b-sales-benchmarks-report/
- UPWARD『フィールドセールス活動実態と業務課題調査』(2026年5〜6月/営業職370名。設問ベース n=265) https://upward.jp/weblog/sfa-adoption/
- Gong Labs(100万件超のメール・約3万件の商談通話/2022〜23年) https://www.gong.io/resources/labs/
- Forrester『Demand Unit Waterfall™』(デマンドユニットの成立条件) https://www.forrester.com/b2b-marketing/b2b-revenue-waterfall-guide/
- Forrester「Surprise! You Can Set Up the Demand Unit Waterfall™ in Salesforce With Standard Functionality」(OCR=購買グループのオブジェクト) https://www.forrester.com/blogs/set-up-demand-unit-waterfall-in-salesforce/
- Salesforce ヘルプ「Manage Opportunity Stage to Forecast Category Mappings for Pipeline Forecasts」(予測カテゴリの5区分と上書き) https://help.salesforce.com/s/articleView?id=sales.faq_forecasts_category_mapping.htm
- Salesforce ヘルプ「Opportunity History」(ステージ履歴に記録される項目) https://help.salesforce.com/s/articleView?id=sales.opp_history.htm
- Salesforce ヘルプ「Create Salesforce Report on Duration of Opportunity Stage」(Stage Duration の測り方) https://help.salesforce.com/s/articleView?id=000392663
- Salesforce ヘルプ「Close Date Required When Creating a New Opportunity in Salesforce」(完了予定日の必須指定) https://help.salesforce.com/s/articleView?id=000392275
- Clari「What is Deal Slippage: Everything You Need to Know」(クローズデートのスリップの定義) https://www.clari.com/blog/deal-slippage-everything-you-need-to-know/

