HubSpot / Sales Pipeline

パイプライン滞留SLA設計

リードと取引の各ステージについて、何を測り、何日で誰が動き、どうやってアラートを解除するかを定めたもの。日数はすべて初期値で、運用実績で置き換える前提。

作成 2026-09-07 対象 リードパイプライン / 取引パイプライン 状態 設計合意済み・未実装

全体マップ

9ステージ・3段のSLA一覧

詳細な理由づけは 04・05 の各ステージを参照。ここでは日数だけを並べる。

ステージ1段目2段目3段目・処置
取引・商談化 A 提案準備中 5営業日10日 網:45日超で強制レビュー
60日超+30日無接触→自動見送り
B 提案・見積提示済み 5日14日
C 条件調整中 7日21日
取引・担当者合意 7日+決裁予定日空/14日無接触30日 60日超+30日無接触→自動見送り
取引・内諾 7日無接触/5日契約書未返送21日 45日超→人へエスカレーション(自動クローズなし)
リード・案件発生 1営業日未接触2営業日未接触 5営業日→自動でナーチャリングへ
リード・接触済み/ヒアリング済み 7日無接触14日 30日+14日無接触→自動でナーチャリングへ
リード・ナーチャリング 再評価3回(約9ヶ月)→自動で失注

01

基本方針

「失注ではないがステイ」の扱いから決めた、設計全体の前提。

02

3つの時計

測る対象を分けるのが設計の核心。混ぜると全部ノイズになる。

進捗

ステージ滞留日数

ステージに入ってからの経過。ステージが変わるとリセット。HubSpotが自動計算(hs_date_entered_*)。

接触

最終接触日からの経過

顧客とのメール・通話・ミーティングでのみ更新される notes_last_contacted を使う。社内メモでも動く notes_last_activity_date は使わない。

意図

次回アクション日

意図的に待っていることの表明。未来日付が入っていればアラートを抑止する。営業に求める唯一の必須入力。

放置案件の定義

ステージ滞留がSLA超過 かつ 次回アクション日が空または過去日

次回アクション日が未来にあれば「追っている」、なければ「放置」。営業の申告に頼らず機械的に判定できる。

商談化のように区間が長いステージでは、ステージ滞留の代わりにマイルストーン変更日からの経過を使う。ビューのフィルタに「マイルストーン変更日が10日以上前」と書けば足りる。

03

エスカレーションの3段

全ステージ共通の骨組み。段によって意味・通知先・頻度・解除方法がすべて違う。

1段目

動け ── 行動が止まっている

原因は失念や多忙。連絡すれば最終接触日が更新され、アラートは自動で消える。マネージャーは登場しない。

通知先: 営業本人 / 手段: HubSpotタスク自動生成 / 頻度: 日次 / 抑止: 次回アクション日

2段目

決めろ ── 判断が止まっている

連絡しても解決しない停滞。「進める」「待つ(見送り)」「諦める(失注)」の3択のどれかを決める会議の招集状。

通知先: マネージャー / 手段: レビュー用ビュー / 頻度: 週次 / 抑止: 最終レビュー日のみ

3段目

機械が処理する ── または人を投入する

1・2段目をすり抜けた案件。ステージごとに自動クローズ/自動ナーチャリング/人の直接介入を使い分ける。会議の時間は使わない。

通知先: なし(ワークフロー) / 例外: 内諾のみ人が介入

抑止の効かせ方は段によって違う。次回アクション日の抑止は1段目にだけ効かせ、2段目には効かせない。2段目の目的は「10月まで待つ」という営業の判断そのものを検証することなので、その申告で消えると意味がなくなる。2段目は最終レビュー日(マネージャーが見た事実)でのみ消える。すべてのアラートに解除経路があること。消えないアラートは必ず無視される。

04

取引パイプライン

商談化 → 担当者合意 → 内諾 → 受注/失注(+見送り)。

商談化

ステージ全体の上限 45日 / 3マイルストーンに分割

止まる原因

提案が出ない / 反応がない / 条件が詰まらない

測るもの

マイルストーン別の日数

A 提案準備中 起点: 初回商談日
1段目5営業日、提案未提示本人タスク「提案書提示、または提示予定日を先方に連絡」
2段目10日問い提案を出せない理由は何か ── 遅れの実態は多忙より初回ヒアリング不足。答えが出なければ再ヒアリングか、案件として弱いので見送りへ。
B 提案・見積提示済み 起点: 提案提示日
1段目5日反応なし本人タスク「先方の反応確認」
2段目14日問い誰が評価しているのか、競合は何社か ── 提案後の沈黙は「検討中」でなく「社内で議題に上がっていない」サイン。決裁者への直接アプローチを設計する。
C 条件調整中 起点: マイルストーン変更日
1段目7日無接触本人タスク
2段目21日問い合意を妨げている条件は何か、決裁ラインはどこか ── 値引き承認や仕様調整は営業単独で決められない。「上に相談できていない」ことが多く、マネージャー介入の価値が最も高い局面。
2段目・網滞留45日マイルストーンに関係なく強制レビュー対象。マイルストーンが更新されていない案件をここで拾う。
3段目滞留60日超 かつ 30日無接触自動で見送りクローズ(保留理由「一定期間非活動」)+リードをナーチャリングへ。

