HubSpotでセールスサイクルを短縮する方法｜商談停滞を解消する実践設計

短縮の起点は営業担当者を急かすことではありません。HubSpotで停滞を可視化し、次の行動が進む仕組みを設計します。

「商談が途中で止まり、次に誰が動くのかわからない」
「提案書や見積もりの準備に時間がかかり、案件が前へ進まない」
「担当者の経験に依存し、受注予定日の見通しが揃わない」
こうした状態では、案件の確認や催促が増え、営業担当者とマネージャーの負担が重くなります。

セールスサイクルとは、見込み顧客との初回接触から受注または失注までにかかる期間です。HubSpotで短縮を図るには、取引ステージごとの滞留を調べ、自社で変えられる待ち時間を特定したうえで、入力、通知、フォロー、承認をつなげます。

この分野の体系的な情報はHubSpot営業・CS活用ガイドでまとめています。

本記事は「PLG × PLSハイブリッド戦略｜プロダクトレッドと営業レッドを両立する設計」シリーズの一部です。
本記事はHubSpotゴールドパートナーのStartLinkの「HubSpot完全ガイド」関連記事です。

この記事でわかること

商談の停滞原因を特定し、HubSpotで改善を仕組みにしたい方に向けて、計測項目の選び方から、ステージの設計、担当者の行動、会議での見直し方までを順番に解説します。

• セールスサイクル短縮の考え方 — 顧客の検討に必要な時間と、自社で見直せる待ち時間を分けます。
• ボトルネックの見つけ方 — ステージの滞留だけで結論を出さず、次回行動、顧客回答、社内承認の状態を照合します。
• パイプラインの設計方法 — ステージの出口条件と必要情報をそろえ、次の担当が判断できる状態を作ります。
• 停滞案件への介入方法 — 通知後に担当者が選ぶ行動と、完了時に残す記録まで決めます。
• 改善を続けるKPI — 期間と受注への転換を並べて見て、短縮施策を続ける条件を判断します。

「商談が長期化しているものの、どこから直すべきかわからない」とお感じの方は、まず自社で動かせる工程を一つ選ぶところから始めてください。

セールスサイクル短縮は営業を急かすことではない

営業担当者への催促を増やす前に、案件が待っている理由を分けます。顧客の判断を待つ案件と、次の担当や作業が決まっていない案件では、取るべき行動が異なるためです。

短縮する対象を三つに分ける

初回連絡の遅れ、提案準備の手戻り、承認待ち、フォロー漏れは、営業プロセス側で見直せます。一方で、顧客の稟議や比較検討そのものは、営業側の都合だけでは短くできません。

案件ごとに、現在待っている相手と、次に確認する日を記録します。自社の作業が止まっているなら担当と完了条件を決め、顧客の判断待ちなら不足資料や未回答の論点を確認します。待つ理由を説明できない案件から、対応を見直します。

コンタクトから受注後までを一つの流れで見る

HubSpotでコンタクト、会社、取引、活動の記録を関連付ける際は、前工程の情報を次工程で使えるかを確認します。セールスサイクルの計測対象は受注または失注までですが、受注後への引き渡しに不足がないかも、商談中の入力項目を決める材料になります。

例えば、フォームで取得した課題を初回商談で参照できなければ、同じ確認を繰り返します。受注時の条件を顧客対応へ渡せなければ、引き継ぎ時に確認が必要です。一元管理は保存場所をまとめることではなく、次工程が前工程の情報を使える状態を作ることです。まず重複確認が起きている工程を探し、必要な情報だけを引き継ぐ設計にします。

セールスサイクルのボトルネックをデータで特定する

改善は、どの取引ステージで案件が止まっているかを把握するところから始まります。ただし、長く滞留した案件がすべて放置されているわけではありません。滞留時間を見た後に、活動記録と次回行動を確認して理由を分けます。

スプレッドシート管理で見えにくくなること

スプレッドシートに案件一覧、メールに顧客とのやり取り、個人メモに次回行動が分かれていると、最新状態をそろえる作業が増えます。ステージ名が同じでも、担当者ごとに「提案済み」の意味が違えば、滞留時間を比較しても改善点を特定できません。

HubSpotの取引レコードを確認する際は、関連する会社、コンタクト、活動記録と、ステージ変更後の次回行動を合わせて見ます。入力項目は分析や引き継ぎに使うものへ絞ります。まず同じステージの案件を担当者間で見比べ、進行状態を同じ言葉で説明できるか確かめてください。

