HubSpot取引パイプラインの設計｜ステージを買い手側の出来事で区切る判断軸

取引パイプラインは何を判断するための仕組みか

取引パイプラインは営業の進捗ボードである前に、売上の見込みと、案件がどこで止まっているかを判断するためのデータ構造です。設計は、そこから出したい判断を先に決めるところから始めます。

取引パイプラインからは多くの数字が出ます。ステージ別の件数と金額、ステージ間の移行率、ステージごとの滞留日数、確度を掛けた見込み額、流入元別の受注。これらはすべて「同じステージに置かれた取引は、買い手の検討が同じところまで進んでいる」という前提で計算されます。前提が崩れていれば、レポートをどれほど作り込んでも数字は判断に使えません。

設計で決めることは6つあり、順番があります。画面上はステージ名を入力するところから始められますが、名前から決めると、その後の必須項目も確度も曖昧な定義の上に積み上がります。

出したい判断は、経営会議やパイプラインレビューで実際に見る数字から逆算します。会議で並べる数字がまだ決まっていなければ、先にHubSpotのレポートで見る項目を決めてからステージに戻ります。ステージを顧客側で確認できた事実で定義しておかないと、パイプラインカバレッジを計算しても、どの取引を分母に入れるかが担当者ごとにずれます。

パイプラインはデータを入れる前に決める設定の1つです。まだ取引を入れていないなら、通貨やタイムゾーンと一緒に初期設定の順番の中でパイプラインを決めると、後から取引を移し替える手間が出ません。

取引パイプラインは、マーケから営業に渡った後の接点を記録する場所でもあります。ステージを決める前に、営業とマーケティングがリードを受け渡す6つの接点のうち、どこまでを取引として記録するかを営業と合意しておきます。

ステージは出口条件を先に書き、買い手側の出来事で区切る

ステージ名から考えず、「何が確認できたら次へ進めるか」という出口条件を先に書きます。出口条件の主語は営業ではなく買い手です。

よくあるのは「初回訪問」「提案書送付」「見積提出」のように営業の作業でステージを区切る形です。作業は営業の裁量で完了できるため、買い手の検討が進んでいなくてもステージは進みます。見積を出しただけで先方は予算化もしていない取引と、すでに稟議に上がった取引が、同じ列に並ぶことになります。

同じ区切りを、買い手側の出来事で書き直すと次のようになります。右端の列は、その出来事が起きたことをCRMに残す手段です。

出口条件が使えるかを確かめる3つの問い

書いた出口条件は、次の3つで確かめます。1つ目は、営業担当が違っても同じ取引を同じステージに置けるか。2つ目は、買い手に確認しなければ満たせない条件になっているか。3つ目は、満たしたことをCRMの項目として残せるか。3つ目を満たさない条件は、あとからレポートで検証できません。「前向きな反応があった」のような条件は、1つ目と3つ目で落ちます。

パイプラインの始点と終点を決める

始点は、取引をいつ作るかです。始点を早く置けば件数は増えて受注率は下がり、遅く置けばその逆になります。どちらでも構いませんが、マーケティングから営業へ引き渡す基準と揃えてください。引き渡し基準がまだ文章になっていなければ、MQLとSQLの定義を営業と先に合意し、合意した時点を取引の始点にします。

終点は受注と失注の2つだけにします。「保留」「検討中断」といったステージは、終点でも途中でもない状態で、置かれた取引は誰にも見られなくなります。保留は時期を理由にした失注として閉じ、検討が再開したら新しい取引を作る設計のほうが、受注率も滞留日数も正しく残ります。契約後の導入支援や保守対応も、取引パイプラインに続けると数字が混ざるため、別の管理方法に分けます。

取引以外のオブジェクトやプロパティもまだ決まっていないなら、CRM全体の設計順を先に確かめ、取引の必須プロパティがコンタクトや会社の項目と重ならないようにします。

ステージ数の目安と、増やしすぎたときに起きること

進行中のステージは4〜6個、受注と失注を加えて6〜8個に収まるのが実務上の目安です。数を決めるのは営業工程の細かさではなく、出口条件の違いの数です。

ステージを増やしすぎると、まず飛ばされるステージが出ます。2つのステージの出口条件が同じ日に満たされることが多いと、営業は片方を飛ばして先へ進めます。飛ばしが常態化したステージは、移行率も確度も計算できません。四半期のパイプラインレビューで営業責任者がステージ別の件数を並べたとき、0件や数件しかないステージが続いていたら、飛ばしが起きている合図です。

ステージが多いと、置き場所も担当者によって割れます。似た条件のステージが並んでいると、慎重な担当は手前に、楽観的な担当は奥に置きます。さらに、ステージ別の件数が小さくなり、移行率が数件の差で大きく動くようになります。必須項目もステージに比例して増え、入力の負担が上がります。

