HubSpot リードステータス設計 — デフォルトを2軸で並べ直す

本記事のポイント

• HubSpot のリードステータスはデフォルト 8 値の並び順に「プロセス (どこまで接触したか)」と「結果 (商談化か見送りか)」の 2 軸が混在しているため、現場に意味が伝わりません
• 2 軸に分解し、プロセス軸 5 段階と結果軸 3 段階に並べ直すと、誰が見ても状況が一目で読めるステータスになります
• 設計だけでは回りません。誰がいつ更新するか (インサイドセールスの運用) とワークフローの自動更新まで決める型と、そのまま使える AI 実行キットを公開します

「リードステータス、デフォルトのままだと意味がわからないから変えようぜ」。humbulls が HubSpot 導入を支援するなかで、営業会議のたびに出てくる声です。この違和感の原因は、担当者の理解不足ではありません。デフォルトの並び順そのものに、性質の違う 2 種類の情報が混ざっていることにあります。本記事では、リードステータスをプロセスと結果の 2 軸に分解して並べ直す設計の型と、インサイドセールスの運用・ワークフロー自動更新までを解説します。特別な知識は不要で、型と巻末のキットがあれば再現できます。

1. デフォルトのままだと現場が混乱する理由 — 8 値の並び順に意味がない

「このステータス、上から順に進むって意味じゃないの? って新人に聞かれて、うまく説明できなかった」。インサイドセールスを立ち上げたばかりの現場から、よく聞く相談です。

HubSpot のリードステータスは、初期状態で 8 つの値を持っています (2026 年 7 月時点)。デフォルトの並び順はこうです。

1. New (新規)
2. Open (オープン)
3. In Progress (進行中)
4. Open Deal (取引開始)
5. Unqualified (見込みなし)
6. Attempted to Contact (連絡試行)
7. Connected (接続済み)
8. Bad Timing (タイミング悪し)

この並びを上から眺めて、違和感に気づけるでしょうか。3 番目の「In Progress (進行中)」の直後に、4 番目「Open Deal (取引開始)」と 5 番目「Unqualified (見込みなし)」という結果が割り込み、そのあとに 6 番目「Attempted to Contact (連絡試行)」・7 番目「Connected (接続済み)」という、本来はもっと手前にあるべき接触プロセスが戻ってきます。つまり、時間の流れでも重要度でもなく、性質の違うものが交互に並んでいます。

原因は明確です。この 8 値には「営業がどこまで接触できたか (プロセス)」と「そのリードがどう決着したか (結果)」という 2 つの軸が最初から混在しています。並び順に軸が 1 本通っていないから、新人に「上から順に進むわけではない」としか説明できない。これがデフォルトのままで現場が混乱する正体です。

よくある失敗は、この違和感を放置したまま値だけを日本語に翻訳して使い始めることです。表示名を変えても軸の混在は解けないので、混乱はそのまま残ります。まず並び順の設計から入るのが順番です。

→ 自社の営業プロセスに合わせたリードステータスの定義は、巻末の 実行キット① (所要 30 分) で生成できます。

2. リードステータスの正体 — ライフサイクルステージ (SQL) のサブステータス

「リードステータスとライフサイクルステージ、どっちに何を入れればいいのか毎回迷う」。HubSpot を使い始めた担当者が最初にぶつかる問いです。

HubSpot 公式の定義では、リードステータスは「Sales Qualified Lead (営業対象と判断したリード) というライフサイクルステージのサブステータス」です (HubSpot Knowledge, 2026-07 取得)。ライフサイクルステージが「購買行動のどの位置にいるか (リード → MQL → SQL → 商談 → 顧客)」という大きな地図だとすれば、リードステータスはそのうち SQL の中だけを細かく見るための虫めがねにあたります。役割が上下ではなく、入れ子になっている関係です。

この棲み分けを理解すると、設計方針がひとつに定まります。ライフサイクルステージをまたぐ情報 (顧客になった、失注した等) をリードステータスに入れてはいけない、ということです。たとえば「Customer (顧客化)」はライフサイクルステージ側で表現すべきで、リードステータスに独自の「成約」値を足すと、2 つのプロパティが同じことを別々に管理し始め、どちらが正しいか分からなくなります。ライフサイクルとリードステータスの詳しい違いは、関連記事 HubSpot のライフサイクルステージ設計 で整理しています。