まず計測する項目をそろえる

計測を始める前に、起点をそろえます。初回接触から受注までを測るセールスサイクルと、取引作成から受注までを測る期間は、取引を初回接触後に作成する運用では一致しません。前者を追う場合は初回接触日、後者を追う場合は取引作成日を起点として区別します。

HubSpotの既定の取引プロパティには、現在のステージで過ごした時間、ステージへの直近の滞在時間、再入を含む累積時間が別の項目として説明されています。直近と累積の値を比較する際は、案件が現在そのステージにいるか、過去に再入したかを確認し、進行中の滞在時間とは分けて読み取ります。

表の右列は、原因を確定する基準ではなく、次に確認する順序です。例えば、累積時間が長い案件ではステージへの再入履歴を確認し、顧客の条件変更による再検討と、社内の情報不足による手戻りを分けます。

また、「最終アクティビティー日」を見る際は、活動記録で顧客とのやり取りの内容を確認し、次回行動が決まっているかも確かめてください。接点が見当たらず、次回行動も決まっていない場合にフォロー方法を決めます。

停滞理由を分類して打ち手を選ぶ

滞留が長いという結果だけでは、打ち手を決められません。取引レコードで停滞理由を選べるようにし、理由ごとに対応を変えます。

理由が選べない案件は、担当者が顧客とのやり取りを確認してから分類します。分類後は、選んだ対応に必要な情報がそろっているかを見ます。例えば顧客回答待ちでも、回答予定や未回答の論点が不明なら、待機を続ける前に確認事項を整理します。

進み方が揃うパイプラインを設計する

パイプラインでは、取引がどの状態にあるかをチームで共有します。ステージ名を決めるだけでなく、そのステージに入る条件、次へ進む条件、次の担当が使う情報をそろえます。

以下の画面は、取引を初回訪問、意思決定者の確認、見込み、見積提示、受注内示の列に分け、案件カードとステージごとの金額を確認できるボード表示です。

ステージは営業行動ではなく顧客の到達状態で区切る

「連絡した」「提案書を作った」のような営業側の作業だけでステージを分けると、顧客がどこまで判断したかが見えません。「課題と導入時期を確認できた」「提案内容を関係者へ共有できた」のように、案件の状態が変わる地点をステージの出口にします。

設計したら、実際の進行中案件を当てはめます。同じ案件について担当者とマネージャーの判断が分かれるなら、ステージの出口条件か必要情報を見直します。判断がそろってから、滞留時間の比較に進みます。

受注確度と次回行動を分けて管理する

受注確度が高くても、次回行動が決まっていなければ案件は止まります。反対に、活動量が多くても、意思決定者や導入時期が不明なら見通しは立ちません。

ステージと受注確度に加えて、次回行動、予定日、意思決定者、導入時期を確認します。会議では、見込みを議論する前に「次に誰が何をするか」を確かめます。それが決まらない案件は、顧客の判断待ちなのか、自社の確認不足なのかを分けてから見通しを更新します。

必須項目は次工程に必要なものへ絞る

オブジェクトパイプラインの設定と管理を参照し、利用中の設定でステージ移動時に求める項目を確認します。

必須項目は多いほど良いわけではありません。次工程が使わない情報まで求めると、入力が後回しになる可能性があります。項目ごとに「誰が、どの判断に使うか」を示し、引き継ぎ、判断、レポートのいずれにも使わないものは必須にする前に見直します。

各ステージの待ち時間を減らす施策

ボトルネックとパイプラインの基準が整ったら、滞留の理由に合う施策を選びます。変更後は、待ち時間だけでなく、次工程へ渡す情報と受注への転換も確認します。

初動とニーズ確認をつなげる

フォーム送信後の対応では、担当者の割り当て、通知、初回連絡のタスクを一つの流れとして設計します。通知を受け取るだけでは動けないため、連絡手段と担当者が次に確認することまで決めます。

初回接触では、BANTと呼ばれる予算、意思決定権、課題、導入時期の観点を確認します。すべてが明確でない場合は、不明な点を次回確認で解消できるかを判断します。

• 確認の相手と予定が決まれば ── 商談を進めます
• 検討の条件が整っていなければ ── ナーチャリングへ戻すことを検討します

提案作成と社内承認の手戻りを減らす

提案書は、再利用できる構成と、案件ごとに編集する部分を分けます。CRMのプレイブックにはヒアリング項目や提案前の確認事項をまとめ、提案に必要な情報がそろっているかを確認できるようにします。不足があれば作成前に確認し、そろっていればレビューへ進めます。