ステージが少なすぎると、初回商談の直後から稟議中までが「商談中」ひとつに入ります。この状態では滞留日数の平均に意味がなく、どこで止まっているかが見えません。

ステージを足す前に確かめること

足したいステージで、取引に対する次のアクションや関わる人が変わるかを確かめます。変わらないなら、ステージではなくプロパティで持ちます。「デモを実施したか」は多くの場合、ステージではなく項目で足ります。また、そのステージを通過するのに数日しかかからないなら、分けても滞留は見えません。分ける価値があるのは、そこで取引が止まりうる区切りだけです。

ステージごとの必須プロパティは出口条件の証拠に絞る

必須プロパティは「そのステージに進んだ根拠」を残す項目だけにし、1ステージ2〜3個（実務上の目安）までに抑えます。入力しないと次へ進めない設計は、項目が少ないときにだけ機能します。

HubSpotでは、パイプラインの設定でステージごとに入力を求めるプロパティを指定でき、必須にしたプロパティは値を入れるまで取引を作成・更新できません。スコアや計算プロパティのように自動で値が入るプロパティは指定できません。この仕組みを使うと、金額やクローズ予定日の欠落がなくなり、見込み額やカバレッジを計算できる状態を保てます。一方で、項目が多いと営業はステージを動かすこと自体を後回しにします。必須化のせいでステージの更新が遅れるなら、逆効果です。

項目を選ぶときの判断は4つです。

• 文章の手入力ではなく、選択・日付・数値で答えられる項目にする
• 選択肢に「未確認」を入れる
• 流入元や作成日のように自動で埋まる項目は必須にしない
• 最初は金額とクローズ予定日だけを必須にし、運用が回ってから足す

すでに選択肢や表記がばらついている項目は、必須にする前に既存データの整備で表記をそろえてください。ばらついたまま必須にすると、営業は近い選択肢を適当に選ぶようになります。

提案ステージに進める前の必須項目には、稟議の流れや時期の根拠など、初回商談で確かめる4つの事実を選択式で持たせると、営業会議で判定の根拠を一覧にできます。

確度（受注確率）は自社の実績から出すまで予測に使わない

ステージの確度は、そのステージに到達した取引が最終的に受注した割合の実績です。初期値や感覚で置いた確度を掛けた見込み額は、精度があるように見えるぶん判断を誤らせます。

HubSpotの取引ステージには確度を持たせることができ、ボード表示ではステージごとの合計金額に確度を掛けた加重金額が表示されます。問題は、その値がどこから来たかです。既定のパイプラインに最初から入っている確度（ステージが進むごとに20%、40%、60%、80%、90%と上がる値）や、「提案なら50%」といった切りのいい数字は、自社の受注実績と関係がありません。経営会議に見込み額を出すと、根拠のない確度で割り引かれた数字が、そのまま予算の議論に使われます。

実績から確度を出す手順

まず、直近の一定期間にクローズした取引を受注と失注の両方で集めます。進行中の取引は入れません。次に、ステージごとにそのステージへ到達した取引の数を数えます。途中のステージを飛ばして奥へ進んだ取引は、手前のステージも通過したとみなすか決めて、扱いを揃えます。到達した取引のうち受注した割合が、そのステージの確度です。計算は四半期ごとにやり直し、出口条件を変えたら、変更前の実績は使わないでください。

確度を置かない判断

クローズ済みの取引が少ないうちは、1件の結果で確度が大きく動きます。あるステージに到達した取引が10件で受注が3件なら30%ですが、次の1件が受注なら36%になります。この段階では確度を掛けた見込み額を報告に使わず、ステージ別の件数と金額をそのまま見るほうが安全です。ツール上で値を入れておく場合も、報告には使わないと社内で決めておきます。

営業担当が案件ごとに持つ「この案件は決まりそうだ」という見立ても、ステージの確度と混ぜないでください。ステージの確度は平均であり、個別の見立ては別の項目で持ちます。加重した見込み額を目標と比べる前に、パイプラインカバレッジとの違いを確かめ、会議でどちらを見るかを1つに決めておきます。

ステージ別の実績受注率は、マーケ施策の予測ROIを出すときにも使います。パイプラインのレポートから受注率を書き出し、マーケティングROIの計算の式にそのまま当てはめます。

パイプラインを複数に分ける条件と、分けすぎの弊害

パイプラインを分けるのは、出口条件か確度が明らかに違う取引が混ざっているときだけです。担当チームや地域の違いはパイプラインではなくプロパティで持ちます。

既存顧客への拡販を新規と同じパイプラインに入れると、受注率が高く期間の短い取引が平均を引き上げ、新規の実態が見えなくなります。既存顧客向けのパイプラインを作るときは、アップセル・クロスセルの前に見る利用状況を取引を作る条件に使えます。パートナー経由の案件は、パートナーが商談を進める期間に自社が確認できる出来事が少ないため、ステージを減らした別のパイプラインにするほうが実態に合います。パートナー経由の取引を始めたばかりなら、パートナー営業の立ち上げ指標で追う数字を決めてから、ステージの数を合わせます。