よくある失敗は、リードステータスを「営業パイプラインの代わり」に使おうとすることです。商談の進捗は Deal (取引) のパイプラインで管理するのが HubSpot の設計思想で、リードステータスはあくまで「SQL に上がったリードへの接触状況」を表す枠です。守備範囲を SQL の中に絞ると、次章の 2 軸分解がきれいに効きます。

3. プロセスと結果の 2 軸で並べ直す — 設計の核

「結局、どういう順番にすればスッキリするの?」。ここが本記事の核心です。

第 1 章で見たとおり、デフォルト 8 値には 2 つの軸が混ざっています。やることはシンプルで、その 2 軸をいったん分解し、それぞれを独立して並べ直すだけです。分けてみると、デフォルト 8 値はきれいに 2 グループに収まります。

プロセス軸 (どこまで接触できたか / 5 段階) — 時間の流れで一直線に進む値。

1. New (新規) — 入ってきたばかり、まだ着手していない
2. Open (オープン) — 有望と判断し、着手すると決めた
3. Attempted to Contact (連絡試行) — 連絡はしたが、まだ相手の反応がない
4. Connected (接続済み) — 相手から反応があり、会話が始まった
5. In Progress (進行中) — 継続的にやり取りしている

結果軸 (どう決着したか / 3 段階) — プロセスの途中や終端で確定する値。

• Open Deal (取引開始) — 商談化した (= Deal を作成する合図)
• Unqualified (見込みなし) — 自社の対象ではないと判断した
• Bad Timing (タイミング悪し) — 今ではないが、将来の可能性は残る

並べ直しの効果は、プロセス軸を上から下へ読むだけで「今この人にどこまで接触できているか」が分かる点にあります。デフォルトで 6〜7 番目に沈んでいた Attempted to Contact・Connected が、New と In Progress のあいだの正しい位置に戻るからです。そして結果軸の 3 値は「そこで会話が止まった / 決着した理由」を表す終端として、プロセス軸の下に別ブロックで置きます。HubSpot の設定画面では、コンタクトプロパティーの「リードステータス」を開き、ラジオ選択オプションをこの順に並べ替えるだけで反映できます。

ここで結果軸の Bad Timing だけは、失注と同じ「終わり」に見えて性質が違います。将来的に再アプローチする母集団なので、ナーチャリングの対象として別管理します。掘り起こしの設計は リードナーチャリングの設計ガイド を参照してください。

よくある失敗は、並べ直すときに欲張って値を増やしてしまうことです。「電話済み」「メール済み」「フォーム返信あり」と接触手段ごとに刻むと、プロセス軸が 10 段階を超え、更新する側が「今どれ?」と迷って結局更新しなくなります。プロセス軸は 5 段階前後、多くても 6 段階に抑えるのが、現場が回せる上限です。

→ 自社版の 2 軸並べ直し表は、巻末の 実行キット① でそのまま出力できます。

4. 誰がいつ更新するか — インサイドセールスの運用設計

「ステータスはきれいに並べ替えたのに、3 週間で全員が更新しなくなった」。設計だけ整えて運用ルールを決めなかった現場で、必ず起きることです。

リードステータスは、置いておけば勝手に埋まるプロパティではありません。誰が・どのタイミングで・どの値に動かすかを決めて初めて、レポートに使える精度になります。プロセス軸の 5 段階には、それぞれ「この行動をしたらこの値にする」という更新トリガーを 1 対 1 で紐づけるのが型です。

運用でまず決めるべきは、「New」だけは人が触らないという線引きです。New は流入時に自動で付く初期値であり、ここを手動運用にすると付け忘れが起きます。人が責任を持つのは Open 以降。この境界を引くと、インサイドセールスの負担が「有望と判断したリードだけ」に絞られ、更新が続きます。

よくある失敗は、更新ルールを口頭で共有して終わりにすることです。「Connected はどこから?」の解釈が人によってズレ、同じ状況のリードに別々の値が付きます。更新トリガーは 1 枚の表にして、定義まで文章で固定してください。掘り起こしや会議で使う数字の信頼は、この定義の統一から生まれます。