見積と提案はほぼ同時に出るため、Bは「提案・見積提示済み」の1マイルストーンにまとめる(4分割にしない)。

担当者合意

設計上もっとも間違えやすいステージ

止まる原因

決裁者に届いていない

測るもの

情報の欠落(日数ではない)

営業は担当者と頻繁に連絡を取り合うため無接触アラートが立たない。日数では検知できないので、決裁情報が埋まっているかどうかを見る。

1段目aステージ入りから7日、決裁予定日が空本人タスク「決裁プロセスと予定日を確認」。最も価値のある検知 ── 答えられない案件は担当者と仲良くしているだけで前に進んでいない。
1段目b14日無接触本人タスク
2段目滞留30日、または決裁予定日超過で進捗なし問い決裁者に会えているか。会えていないなら障害は何か
3段目滞留60日超 かつ 30日無接触自動で見送りクローズ。

診断指標

担当者合意 → 内諾 の所要日数。伸びているなら、担当者の「いいですね」を合意と誤認しているサイン。

内諾

3段目で自動クローズしない唯一のステージ

止まる原因

事務手続き(営業の問題ではないことが多い)

測るもの

短いサイクル+エスカレーション

1段目a7日無接触本人タスク
1段目b契約書送付から5日返送なし本人タスク
2段目滞留21日問い事務手続きのどこで止まっているか、先方の事務担当は誰か
3段目滞留45日自動クローズしない。マネージャーへ直接エスカレーション ── 最も確度が高いのに最も油断されるステージで、機械的に閉じると損失が大きすぎる唯一の3段目。

診断指標

内諾 → 受注 の転換率。90% を下回るなら内諾の定義が甘い。

受注 / 失注 / 見送り

個別案件は追わず、分布を見る

受注

商談化 → 受注のリードタイム中位値と、ステージ別転換率を半年ごとに出す。全SLAの見直し材料。

失注

失注理由 × 失注ステージのクロス集計。商談化で負ける=提案力とスピード、担当者合意=決裁者アプローチ、内諾=条件と事務対応。

見送り

見送り → 再開 → 受注の復活率。保留在庫が資産か死蔵かを半年で判断できる。

05

リードパイプライン

案件発生 → 接触済み・ヒアリング済み → ナーチャリング → 商談化/失注。

案件発生

唯一、日ではなく時間単位で測る

止まる原因

担当割当の失敗(不在・繁忙・退職)

測るもの

速度

1段目1営業日で未接触本人にSlack即時通知(タスクでなく通知。タスクは翌日以降に見られる恐れがあるため)
2段目2営業日で未接触問い割当が正しいか ── マネージャーにも即時通知、週次には回さない。原因はほぼ担当者不在、答えは再割当。
3段目5営業日で未接触自動でナーチャリングへ。失注にはしない ── 未接触リードを失注にすると流入元の評価が狂う(体制の問題をチャネルの問題と混同しない)。

組織KPI

リードレスポンスタイム(作成 → 初回接触)の中位値と分布。個別アラートより、この分布を見る。

接触済み、ヒアリング済み

日数の前に、商談化の定義を決める必要がある

止まる原因

見極めが未完了

測るもの

商談化条件の充足度

商談化の条件は3つ。① 課題が特定できているか ② 導入時期が確認できているか(未定でもよい、確認したかどうか) ③ 予算の存在が確認できているか。3つ埋まれば商談化、時期が未定なだけならナーチャリング、課題が特定できないなら失注、と自動で振り分ける。

1段目7日無接触本人タスク
2段目滞留14日問い商談化条件のどれが未確認か ── 答えられなければヒアリング未完了。次に何を聞くかを決める。
3段目滞留30日 かつ 14日無接触自動でナーチャリングへ。見極め未完了は失注ではない。

ナーチャリング

このステージだけ滞留日数を測らない

状態

意図的な待ち(正常)

測るもの

温度と再評価日

意図的に待っている状態なので、日数で追うと全件が異常になる。溜まること自体は問題ではなく、溜まったものが浮き上がってこないことが問題。

自動補完次回アクション日が空自動で90日後をセット(人を呼ばない)。溜めていいのは「いつ見るか決まっているもの」だけ。
温度 ★サイト再訪/料金ページ閲覧/資料DL本人に即通知「A社が料金ページを閲覧」。このステージの主役 ── これがなければナーチャリングは単なる倉庫。
再評価再評価日(次回アクション日)が到来本人タスク。月次でまとめて処理する。
打ち切り再評価3回(約9ヶ月)通過して動かないリード失注へ自動移行。上限がないとナーチャリングが「何も意味しない箱」になる。