分けすぎの弊害も具体的です。全社の見込みを見るたびに複数のパイプラインを合算する必要があり、ステージの区切りが揃っていなければ合算できません。確度をパイプラインごとに計算するため件数が分散し、実績が貯まりません。取引をパイプライン間で移すと、ステージの対応がなく履歴が途切れます。パイプラインを追加するにはStarter以上の有料プランが必要で、作成できる数もプランによって異なります。分けた場合でも、受注と失注の定義、失注理由の選択肢の大部分は共通にしておくと、横断で集計できます。

複数商材の会社で、会社の主担当と商材の担当がぶつかり始めたら、商材ごとに取引を分ける運用で担当の持ち方を決めてから、パイプラインを分けるかを判断します。

既存顧客からの質問や不具合の報告まで取引パイプラインに入れると、金額の動かない案件が受注率の分母に混ざります。問い合わせは既存顧客の問い合わせをチケットで管理する設計に沿ってチケットで追い、見積もりを出す段階から取引を作って関連付けます。

失注理由は選択式で持ち、失注したステージとセットで残す

失注理由は選択式を必須にし、自由記述は補足に回します。パイプライン設計の側で決めるのは、選択肢の粒度と、どのステージで落ちたかを後から読める構造です。

自由記述だけにすると集計できず、そのうち書かれなくなります。選択肢は5〜8個程度（実務上の目安）に「その他」を1つ加え、「その他」の割合が増えてきたら選択肢を見直す合図とします。

設計で見落とされやすいのは、失注したステージです。失注に移した時点で、その取引がどこまで進んでいたかは一覧から見えにくくなります。HubSpotはステージの履歴を持っていますが、集計の手間を考えると、失注時のステージを項目として残すか、履歴からレポートで読み出せることを事前に確かめておきます。初回商談の直後に落ちたのか、稟議まで進んで落ちたのかで、打つ手はまったく違います。

失注した取引が再開したときの扱いも、設計の段階で決めておきます。失注を取り消して元のステージに戻すと、失注の記録が消え、受注率と確度の計算が実態より良く出ます。再開したら新しい取引を作り、前の取引と関連づけて残すほうが、数字が歪みません。時期を理由にした失注には再接触の予定日を残しておけば、ナーチャリングに戻す対象として抽出できます。

選択肢を運用し始めたら、四半期に一度は失注分析で表向きの理由と構造的な要因を分け、判断がつかない失注は顧客へのヒアリングで確かめます。

既存のパイプラインを作り直すときの移行の注意

作り直しで失われやすいのは、過去の取引データとレポートの連続性です。新しいステージを作る前に、参照箇所の棚卸しと旧ステージとの対応表、切り替え日を決めます。

過去の取引をどう扱うか

クローズ済みの取引は動かさないのが基本です。受注と失注は新旧どちらの定義でも終点なので、無理に置き直す必要がありません。進行中の取引は、新しい出口条件に照らして置き直します。対応表で機械的に一括移動すると、旧定義の曖昧さがそのまま新しいステージに持ち込まれます。件数が多くなければ、担当営業と一件ずつ確認してください。確認の過程で、実質的に止まっている取引を失注として閉じる判断もここで済ませます。

ステージを削除・統合する前に

ステージは、ワークフローの起動条件、レポートの絞り込み、リストの条件、ダッシュボードなど、思っている以上に多くの場所から参照されています。HubSpotでは、取引が残っているステージや、条件付きのステージプロパティで使われているステージは、その参照を外すまで削除できず、参照箇所はパイプラインの設定画面で確認できます。ステージを条件にしたワークフローがあるなら、削除や統合の前にワークフローの起動条件を1つずつ書き換えておきます。

レポートの連続性を保つ

切り替えは期の途中を避け、期初に行います。切り替え日を記録し、ダッシュボードにも注記を残します。ステージ間の移行率、滞留日数、確度は、旧定義と新定義で比較できません。切り替え前の数字と並べるときは、定義が違うことを明記してください。確度は新しい定義で実績が貯まるまで加重に使いません。一方、受注件数と受注金額はステージ定義に依存しないため、前年同期との比較にそのまま使えます。

運用が崩れる典型と、設計側でできる手当て

ステージが更新されない、全部「商談中」に溜まるといった崩れ方には、入力の習慣より先に設計側の原因があります。運用ルールで補う前に、定義と項目で手当てできる部分を潰します。

通知や一覧化はワークフローで自動にできますが、通知が多すぎると無視されます。取引ごとに都度送るより、担当者ごとに週1回まとめて届けるほうが読まれます。滞留の基準日数は、確度と同じく実績から出し、最初は長めに置いて通知の件数を抑えます。