→ 自社のインサイドセールス向け更新ルール表は、巻末の 実行キット② (所要 30 分) で作成できます。

5. ワークフローで手更新を減らす — 自動更新の設計

「更新ルールは決めた。でも全部手作業だと、やっぱり抜ける」。運用を始めた現場の、次の本音です。

前章の更新トリガーのうち、システムが検知できるものはワークフローで自動化できます。人が判断しなければならない値 (Open にするか、Unqualified にするか) は手動のまま残し、行動の記録が自動で取れる値だけを自動更新に回すのが振り分けの型です。

自動化に向くのは、たとえば次の 3 つです。

• New の自動付与 — フォーム送信をトリガーに、リードステータスを New にセット
• Attempted to Contact への自動更新 — 1 通目の営業メール送信 (シーケンス開始) を検知して更新
• Connected への自動更新 — メール返信あり / ミーティング予約を検知して更新

一方で「Open (着手すると決めた)」「Unqualified (対象外と判断した)」は人の意思決定なので、自動化しません。ここを無理にスコアリングで自動判定させると、現場感覚とズレたステータスが量産され、かえって信用されなくなります。ワークフローの具体的な組み方は HubSpot ワークフロー活用例 にまとめています。

なお HubSpot Starter プランはワークフロー数に上限があるため、自動更新に何本使うかは計画的に決める必要があります。プラン別の制約は HubSpot 導入・設定ガイド を参照してください。

よくある失敗は、手動と自動を混在させたまま「どの値が自動でどの値が手動か」を現場に共有しないことです。自動で動いた値を人が二重に更新してしまい、履歴が濁ります。自動化した値には運用ルール表で「自動」と明記し、人は触らないと決めてください。

→ 自動更新の対象・トリガー・振り分け表は、巻末の 実行キット③ (所要 30 分) で設計できます。

まとめ

リードステータスがデフォルトのままで現場に伝わらないのは、担当者のせいではなく、並び順に「プロセス」と「結果」の 2 軸が混ざっているからです。2 軸に分解してプロセス 5 段階・結果 3 段階に並べ直し、誰がいつ更新するかを表で固定し、システムで取れる値だけワークフローで自動化する。この 3 点がそろって、初めてレポートに使えるステータスになります。まずは巻末のキット①で、自社の営業プロセスに合わせた並べ直しから始めてみてください。

humbulls では、こうしたリードステータスやライフサイクルの設計から、インサイドセールスの運用定着まで伴走する Growth Partner サービス を提供しています。「設計はできても運用が続かない」と感じたら、ご相談ください。

🤖 AI 実行キット

本文の判断と設計を、そのまま AI で実行するためのキット集です。プロンプトは Claude (ブラウザ版で可) にコピペすれば動きます。

キット① 自社の営業プロセスからリードステータスを設計する — 30 分

種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: 自社のインサイドセールスがリードに接触する流れのメモ (架電するのか、メールなのか、フォーム返信を待つのか等)。箇条書きで構いません。

プロンプト:

HubSpot のリードステータス設計を手伝ってください。

【前提となる知識(必ずこの前提に従うこと)】
- リードステータスは Sales Qualified Lead ライフサイクルステージの
  サブステータス。顧客化・失注などステージをまたぐ情報は入れない。
- リードステータスは 2 軸で構成する:
  - プロセス軸(どこまで接触できたか): 時間の流れで一直線に進む。5 段階前後、
    最大 6 段階まで。接触手段ごと(電話済み/メール済み等)に刻みすぎない。
  - 結果軸(どう決着したか): 商談化 / 対象外 / 時期尚早 の 3 種を基本とする。
- HubSpot デフォルト 8 値(New / Open / In Progress / Open Deal /
  Unqualified / Attempted to Contact / Connected / Bad Timing)を出発点にし、
  自社に不要な値は削り、足りない接触段階だけ足す。

【私の営業プロセス】
- 接触手段: (記入例)フォーム流入 → 架電 → つながらなければメール → 商談化
- インサイドセールスの人数: (記入例)2 名
- (以下、自社の流れを貼り付け)