見積もりや条件変更の承認では、申請者、承認者、必要情報、差し戻し後の戻し先を決めます。申請前に条件を確認し、不足があれば営業担当者へ戻します。差し戻しが続く場合は、個々の担当者への催促ではなく、申請条件の説明や入力項目を見直します。

フォローと意思決定者への接点を設計する

商談終了時に、次回行動、担当者、予定日を取引へ記録します。日程が決まらない場合も、「顧客回答待ち」「社内確認待ち」のように待っている理由を残します。予定日になったら、回答の有無だけでなく、未解決の論点を確認して次の行動を決めます。

シーケンスを使う場合は、提案内容の要約、参考資料、日程調整のように各連絡の目的を分けます。ただし、個別条件の調整や重要な交渉まで定型文だけで進めると、相手の論点とずれることがあります。送信前に取引レコードを確認し、案件固有の情報を反映する運用にします。

担当者だけで商談が止まる場合は、意思決定者と意思決定の手順を確認します。誰が何を判断し、どの資料が必要かが分かれば資料を準備します。判断の手順が不明なら、次の商談で確認する事項に加えます。

ステージ別に完了条件を置く

ステージ名は自社の営業プロセスに合わせて置き換えます。大切なのは名称ではなく、各段階の完了条件と次の担当が明確になっていることです。出口条件を満たさない案件は、ステージを進める前に不足情報と取得方法を決めます。

HubSpotで停滞案件の検知と介入を仕組み化する

担当者の記憶だけに頼らず、決めた停滞条件に該当する案件を確認できるようにします。自動化を設定する前に、条件に該当した案件を人が見て、同じ行動を選べるか確かめます。

ワークフローの条件を順番に組む

取引ベースのワークフローを検討する際は、次の順に組みます。

1. 対象のステージを決める
2. 確認する条件を決める ── 現在のステージで過ごした時間と次回行動の有無を確認し、顧客回答待ちなど、意図して待機している案件をどう扱うか決めます
3. 設定する ── 担当者への通知やタスク作成を設定します

登録条件を広げすぎると、行動につながらない通知が増えます。通知を受けた担当者が継続フォロー、ナーチャリングへの移行、失注処理のいずれかを判断できるか確認します。判断できない通知が続くなら、対象条件か通知に含める情報を見直します。

通知ではなく判断まで設計する

通知後に更新する項目まで決めます。担当者が対応したのに同じ通知が繰り返される場合は、完了の記録と登録条件の関係を確認します。通知が出ない案件があれば、ステージや次回行動の入力状態を先に確認します。

自動化とパイプラインルールの限界を理解する

オブジェクトパイプラインのルール設定を参照し、利用中のパイプラインルールとワークフローの更新条件をそれぞれ確認します。

画面上の操作制限だけを前提にせず、ステージを自動更新する処理も点検します。必要情報がそろっている案件だけを次へ進め、不足している案件は担当者が確認できるようにします。設定後は実際の運用条件に沿う案件で、想定した担当者に作業が渡るか確かめてから対象を広げます。

KPIで短縮と受注品質を同時に見る

期間だけを短くすると、見込みの低い案件を早く閉じただけでも改善したように見える場合があります。期間、進行、受注、失注を組み合わせ、施策を続けるか判断します。

管理するKPIを役割で分ける

比較する案件の起点と終点をそろえます。初回接触からの期間と取引作成からの期間を混ぜず、受注案件と進行中案件も分けます。案件規模、商材、流入経路など、自社で意味のある区分ごとに、滞留の変化と受注への転換を確認します。

受注案件と失注案件を分けて比較する

受注案件の滞留時間は、前進した商談の進み方を調べる材料になります。失注案件では、どの工程で見極めが遅れたか、判断材料が不足していなかったかを確認します。長期化した理由が異なる案件を一括りにしないことが大切です。

営業会議では、停滞基準を超えた案件、次回行動がない案件、受注予定日を過ぎた案件を取り上げます。各案件について、待っている理由、次に判断する人、必要な情報を確認します。会議後に次回行動が記録されていなければ、報告の形式を見直します。

失注から掘り起こしへ戻す

失注はセールスサイクルの終点ですが、関係の終点とは限りません。価格、時期、製品機能、社内決裁などの失注理由を記録し、再接触の条件がある案件を分けます。