「全部商談中」の状態は、多くの場合、ステージの数を増やせば解決すると考えられがちです。実際には、既存のステージの出口条件が曖昧なまま数を増やすと、曖昧なステージが増えるだけです。先に今あるステージの出口条件を書き、書けないステージを統合してから、足りない区切りを足します。

設計を直しても入力が続かない場合は、Sales Hubでの日々の入力の流れと、マネージャーが週に一度パイプラインを見る習慣を合わせて見直します。自社のパイプラインがどの症状に当てはまり、どこから直すべきかを整理したい場合は、現在のステージ定義を前提にした相談をご利用ください。

ステージの定義を直しても更新が会議の前日に集中するなら、入力が会議の準備作業になっています。見積や社内依頼を取引から始める入力を次の行動の前提にする運用を足すと、商談の直後に更新が入るようになります。

パイプラインを作り込まない判断｜向かない場合

月の新規商談が数件の段階や、売り方がまだ固まっていない段階では、ステージを細かく設計しても実績が貯まらず、判断に使える数字は出ません。

月の新規商談が数件なら、ステージは「商談中」「提案中」「受注」「失注」程度で足ります。確度は使わず、必須項目は金額とクローズ予定日だけにします。この規模では、パイプラインの目的は見込みの精度ではなく、取引の抜け漏れを防ぐことです。

売り方がまだ固まっていない段階では、出口条件そのものが書けません。無理に定義を作るより、簡素なステージで3か月ほど取引を記録し、実際にどこで止まり、どこで落ちたかを見てから出口条件を書くほうが、作り直しの回数が減ります。

作り直し自体をしない判断もあります。崩れの原因が定義ではなく、パイプラインを見る場がない、入力しても誰も使わないといった運用側にあるなら、ステージを作り直しても半年で同じ状態に戻ります。症状の表で設計上の原因に当てはまらない崩れ方をしているなら、先に運用を見直してください。

まとめ

取引パイプラインの設計は、ステージ名を並べる作業ではなく、買い手側で起きた出来事で出口条件を書き、そこから必須項目と確度を導く作業です。

最初にやるのは、今あるステージごとに、買い手側で確認できる出口条件を1〜2文で書いてみることです。書けないステージは統合の候補、次のアクションや関わる人が変わらない区切りはプロパティに移す候補になります。確度は自社の到達実績が貯まるまで報告に使わず、作り直すなら参照箇所の棚卸しと旧ステージとの対応表を作ってから、期初に切り替えてください。

よくある質問

HubSpotの取引ステージはいくつに分けるのがよいですか

進行中のステージは4〜6個、受注と失注を加えて6〜8個に収まるのが扱いやすい目安です。ただし数から決めるのではなく、買い手側で確認できる出口条件がいくつ違うかで決めます。次のアクションや関わる人が変わらない区切りはステージにせず、プロパティで持つほうが、飛ばしや置き場所のばらつきを防げます。

取引ステージの確度は何％に設定すればよいですか

決まった数字はありません。各ステージに到達した取引のうち、最終的に受注した割合を自社の実績から計算したものが確度です。クローズ済みの取引が少ないうちは1件で確度が大きく動くため、確度を掛けた見込み額は報告に使わず、ステージ別の件数と金額をそのまま見てください。実績が貯まったら四半期ごとに再計算します。

HubSpotでパイプラインを複数作るべきなのはどんな場合ですか

出口条件か確度が明らかに違う取引が混ざっているときです。新規顧客と既存顧客への拡販、契約更新、決裁者やサイクルが違う商材、自社が関与しない期間が長いパートナー経由の案件が代表例です。営業チームや地域、流入元の違いはプロパティで絞り込めば足りるため、分ける理由になりません。パイプラインの追加にはStarter以上の有料プランが必要で、作成できる数もプランによって異なります。

ステージごとに入力必須のプロパティは設定できますか

できます。パイプラインの設定でステージごとに入力を求めるプロパティを指定して必須にでき、必須にしたプロパティは値を入れるまで取引を作成・更新できません。必須にするのは出口条件の証拠になる項目を1ステージ2〜3個までにとどめ、選択肢に「未確認」を入れておくと、先へ進めるためだけのダミー入力を防げます。

パイプラインを作り直すと過去の取引データはどうなりますか

クローズ済みの取引は動かさず、進行中の取引だけを新しい出口条件で置き直すのが基本です。ステージを削除・統合すると、そのステージを参照するワークフローやレポートが意図どおりに動かなくなることがあるため、先に参照箇所を洗い出します。切り替えは期初に行い、移行率や滞留日数、確度は新旧で比較できないことを明記してください。受注件数と受注金額はステージ定義に依存しないため連続して使えます。