【出力】
1. プロセス軸の並び(上から順に、各値の定義を 1 行)
2. 結果軸の並び(各値の定義を 1 行)
3. デフォルト 8 値からの差分(残す / 削る / 追加を理由付きで)
4. HubSpot 設定画面での並べ替え手順を 3 行で

出力の確認ポイント:

• プロセス軸が 6 段階を超えていないか。超えていたら接触手段で刻みすぎているので統合する
• 結果軸に「顧客化」「成約」が混じっていないか。混じっていたらライフサイクルステージ側の役割なので削る

うまくいかないとき:

• 値が多すぎて決められない → 「まず最小構成で。プロセス軸 4 段階・結果軸 3 段階だけで再提案して」と指示する

キット② インサイドセールスの更新ルール表を作る — 30 分

種別: 実装キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: キット①で決めたプロセス軸・結果軸の並び

プロンプト:

リードステータスの更新ルール表を作ってください。運用が続く粒度にすること。

【私のリードステータス】
- (キット①の出力を貼り付け)

【設計ルール(必ず従うこと)】
- 各ステータスに「誰が更新するか」「どの行動をしたら更新するか(トリガー)」を
  1 対 1 で紐づける。
- 初期値(New に相当)は自動付与とし、人は触らない。人が責任を持つのは
  「着手すると決めた」以降の値だけにする。
- 「つながった(Connected)」の定義は解釈がぶれやすいので、
  何をもって Connected とするかを 1 文で厳密に定義する。

【出力】
- 表: ステータス / 更新者(自動 or 役割名)/ 更新トリガー / 定義(1 文)
- 表の下に「人が触らない値」と「必ず人が判断する値」を箇条書きで明示

出力の確認ポイント:

• 各ステータスの定義が、別の人が読んでも同じ判断になる具体度か (「連絡した」ではなく「1 回目の架電またはメール送信をした時点」)
• 「自動」と書いた値が、実際にシステムで検知できるトリガーになっているか

うまくいかないとき:

• 定義が曖昧なまま出る → 「各定義に『いつから』『何をもって』を必ず含めて書き直して」と指示する

キット③ ワークフロー自動更新の振り分け表を作る — 30 分

種別: 実装キット 使うもの: Claude (ブラウザ版で可。HubSpot MCP があれば既存ワークフロー数の確認も依頼できます) 事前に用意するもの: キット②の更新ルール表

プロンプト:

リードステータスの自動更新をワークフローに振り分ける表を作ってください。

【私の更新ルール表】
- (キット②の出力を貼り付け)

【振り分けルール(必ずこの順で判定)】
1. システムが行動を検知できる値(フォーム送信・メール送信・返信・
   ミーティング予約など)→「自動更新できる」
2. 人の意思決定が必要な値(着手する / 対象外と判断する / 時期尚早と判断する)
   →「手動のまま」。スコアリングで自動判定させない。
3. 自動化する値には、どのイベントをトリガーにするかを 1 つ明記する。

【出力】
- 表: ステータス / 自動 or 手動 / 自動の場合のトリガーイベント / 補足
- 集計: 自動更新に必要なワークフロー本数(HubSpot Starter は上限があるため本数を明示)
- 手動と自動が混在する運用上の注意を 2 行

出力の確認ポイント:

• 「自動」に振り分けた値が、本当にシステムイベントで一意に決まるか (人の判断が 1 mm でも入るなら手動に戻す)
• 必要ワークフロー本数が、自社プランの上限に収まっているか

うまくいかないとき:

• ワークフロー本数が上限を超える → 「最も更新漏れが起きやすい 2 値だけを自動化対象に絞って再提案して」と指示する

参考文献

• HubSpot のデフォルトコンタクトプロパティー — HubSpot Knowledge (取得日: 2026-07)
• HubSpot のデフォルトリードプロパティー — HubSpot Knowledge (取得日: 2026-07)
• コンタクトと会社のライフサイクルステージを使用する — HubSpot Knowledge (取得日: 2026-07)
• HubSpot Lead Status: How to Use It — hublead.io (取得日: 2026-07)