例えば、導入時期が合わなかった案件では、再検討の予定と、その際に必要な情報を確認します。対象外と判断した案件は、同じ施策へ自動的に入れず、対象外とした理由を残します。再接触の条件が明確になった案件から、次の対応を決めます。

小さく始めて運用に合わせて拡張する

最初からすべてのステージ、プロパティ、ワークフローを作り込むと、設定を現場の判断に使えているか確認しにくくなります。滞留の理由が明確な工程を一つ選び、入力、可視化、自動化の順で確かめます。

導入を三段階に分ける

入力基準が揃わなければ、一覧を作る前にステージの判断を見直します。会議で一覧を見ても次の行動を決められなければ、表示項目や停滞理由を見直します。担当者が同じ判断を繰り返せる状態になってから、自動化する工程を選びます。

短縮施策が向かない状態を見極める

顧客側の判断待ちが中心なら、期間の短縮よりも、必要資料と次の確認予定を明確にすることを優先します。

設定を増やす前に運用を見直す

停滞を見つけるたびにプロパティやワークフローを増やすと、入力先や通知経路が分散します。新しい設定を作る前に、既存のステージ定義、必須項目、通知条件で表現できないかを確認します。

追加する項目には、利用目的、入力する人、確認する場を決めます。運用後は、その情報が分析、判断、引き継ぎのどこで使われたかを確認します。使い道を説明できない場合は、項目を増やす判断に戻ります。

よくある質問

目標値や停滞基準を決めるときは、他社の目安を当てはめる前に、自社の案件を同じ条件で比較します。ここでは、期間と案件品質の両方を見ながら判断する方法を整理します。

セールスサイクルの目標はどう設定しますか？

まず受注案件を商材や案件規模で分け、初回接触から受注までの期間とステージ別滞留時間を把握します。次に、顧客の判断時間と、自社の社内処理や連絡の空白を分けます。改善する工程を選んだら、その工程の進み方と受注への転換を並べて確認し、案件品質を保てている場合に対象を広げます。

案件を早く進めると受注率が下がりませんか？

顧客の判断を急がせれば、提案に必要な確認が不足する場合があります。初動、社内承認、フォローなど、自社で見直せる待ち時間を対象にしてください。期間が短くなっても受注への転換が下がったり、失注理由に確認不足が増えたりする場合は、進め方を見直します。

停滞案件の基準はどのように決めますか？

同じステージを通過した受注案件を、商材や案件規模などの条件をそろえて見比べます。滞留が目立つ案件について、次回行動、顧客回答の予定、社内作業の状況を確認します。担当者が次の行動を選べる案件を通知対象とし、通知後の処理が進まなければ条件と表示情報を見直します。

大型案件でもセールスサイクルを短縮できますか？

意思決定者が多く、契約確認や顧客内の調整が長い案件では、顧客側の判断時間を大きく変えにくいことがあります。一方で、提案準備、社内承認、連絡の空白、必要資料の不足は見直せます。まず案件の意思決定手順を確認し、自社で動かせる工程が見つかった場合に施策を選びます。案件固有の判断は担当者とマネージャーが行います。

まとめ

HubSpotでセールスサイクルを短縮するには、ステージごとの完了条件、必要情報、次の担当をそろえ、停滞の理由に応じた行動を決めます。期間だけを成果とせず、受注への転換と失注理由も合わせて確認します。

記事の要点

• 初回接触からの期間と取引作成からの期間を区別して計測します。
• 社内処理、連絡の空白、顧客判断の時間を分けます。
• 滞留時間を見た後に、活動内容と次回行動を確かめます。
• ステージの出口条件と、次工程に必要な情報をそろえます。
• 通知後の判断と記録が定着してから、自動化の対象を広げます。

まずはステージ別滞留の確認から始める

まずは次の順番で、現在の運用を確認してください。

1. 受注案件と進行中案件を分け、同じ条件の案件で滞留が目立つステージを一つ選びます。
2. そのステージの入口条件、出口条件、必須情報、次の担当を言語化します。
3. 次回行動がない案件を確認し、待っている理由に応じて担当者の行動を決めます。
4. 会議で判断に使えることを確かめてから、通知やタスク作成を試します。

企業様によって最適な形は異なります。まず一つのステージで基準と行動をそろえ、案件の進行と受注への転換を確認しながら、対象を広げてください。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• サブスクリプション解約防止の施策設計
• 中小企業向けSFAおすすめ比較
• ヘルススコア設計ガイド