私が引き継ぐ B2B HubSpot インスタンスのほとんどは、1 つの Pipeline で 2 つの仕事をしています。Deal Pipeline は AE のコマーシャル業務、Discovery、認定、提案、交渉、を追跡し、AE が所有しない運用業務、オファー生成、技術的フィットチェック、KYC、契約承認、ときにオンボーディング、も追跡しています。それらすべてを Deal ステージとしてモデル化したい本能はホワイトボード上では整然と感じられます。ライブのレベニューシステムでは、AE がコーディネーターでデータが間違っている、遅くフォーキャスト不能な Pipeline を生みます。
なぜ今これが重要なのか
B2B 購買は単純になっていません。Brent Adamson、Matthew Dixon、Nick Toman は 2012 年に Harvard Business Review で、Sales 担当者の伝統的な仕事、ニーズを発見し、ソリューションを推奨する、はすでに洗練された調達と自分自身の答えを持って到着する購買側に食われている、と論じました。私が 2026 年に HubSpot で見るそのバージョンは構造的です。サービス重視のコマーシャルモーション、エネルギーと公益、規制された製造業、ハードウェアプラスオンボーディング、では、購買決定は AE の日常の外に住む業務によってゲートされます。その業務を Deal ステージとしてモデル化することは AE をより戦略的にしません。Deal Pipeline を誰か他のキューのプロジェクトトラッカーにします。
パターン：1 つのワークフローは Sales、もう 1 つは Operations
私がレビューするすべての Pipeline で有用な診断質問：このステージが進むために、誰がアクションを取らなければならないか？答えが一貫して AE なら、それは Sales ステージです。答えが一貫して別の誰か、Deal desk、オファーチーム、コンプライアンスレビュアー、CS リード、オンボーディングエンジニア、なら、それは運用業務であり、AE はフォーキャスト可能なタイムラインでそれを引き寄せるレバレッジを持ちません。
標準的な間違いは、運用業務を「オファー進行中」「コンプライアンスレビュー」「契約待ち」のようなステージとして Deal Pipeline に圧縮することです。AE はその後、動かせない Pipeline を所有します。フォーキャスト精度は崩壊します。任意のステージの年齢は AE が運用上のコントロールを持たない機能でのキュー時間が支配するからです。ステージ間の変換率は意味を持たなくなります。Deal がコンプライアンスレビューステージを去る率は、Sales 実行とは関係ないからです。
2 Pipeline アーキテクチャ
サービスゲートモーションのために HubSpot で推奨するアーキテクチャは、並行して走る 2 つの Pipeline です。
Deal Pipeline、AE が所有
ステージは AE が実際に駆動するコマーシャル決定を反映します：discovery、qualified、offering、contracting、Closed Won、Closed Lost。ステージ遷移は AE がコントロール可能な証拠でゲートされます：Discovery サマリーがキャプチャされた、フィットが確認された、オファーが要求された、署名済み契約が受領された。AE はこの Pipeline でフォーキャスト可能です。すべてのステージは彼らがやれることで進むからです。
Ticket Pipeline、RevOps または運用チームが所有
Deal の下には、運用業務を行う機能が所有する別の Pipeline 上の Ticket が座ります：オファー要求、入力検証、オファー生成、コンプライアンスクリア、契約送付。各ステージはそのチームが実際に行う業務を表します。Ticket は独自の SLA、独自のキュー、独自の担当者、独自のレポートを持ちます。RevOps またはオファーチームは、繰り返しますが、すべてのステージが彼らがやれることで進むので、この Pipeline でフォーキャスト可能です。
両者の間のゲート
Deal は関連 Ticket がクローズするまで Closed Won に到達できません。そのゲートがアーキテクチャ上の全要点です。AE は Ticket が進行中の間も販売することをブロックされません。Deal は contracting ステージに無期限に座れます。しかし Closed Won、ブッキング、コミッション、レベニューフォーキャスティングを駆動するステージ、は、Operations が業務を完了したときのみ発火します。Deal Pipeline はコマーシャルスループットを報告するようになります。Ticket Pipeline は運用スループットを報告します。ゲートは両者がカップルしたままであることを保証します。
必須フィールドゲートとデータ検証層
2 Pipeline アーキテクチャは、AE と Operations のあいだのハンドオフがクリーンな場合にのみ保ちます。最も一般的な失敗ポイントは AE が Ticket を作る瞬間です：運用チームは定義された入力セット、サイトアドレス、容量、技術仕様、KYC のための顧客エンティティ、契約テンプレート選択、を必要とし、ほとんどの場合それを得られません。修正は、Ticket 作成をトリガーする Deal ステージでの必須プロパティゲートです。
私がやること：オファーチームが開始する前に必要な入力を定義します。それらのプロパティを Deal を qualified から offering に動かすために必須にします。Ticket を作成するワークフローはそれらのプロパティをコピーします。ハンドオフでの AE の仕事はフォームを埋めることであり、ステータスのためにオファーチームを追いかけることではありません。
AE と RevOps のあいだのハンドオフトリガー
HubSpot 内のメカニカルな配線はストレートフォワードです。Deal ベースのワークフローが offering ステージへの遷移でトリガーし、オファー Pipeline 上に Ticket を作成し、Ticket Pipeline を最初のステージに設定し、必須 Deal プロパティをコピーし、Ticket を Deal と Contact に関連付けます。Ticket ベースのワークフローが Ticket がコンプライアンスクリアステージに到達したときにトリガーし、AE 向けダッシュボードが読む Deal プロパティ、offer_status のようなもの、を更新します。Ticket がクローズすると、最終ワークフローが AE が Deal を Closed Won に動かせる Deal プロパティを反転します。
これらのどれもエキゾチックではありません、すべての HubSpot インスタンスが持つ同じワークフロービルディングブロックです。重要なアーキテクチャ上の決定の部分：業務は自分の Pipeline に属し、AE の Pipeline はブロックされるのではなくゲートされ、2 つのシステムは小さな指名されたプロパティのセットを通じて協調します。
現場で見たパターン
ハードウェアプラスオンボーディングモーションを持つドイツのエネルギー SME が、11 ステージを持つ単一の Deal Pipeline でご相談に来ました。それらのステージのおよそ半分は運用でした：オファー進行中、技術レビュー、KYC、契約レビュー、署名。AE のフォーキャストは信頼できませんでした。任意の四半期のステージ年齢のほとんどが Operations のキュー時間だったからです。修正は AE が所有する Sales ステージを持つ Deal Pipeline と、オファーチームが所有する運用ステージを持つ別の Ticket Pipeline でした。Deal-to-Ticket ワークフローが必須フィールド検証付きでステージ遷移時に走り、Closed Won ゲートは Ticket がクローズしたときに更新される Deal プロパティでした。変更後、オファーチームは独自のキューと SLA を持ち、AE のフォーキャストはフォーキャストのように振る舞い始め、週次 Pipeline レビューは「私のオファーはどこに」から「次のコマーシャルステップは何か」へとシフトしました。
解決策：2 Pipeline プレイブック
今日 HubSpot でサービスゲートのコマーシャルモーションを運用しているなら、私が変更を実行する順序はこちらです。
- 現在の Deal Pipeline を監査してください。すべてのステージについて、AE がそれを進めるアクションを所有するかを問います。テストに失敗するステージをリストします、それらは間違った Pipeline 内の運用業務です。
- 並行 Ticket Pipeline を設計してください。ステージは運用チームが実際に行うことを、彼らが実際に使う言葉で反映します。オーナー、SLA、キュー割り当てがステージごとに定義されます。
- Deal-to-Ticket ハンドオフプロパティを定義してください。運用チームが開始する前に必要な最小入力セット。これらを Ticket 作成をトリガーする Deal ステージで進行に必須にします。
- ワークフローを構築してください。1 つのワークフローがステージ遷移で Ticket を作成しプロパティをコピーします。第 2 のワークフローが Ticket が意味のあるチェックポイントに到達したときに Deal を更新します。第 3 のワークフローが Ticket がクローズしたときにループを閉じます。
- Closed Won ステージを Ticket クローズでゲートしてください。関連 Ticket がクローズしない限り Deal は Closed Won に動けません。検証ルールまたは必須プロパティチェックで強制します。
- 新しい境界でダッシュボードを再構築してください。AE フォーキャストとコンバージョンレポートは Deal Pipeline で走ります。運用スループット、SLA コンプライアンス、キュー年齢は Ticket Pipeline で走ります。同じチャートから両方をレポートするのをやめます。
- 新モデルで AE チームをトレーニングしてください。もっとも一般的な反発は、AE が「オファーで何が起きているか見えない」というものです。答えは Ticket プロパティでフィードされる Deal 側ダッシュボードであって、1 Pipeline への回帰ではありません。
これら 7 つを行えば変更は数週間かかります。フォーキャストは 1 四半期以内に正直になり始めます。ステップ 1 を飛ばせば、置き換えるものと同じ境界問題を持つ並行 Pipeline を設計することになります。
Checkpoint がどう関わるか
Checkpoint で再設計するほとんどの HubSpot Pipeline はこの病理を持ちます：運用業務をする Sales Pipeline、フォーキャストのように振る舞わないフォーキャスト、データを信頼するのをやめたチーム。修正は新しいプロパティやよりスマートなダッシュボードであることはまれです。どの業務がどの Pipeline に属するか、どの機能が所有するか、どの証拠でゲートされるか、についてのアーキテクチャ上の決定です。その決定は RevOps と Customer Success オペレーションの継ぎ目に位置します。Pipeline がフォーキャストできない運用業務を運んでいるなら、それが行うべき会話です。
Harmeet Obhrai