月次指標

ナーチャリング復活率 = ナーチャリング → 商談化の件数 ÷ 在庫件数。

商談化 / 失注

通過点と終端

商談化

通過点。滞留3日以上はシステム異常(取引が作られていない)として管理者に通知、営業には出さない。リード側は「コンバート済みの終端」とし、以降の進捗は取引だけで見る(二重計上を防ぐ)。

失注

個別には追わず、月次で失注理由の構成比を見る。「未接触のまま失注」が出ていたら流入品質ではなく体制の問題。

06

3段目の処理方針

自動処理するのは3ステージだけ。残りは対象外か、人が入る。

ステージ 3段目の処理 種別 理由
案件発生 ナーチャリングへ移動 自動 失注にすると流入元の評価が狂う
接触済み・ヒアリング済み ナーチャリングへ移動 自動 見極め未完了は失注ではない
ナーチャリング 再評価3回で失注へ 対象外 待つのが正常。日数では追わない
取引・商談化 見送りクローズ 自動 リードをナーチャリングへ戻す
取引・担当者合意 見送りクローズ 自動 リードをナーチャリングへ戻す
取引・内諾 マネージャーへエスカレーション 人が介入 機械的に閉じると損失が大きすぎる
サボり得を塞ぐ。「放置すれば自動でクローズされて記録も消える」では営業のサボり得になる。非活動による自動クローズ件数を営業ごとに月次集計してレポート化し、処理は自動で、責任は記録に残す。
なお65日放置まで到達しているのは1・2段目を両方すり抜けたということで、個人の失念でなく仕組みの不作動。怒鳴る正しいタイミングは10日目にタスクが消化されなかったときで、マネージャーの仕事は放置を叱ることではなく放置を0件にすること。

07

必要プロパティ

この設計を成立させるために追加が必要なもの。営業の手入力は「次回アクション日」だけ。

取引オブジェクト
プロパティ 種別 入力方法 用途
商談内マイルストーン 選択 手入力 提案準備中 / 提案・見積提示済み / 条件調整中
初回商談日 日付 自動 ミーティング完了時、空なら今日をセット。マイルストーンAの起点
提案提示日 日付 自動 マイルストーンB入り時にセット。Bの起点
マイルストーン変更日 日付 自動 マイルストーン滞留日数の起点
次回アクション日 日付 手入力 営業に求める唯一の必須入力。1段目アラートの抑止
最終レビュー日 日付 手入力 2段目アラートの抑止。マネージャーが入力
決裁者 関連付け 手入力 担当者合意ステージの必須情報
決裁プロセス 選択 手入力 稟議 / 役員会 / 担当者の決裁権限内
決裁予定日 日付 手入力 空のまま7日で1段目アラート(最重要の検知)
発注予定日 日付 手入力 内諾ステージ
契約書送付日 日付 手入力 送付から5日で1段目アラート
保留理由 選択 自動+手入力 予算凍結 / 時期未定 / 決裁待ち / 担当者異動 / 一定期間非活動
再開想定四半期 選択 手入力 見送りクローズ時に記録。再開タスクの起点
再開元取引ID 文字列 自動 復活時に新規作成した取引から元案件を辿る
リードオブジェクト
プロパティ 種別 入力方法 用途
初回接触日時 日時 自動 案件発生の速度計測。リードレスポンスタイムの終点
課題特定済み チェック 手入力 商談化条件 ①
導入時期確認済み チェック 手入力 商談化条件 ②(未定でもよい、確認したかどうか)
予算確認済み チェック 手入力 商談化条件 ③
次回アクション日 日付 自動+手入力 ナーチャリングの再評価日。空なら90日後を自動セット
再評価回数 数値 自動 3回で失注へ自動移行

08

運用と権限

09

未決定・要検証

実装前に埋めるべき穴。

  1. 01

    SLA日数はすべて初期値

    BtoB法人営業・商談サイクル1〜3ヶ月を想定したたたき台。3〜6ヶ月運用したら、受注した案件だけのステージ滞留日数の中位値を出し、その1.5倍に置き換える。失注案件を含めると数字が伸びて意味がなくなる。

  2. 02

    検知結果の届け方が未定

    HubSpotのビューで見るか、Slack通知か、AIが該当案件を絞って要約するか。条件式が確定すれば後から差し替えられるので、いま決めなくてよい。

  3. 03

    初回商談 → 提案提示の実績日数が未確認

    マイルストーンAの「5営業日」の妥当性。実態が7〜10日なら調整が必要。

  4. 04

    最終接触日プロパティの挙動確認

    取引オブジェクト側の notes_last_contacted 相当プロパティは、名称と更新条件がコンタクト側と微妙に違うことがある。実データで挙動を確認してから条件式に採用する。

  5. 05

    復活案件を「商談化」で作り直す運用

    担当者合意で見送った案件が復活したとき、元のステージに戻さず商談化から作り直す。これが実際の商習慣・営業心理に合うかどうか未検証。