今週のワーキングセッションは 2 本、同じクライアント、同じ部屋、ホワイトボードには 2 つの異なる問題、そのうちの 1 つが、チームが 1 年間抱えてきた静かな Pipeline 診断でした。先方の Head of Sales が公式の HubSpot Pipeline を開き、Deal ステージを一通り眺め、そして部屋に向かって一瞬宙に残るような問いを投げました。まだ移していない 50 件の SQL はどうなっているのか。誰も答えませんでした、答えを持っていなかったからです。Sales Meeting を取り、初期の Qualification を通過し、Lifecycle Stage は SQL のまま Contact Record のどこかに置かれた 50 件の Lead、しかし Deal Record はない。Forecast から見えない。Pipeline Review から見えない。来四半期の Capacity 会話からも見えない。このギャップは、今この瞬間における中期 B2B SaaS の HubSpot インスタンスで最も高くつく構造的な選択であり、それは HubSpot の問題ではありません。Deal が「いつ始まるか」をいつ決めるか、の問題です。
なぜ今これが重要なのか
Jason Lemkin の 1 月の「2026 Sales Reckoning」レポートは、進行中の構造変化について率直でした。AI ネイティブの B2B チームは、前世代の半分ほどのサイズの Sales ベンチを回しており、AI 駆動のアウトバウンドが彼自身の組織で 90 日以内に新規 Pipeline の 4 分の 1 を生成しています。それが、このギャップが現れるマクロな絵柄です。AI で縮小された Sales チームは構造的な問題を悪化させます、MQL と Deal Record の間のギャップを手で埋める SDR レイヤーはもう存在せず、Discovery を回すのは AE 本人で、AE は本物だと確信できるまで Deal の作成を延期するインセンティブをあらゆる方向から受けます。これを 10 人のレップと 1 四半期で掛け合わせると、50 件の SQL の引き出しができます。Forecast が間違っているのは、Close Date モデルが悪いからではありません。Pipeline が Deal を含んでいないから間違っているのです。
SQL ギャップが HubSpot のどこに住むか
HubSpot の Lifecycle は Contact プロパティの形をしています、subscriber、lead、MQL、SQL、opportunity、customer。Deal は別オブジェクトで、Contact の Lifecycle が opportunity ステージに移ったときに、通常は作成されます。この慣行は原則として妥当ですが、実務では災害です。なぜなら、多くの Sales チームでの opportunity の運用上の定義は「Pipeline にコミットするだけの確信がある」だからです。その確信のしきい値は健全ですが、高い。Meeting Booked は opportunity ではありません。最初の Discovery Call は opportunity ではありません。Follow-up Demo すら、Budget が検証されていなければ opportunity ではありません。したがって本物の Lead は、Contact Record の上、Deal を付けず、SQL Lifecycle Stage で 4〜8 週間を過ごすことになります。AE は仕事をしています。システムは何も映していません。
50 件の SQL の引き出しはその結果です。プロセスの失敗ではありません。設計通りに動いているアーキテクチャが、スキーマにもはや一致しない Sales モーションに適用されているだけです。コストは Pipeline Review まで見えません。誰かが「Marketing の MQL 数と Deal Pipeline の Deal 件数の間で何が起きているのか」と尋ね、誰もその橋を生み出せないとき、初めてコストが現れます。
支配的な知恵は「Deal をもっと遅く作れ」
標準的なアドバイス、Lemkin の SaaStr Q&A がまさにこの問いに対する最も明瞭な定式化です、は、待つこと。ICP、pain、engagement、buying intent がすべて確認されたときに初めて Lead を opportunity に変換する。論理は妥当です。Deal を早く作りすぎると Pipeline は膨れ、coverage ratio は歪み、Forecast はノイズになり、レップは Deal を本物のコミットメントとして扱う規律を失います。Lemkin の具体的な言い回しは、早く変換しすぎると Pipeline を詰まらせ Sales リソースを浪費する、遅く変換しすぎると Momentum を失う、というものです。多くの CRO はそれを読み、より安全な側を選びます、遅い側を。
遅い側を選べば Forecast Accuracy は守られますが、2026 年により必要となる 2 つのものを諦めることになります。Pipeline Visibility と、まだ Deal にカウントされていない In-flight ワークに対する AE の Accountability です。引き出しの 50 件の SQL は、まさに AE がやっている仕事です。それらはシステムの中にいません。だから AE はそれらに責任を負わず、Head of Sales はそれらを見ることができず、Forecast はそれらに値段を付けられず、Ramp モデルはそれらに対して Capacity を計画できません。クリーンな Coverage Ratio のために支払う代償としては高すぎます。
Pre-pipeline ステージ：第 3 の選択肢
私が推奨するのは、遅くも早くもありません。両方であり、フィルタで分離します。Meeting Booked で Deal を作成、AE が時間をコミットし、見込み顧客がカレンダーをコミットした最も安価で信頼できるシグナル、しかし、それを Pre-pipeline と呼ばれる Deal ステージに作成し、デフォルトの Win Probability を 0 % または 5 % にし、インスタンス内のすべての Forecast Report、Dashboard Widget、Coverage Calculation、Weighted Pipeline ビューからフィルタアウトします。Deal は Accountability、Visibility、Tracking のために存在します。Forecast のためには存在しません。定義された Exit Criterion を通過することで Pipeline に入る権利を得るまでは、どこの単一の Revenue 数字にも集計されません。
これはアーキテクチャ自体に適用した Keep-Edit-Delete のムーブです。標準ルール「Qualification の時点で Deal を作る」には、異なる仕事をしている 2 つの目的が同居していました。Forecast をノイズから守ること、そして Deal Record をコミットされた仕事のために予約することです。Pre-pipeline ステージは、フィルタリングによって最初の目的を無傷で保持し、Deal Record はセグリゲートされている限りコミットされていない仕事も運べると言うことで、2 つ目を編集します。Forecast はクリーンに保たれます。50 件の SQL の引き出しは存在しなくなります。
3 つのガードレール
Pre-pipeline ステージは、3 つのフィルタが初日から交渉不可であるときにのみ機能します。どれか 1 つでも甘くなれば、1 四半期以内に Bloat が忍び戻り、Head of Sales が変更を巻き戻します。
第 1 に、すべての Forecast Report、Dashboard Widget、Pipeline Coverage Calculation は、Pre-pipeline ステージをデフォルト条件としてフィルタアウトしなければなりません。Opt-in フィルタではなく、デフォルトです。保存されたあらゆる View、あらゆる CRO Dashboard、あらゆる Weekly Forecast Meeting Deck を監査します。たった 1 つの Chart でも Pre-pipeline と Qualified Pipeline を同じカラムとして並べて表示しているなら、アーキテクチャを正当化する規律を失ったということです。
第 2 に、Pre-pipeline のデフォルト Win Probability は 0 % または 5 % で、決してそれより高くしません。一部のチームは、より誠実に感じるからと 10〜30 % に手を伸ばします。抵抗してください。要点は、Pre-pipeline にあるものに基づいて Weighted Pipeline 数字が動かないようにすることです。0 が最もクリーン、5 は許容範囲、それより上は、誰かがフィルタを変えた瞬間に Pre-pipeline Deal が Revenue 予測に現れ始めるよう招くことになります。
第 3 に、Pre-pipeline Deal は、90 日無進展の硬いルールで自動アーカイブされます。HubSpot Workflow が毎晩 Pre-pipeline Deal をチェックします。ステージが 90 日変わっていなければ、Deal は Closed Lost に移り、Lost Reason は「no advance from pre-pipeline」になります。例外も延長もありません。Late-creation Pipeline を破壊するゾンビ Deal 問題は、放置すれば Pre-pipeline も破壊します。Pre-pipeline を可視で小さく保つのが、90 日ルールです。
現場からのパターン
私たちは最近、DACH の Series B B2B SaaS チームと仕事をしました。Mid-market モーションを少人数の AE ベンチと SDR レイヤーなしで回しているチームです。四半期ごとの Pipeline Review は毎回同じ壁に当たっていました。Head of Sales が公式 Pipeline を一通り眺め、Qualified から Commit まで 20〜30 件の Deal、そしてチームに「まだ正式に移していない他の Deal」について尋ねます。返答は常に「Budget の確認待ち」または「Deal を開く前に Discovery を綺麗に通過させたい」のバリエーションでした。AE はどちらの点でも間違っていません。書かれた通りに Late-creation ルールを適用していただけです。結果として、チームの実際の In-flight ワークの約半分がシステムの外にありました。Pipeline Coverage は薄く見えました。来四半期の Capacity モデルは供給不足だと言いました。両方の読み方が間違っていました。チームはインスタンスが報告しているよりも多くの Pipeline を抱えていました。
私たちは Pre-pipeline ステージを Deal Pipeline の新しい第 1 ステージとして追加し、Win Probability を 0 % にデフォルトし、すべての Forecast View をそれをフィルタアウトするように書き直しました。Meeting-Booked Workflow は彼らの Scheduling ツール経由ですでに配線されていました。私たちはそれを拡張して Pre-pipeline Deal を自動で作成し、Contact と Company に関連付けました。2 週間以内に、チームから見える Deal Count は倍増しました。3 週間以内に、Head of Sales は Non-pre-pipeline にフィルタし、Forecast 数字が動いていないことを確認しました、それが私たちが通したかったテストでした。2 か月後、Pipeline Review Meeting は自ら再構成されていました。前半は以前と同じく公式 Pipeline を回し、後半はソートされた Pre-pipeline リストを 1 件 1 問で回します、これを Pre-pipeline から出す次の一手は何か。50 件の SQL の引き出しは存在しなくなりました。来四半期の Capacity 会話は、推測から具体へと移りました。
HubSpot で Pre-pipeline ステージを配線する方法
- 主要な Deal Pipeline に新しい第 1 ステージを追加します。「pre-pipeline」または「engaged」と命名、ラベルは、その後に来るフィルタリングの規律ほどには重要ではありません。デフォルト Win Probability を 0 % に設定。ステージタイプは Open Stage のままにし、Closed にはしません。
- Meeting-Booked Workflow を構築します。Trigger:Sales レップのカレンダー上で、お使いの Scheduling ツール（HubSpot ネイティブの Meetings ツール、または配線されているスケジューラ）経由で Meeting が予約された時。Enrollment Criterion:Meeting Type が Sales 会話であり、Customer Touchpoint ではないこと。Action:Pre-pipeline ステージに Deal を作成し、Contact と Primary Company に関連付け、Deal Owner を Meeting Host に設定し、Deal Name を Contact 名と Meeting 日付のテンプレ化された文字列に設定。
- インスタンス内のあらゆる Forecast Report、Dashboard Widget、Pipeline Coverage Calculation を監査します。各々にフィルタを追加します:deal stage is not equal to pre-pipeline。デフォルト View、デフォルト Dashboard、Weekly Forecast Meeting Deck、CRO Summary Widget。すべて。1 つでも飛ばせば、誰かが Board Meeting で Chart を見せた日に、アーキテクチャを正当化する規律が漏れ始めます。
- 別の Pre-pipeline Review Report を構築します。Last Engagement で、次に ICP Fit Score でソート。これが AE とそのマネージャーが Pipeline Review Meeting の後半で作業する成果物です。1 行あたり異なる問い、「Close への道筋にあるか」ではなく「これを Pre-pipeline から進める次の一手は何か」。
- Exit Criterion を定義します。私たちが使う最小値は SPICED 検証済みの Discovery です、Situation、Pain、Impact が Deal Record またはリンクされた Discovery Note 上に書面で確認されていること。これら 3 つが確認されると、Deal は最初の Qualified ステージに進みます（あなたのインスタンスでは「qualified」「discovery complete」あるいは第 2 ステージの名前は何であれ）。Exit Criterion は、クリーンな Pre-pipeline ステージと、解決しようとしていた Bloat 問題がゆっくり拡大することとの違いです。
- Auto-archive Workflow を構築します。Trigger:日次のスケジュール済み Workflow。フィルタ:deal stage equals pre-pipeline AND deal stage last-changed date is more than 90 days ago。Action:Deal を Closed Lost に移し、Lost Reason を「no advance from pre-pipeline」に設定し、Deal Owner に通知。90 日は多くの Mid-market B2B SaaS モーションにとって正しい数です。年次予算サイクルを持つ Enterprise モーションでは 120 日まで擁護できます。それより高くはしません。
- Pipeline Review Meeting を再構成します。前半:公式 Pipeline。後半:Pre-pipeline。異なる問い。異なるリズム。会話の異なる責任者がいるならそうします。Meeting の中の構造的分離が、システムの中のアーキテクチャ的分離が現実であり、奇妙なフィルタではないことをチームに教えます。
Checkpoint の関わり方
Deal Stage アーキテクチャに触れるHubSpot 実装のエンゲージメントのほとんどは、最終的には Pre-pipeline ステージの何らかのバージョンを出荷することになります。HubSpot のベストプラクティスではありません、公式のガイダンスはいまだに Late-creation ルールをデフォルトとしています、そして 1 行の設定変更でもありません。3 つのガードレールが尊重されなければならない、1 つのアーキテクチャ的選択です。リターンは、次の Pipeline Review に現れます。引き出しの 50 件のホット SQL は、見ることができ、話すことができ、優先順位を付けることができる 20 件の Pre-pipeline Deal になり、その間 Forecast 数字は以前と全く同じ精度のまま残ります。あなたのRevenue Operations インスタンスに、誰も Forecast していない、誰も見つけられない SQL の静かな引き出しがあるなら、Pre-pipeline ステージは Forecast を壊さずに Visibility 問題を解決する最小のアーキテクチャ変更です。
出典
- Lemkin, Jason.「The 2026 Sales Reckoning: Why Your Traditional Sales Team Is About To Look Very Different」SaaStr、2026 年 1 月。saastr.com
- Lemkin, Jason.「Dear SaaStr: At What Point Should a Lead Convert to an Opportunity?」SaaStr.saastr.com