不動産の追客管理をHubSpotで設計する｜反響から来店・申込までのパイプライン

「反響は毎月それなりに入っているのに、追客が続かず自然消滅してしまう」「誰がどこまで追ったのかを、担当者に聞かないと分からない」——不動産会社の営業責任者の方から、こうしたお話をうかがうことが多いかなと思います。

結論から申し上げます。追客が続かない原因の大半は担当者の意欲ではなく、追客の状態を客観的に記録する型がないことにあります。型がないと、追えているのか放置しているのかを誰も判定できず、「頑張っている人だけが追客できている」状態になってしまいます。

この記事では、反響から契約までを1本のパイプラインとして設計する考え方を解説します。設計例はHubSpotのデモ環境で再現できる範囲の内容です。

反響の取りこぼしに課題を感じている不動産会社の営業責任者の方、追客の状況が担当者に聞かないと分からない状態を変えたい方に向けた内容です。

• 追客をどのオブジェクトで持つか ── 取引（Deal）で管理する場合と、コンタクトのステージで管理する場合の判断基準を整理します。
• 反響から契約までの7ステージ設計 ── 各ステージを「営業の手応え」ではなく、客観的に判定できる条件で定義する具体例を示します。
• 離脱の受け皿の作り方 ── 長期追客・他決・連絡不通を分けて持ち、失注理由を必ず残す設計を解説します。
• 追客の状態を数字で見る方法 ── 一次対応率・内見化率・滞留日数を、HubSpotでどう計測するかを説明します。

読み終える頃には、自社の「追客中」を分解してステージに落とし込む手順が明確になるはずです。ぜひ最後までご確認ください。

追客が続かない原因は「担当者の意欲」ではなく「管理の型がない」こと

追客の失敗を人の問題として扱うと、対策は「もっと電話しよう」という精神論になりがちです。実際には、抜けているのは意欲ではなく、次に何をすべきかが記録に残っていない状態であることがほとんどです。

「追客中」という状態が一番危ない

多くの不動産会社の管理表には「追客中」という区分があります。この区分が曲者で、昨日架電した案件も、3週間連絡していない案件も、同じ「追客中」に入ってしまいます。

つまり「追客中」という言葉は、何もしていない状態を隠せてしまうわけですね。危険な案件が浮かび上がらないので、責任者は介入するタイミングを失います。ここを分解して客観的に判定できる形にするのが、追客管理の出発点です。

ポータルサイトの管理画面やExcelでは追客の履歴が残らない

SUUMOやHOME'S、at homeといったポータルサイトの管理画面は、反響を受け取るところまでは優秀です。一方で「誰がいつ架電して、何を聞いて、次にいつ連絡するのか」を蓄積する用途では設計されていません。

そのためExcelに転記することになりますが、転記した瞬間に更新は手作業になります。担当者が忙しくなれば更新は止まり、責任者はリアルタイムの判断ができません。

型がないと、教育もレビューもできない

見落とされがちなのが育成への影響です。ステージと必須項目を定義しておくと、それ自体が新人に「何を確認すべきか」を教えるチェックリストになります。追客管理の設計は、営業管理であると同時に育成の仕組みでもあるわけですね。

追客を取引（Deal）で管理するか、コンタクトのステージで管理するかの判断

設計に入る前に、追客をどのオブジェクトで持つのかを決める必要があります。ここを曖昧にしたまま作り始めると、後からレポートが噛み合わなくなります。

2つの持ち方の違い

HubSpotで追客を管理する場合、取引（Deal）で持つ方法と、コンタクトのライフサイクルステージで持つ方法があります。それぞれ得意なことが違います。

ステージ確度は、公式ドキュメントによると「各ステージの合計金額にステージ確度を掛けて」加重金額を算出するために使われます（HubSpot ナレッジベース／2026年8月1日確認）。

反響1件＝取引1件で持つのが基本

不動産の追客では、反響1件を取引1件として持つ設計を基本に考えるのがおすすめです。追客の進捗は「人の状態」ではなく「案件の状態」だからです。

同じお客様が賃貸の住み替えで問い合わせた後、数年後に購入で再び問い合わせることもあります。人に状態を持たせているとこの2件を区別できません。取引で持てば別案件として並行管理でき、過去のやり取りは同じコンタクトの履歴に残ります。

なお、提案した物件をどこに記録するかは別の論点です。取引のテキスト項目に詰め込むと「この物件を提案した案件の一覧」が出せなくなりますので、物件をカスタムオブジェクトで管理すると不動産CRMのデータ設計もあわせてご覧ください。

コンタクトのライフサイクルステージは「人」の状態を持たせる

コンタクトのライフサイクルステージには、「この方は現在どういう関係性か」を持たせます。問い合わせ段階か、契約済みのお客様か、過去に成約したOB顧客か、といった区分です。役割を分けておくと、メール配信や再来店の案内はコンタクト側、営業の進捗管理は取引側で独立して回せます。この考え方の全体像はステージ設計とライフサイクルで整理しています。

反響から契約までの7ステージ設計例

反響受付から契約・引渡しまでを7つのステージに分けた設計例をご紹介します。企業様によって最適な形は異なりますので、叩き台として捉えていただければと思います。

7ステージの全体像

7つにしている理由は、受注確度が明確に変わるポイントだけを区切るという基準に沿った結果です。細かく分ければ分かりやすくなるわけではなく、確度が変わらないところで区切っても入力が増えるだけになります。

図の下段には、後ほど説明する離脱の受け皿（長期追客・他決・連絡不通）と、計測する3つの指標を並べています。追客の設計は、進むルートと離脱するルートをセットで作るのが前提です。

各ステージの定義

ステージ定義でもっとも重要なのは、次へ進む判定条件を客観的に書くことです。「お客様の温度感が上がったら」ではなく、「架電またはSMSを1回以上実施した」のように、記録を見れば誰でも同じ判定ができる書き方にします。

「ヒアリング完了」を4項目の入力で判定している点が、この設計のポイントになってきます。ヒアリングは、やったかどうかが一番曖昧になりやすい工程です。項目が埋まっているかで判定すれば、責任者もレビューできる状態になります。

設計したステージは、実際にこう見える

設計したステージは、HubSpotではボードビューとして表示されます。ステージごとに列が並び、案件のカードをドラッグで次のステージへ移動できる、という見え方になります。

賃貸なら仲介手数料・広告料、売買なら想定手数料を取引金額に入れておくと、ステージ確度を掛けた加重金額で追客の残量が読めるようになります。

ステージの進め方を定義する（誰が・いつまでに・何をしたら次へ進むか）

ステージを作っただけでは運用は始まりません。「誰が担当するのか」「いつまでに次へ進めるのか」を決めて、はじめて型として機能します。

「誰が」を先に決める

反響対応を分業している会社であれば、ステージごとに担当が変わります。反響受付と一次対応は反響対応チーム、ヒアリング以降は店舗の営業担当、といった分け方です。ステージが変わるタイミングで担当者も切り替わる設計にしておくと、責任の所在が明確になります。振り分けの自動化はリードの傾斜配布を自動化するで扱っています。

「いつまでに」を数字で置く

次に各ステージの滞在期限を決めます。賃貸仲介なら一次対応は当日中、ヒアリング完了は3日以内といった短いサイクルですが、売買仲介や注文住宅は検討期間が長いので、同じ基準では全案件が期限切れになります。最初は現状の中央値をそのまま期限に置き、運用しながら締めていくのが現実的です。

必須プロパティでステージの意味を守る

ステージ定義を守らせる仕組みとして有効なのが必須プロパティです。HubSpotの公式ドキュメントには「プロパティーが必須となっている場合、ユーザーが値を設定するまで、レコードを作成または更新することはできません」と記載されています（HubSpot ナレッジベース／2026年8月1日確認）。

「内見・来店」に進めるときに内見日を必須にしておけば、内見していない案件がそのステージに入ることを防げます。ただし必須項目を増やしすぎるとステージ移動が嫌われ、まとめて後から動かす運用になります。1ステージあたり多くても2〜3項目がちょうどよいバランスです。

離脱の受け皿をどう作るか

ここが、追客管理でもっとも設計が甘くなりやすい部分です。進むルートは誰でも設計しますが、進まなかった案件は後回しにされがちです。

「失注」に全部入れると、掘り起こしができなくなる

離脱をすべて「失注」に入れると、そのデータは二度と使えなくなります。実際の失注の中身は大きく3種類に分かれていて、それぞれ次にやるべきことがまったく違うからです。

3つの離脱を分けて持つ

この3つを分けておくと、責任者が見るべきものが変わります。他決が多ければ提案内容や物件在庫、連絡不通が多ければ一次対応のスピードや手段、長期追客が多ければ反響の質、というように、改善すべき打ち手が離脱の内訳から読めるわけですね。

長期追客をパイプラインに残すか、閉じるか

長期追客の扱いは実務で必ず議論になります。「まだ見込みがあるのだからパイプラインに残したい」という意見が出るのですが、ここは慎重に判断したほうがよいところです。

パイプラインに残すと、滞留日数の平均が長期追客に引っ張られて、本当に止まっている案件が見えなくなります。おすすめは、取引はいったんクローズし、コンタクト側に「再アプローチ予定時期」を持たせて、その時期が来たら新しい取引を作る運用です。パイプラインが常に「いま動いている案件」だけになり、滞留日数が意味を持ちます。

一方、売買仲介のように検討期間が半年〜1年に及ぶ業態では、長期追客を別パイプラインとして持つ選択肢もあります。判断基準は「その案件に、直近30日以内にやるべきアクションがあるかどうか」に置くと整理しやすいかなと思います。

失注理由は必須にして、選択肢を絞る

離脱を分けるうえで欠かせないのが、失注理由の必須化です。失注ステージに移すときの必須プロパティにしておけば、理由が空欄の失注はなくなります。

選択肢は多くても7つ程度に絞ります。「他決（他社）」「他決（他物件）」「予算が合わない」「条件に合う物件がない」「時期が先」「連絡不通」「対象外・冷やかし」あたりが実用的な粒度です。選択肢を増やしすぎると、担当者が毎回一番上を選ぶようになるので、絞ることが品質につながります。

追客の抜けを止める仕組み（タスク・シーケンス・期限切れの通知）

ステージと離脱の設計ができたら、次は運用が続く仕組みを作ります。全部を一度に入れる必要はなく、順番があります。

まずタスクで「次の一手」を必ず持たせる

最初にやるべきは、稼働中のすべての案件に期日付きのタスクが1つ以上ついている状態を作ることです。タスクがない案件は誰も次の一手を決めていないので、そのまま放置されます。

HubSpotのタスク機能は「すべての製品とプラン」で利用でき、期日前のEメールリマインダーや、完了・削除・期限超過をきっかけに次のタスクを自動生成する繰り返しタスクも用意されています。ただし繰り返しタスクにはコアシート・Salesシート・Serviceシートのいずれかが、ワークフロー経由のタスク作成にはProfessionalまたはEnterpriseが必要です（HubSpot ナレッジベース／2026年8月1日確認）。

定型のフォローはシーケンスに寄せる

一次対応後のフォローメールのように内容が決まっているものは、シーケンスで自動化できます。営業担当個人の受信トレイから送られるため、個別のフォローとして届くのが特徴です。

利用にはSales HubまたはService HubのProfessional・Enterpriseが必要で、1つのシーケンスで使えるメールテンプレートは10個まで、タスクリマインダーのステップは必要な数だけ追加できるとされています（HubSpot ナレッジベース／2026年8月1日確認）。

期限切れ・滞留はワークフローで通知する

3つ目が、滞在期限を過ぎた案件を検知して通知する仕組みです。「一次対応のまま24時間経過した案件を店長に通知する」といった形にすると、責任者が管理表を見に行かなくても介入できます。ワークフローはMarketing Hub・Sales Hub・Service Hub・Data Hubなど各製品のProfessionalおよびEnterpriseで利用できます（HubSpot ナレッジベース／2026年8月1日確認）。設定手順はHubSpotワークフローの設定をご覧ください。

3つ全部を最初から作らない

正直に申し上げると、この3つを同時に導入するとほぼ確実に運用が止まります。通知が増えすぎて誰も見なくなるからです。おすすめはタスク → 期限切れ通知 → シーケンスの順で、1つずつ定着を確認しながら足す進め方です。タスクが100%ついている状態を1ヶ月維持できたら、次に通知を1本だけ追加する。この速度が結果として一番早く定着します。

追客の状態を数字で見る（一次対応率・内見化率・滞留日数）

ステージ設計の副産物として、追客の状態を数字で見られるようになります。設計の答え合わせをする場所でもあります。

3つの指標の定義

見るべき指標は最初は3つで十分です。多く並べても、改善アクションに結びつかない数字は誰も見なくなります。

一次対応率は、単に「対応したか」ではなく期限内に対応したかで測るのがポイントになってきます。3日後に架電しても対応済みにカウントしてしまうと、この指標は改善の役に立ちません。

ステージ別の件数・金額はそのままレポートになる

ステージを設計しておくと、ステージ別の件数と金額の集計はそのままレポートとして出せます。ファネルの形にすると、どのステージで落ちているかが一目で分かります。

ステージ設計の粒度が、そのままレポートの粒度になります。逆に言えば、レポートで見たい単位が決まらないままステージを設計すると、後から見たい数字が出せないということです。設計の段階で「月次でどの数字を見るか」を先に決めるのが結構重要です。

ステージ計算プロパティは既定でオフになっている

滞留日数を測るには、ステージへの移行日時を記録するプロパティが必要です。HubSpotには「Date entered（ステージに移行した日付）」「Date exited（ステージから移行した日付）」「Time in current stage（現在のステージでの滞在時間）」といったステージ計算プロパティがあります。

ただし公式ドキュメントには「新しいパイプラインおよびステージでは、ステージ計算プロパティは既定でオフになっています」と明記されており、設定画面のパイプラインタブからオンにする必要があります。利用にはProfessionalまたはEnterpriseが必要です（HubSpot ナレッジベース／2026年8月1日確認）。ここを知らずに数ヶ月運用すると、その期間の滞留日数は遡って取得できません。パイプラインを作った直後にオンにするのが、後から効いてくるポイントです。

数字は「担当者評価」ではなく「設計の見直し」に使う

これらの指標を担当者の評価に直結させると、数字を良く見せるための入力（内見していないのに内見ステージへ動かす等）が始まり、データが信用できなくなります。まずはステージ定義や期限設定を見直すための数字と位置づけ、定義が安定してから評価に組み込む順番をおすすめします。

ステージを増やしすぎたときに起きること

運用を始めると、必ず「このステージも欲しい」という要望が出てきます。ここでの判断が、1年後の運用品質を分けます。

上限には余裕がある。問題は運用側にある

技術的な制約はほとんどありません。HubSpotの開発者向けドキュメントには「取引・チケット・カスタムオブジェクトのパイプラインは最大100ステージまで」と記載されています（HubSpot Developers／2026年8月1日確認）。

本数も、製品・サービスカタログでは取引パイプラインがStarterで最大2本、Professionalで最大15本、Enterpriseで最大100本とされています（HubSpot Product and Services Catalog／2026年8月1日確認）。制約は上限ではなく、現場が入力し続けられるかどうかです。

増やしていいステージ・増やしてはいけないステージ

判断基準はシンプルで、「そのステージの前後で受注確度が変わるか」です。「内見予定」と「内見実施済み」は確度が明確に変わるので分ける価値がありますが、「資料送付済み」と「資料開封済み」は、確度の差が説明できないなら分けないほうがよい例です。ステージを増やすほど、誰かが毎回カードを動かす手間が増える点は忘れないようにしたいところです。

迷ったらプロパティで持つ

「この情報も残したい」という要望の多くは、ステージではなくプロパティで解決できます。「審査中」はステージにしたくなりますが、申込ステージの中の「審査状況」というプロパティで持てば十分なことが多いです。この考え方はHubSpotのパイプライン設計でも整理しています。不動産全体でのHubSpot活用の全体像は不動産業界のHubSpot活用法をご覧ください。

よくある質問

追客パイプラインの設計でよくいただくご質問をまとめました。

Q1. 賃貸と売買で、パイプラインは分けるべきでしょうか

分けることをおすすめします。賃貸と売買では検討期間もステージの意味も期限の基準も違うため、同じパイプラインに入れると滞留日数や内見化率が混ざって読めなくなります。

なお取引パイプラインはStarterで最大2本までのため（出典は本文中に記載）、Starterの場合は賃貸と売買で2本を使い切る形になります。

Q2. 一次対応の期限は、何時間に設定するのがよいですか

自社の実績から決めることをおすすめします。「◯分以内が正解」という一般的な基準もありますが、根拠が確認できない数値を前提に置くのは危険ですし、業態によって適正値も変わります。

現実的には、現状の所要時間を1ヶ月分集計し、その中央値を最初の期限に置きます。そのうえで、期限内に対応できた案件とそうでない案件で内見化率に差が出るかを比較すれば、自社にとって意味のある閾値が見えてきます。

Q3. 追客の記録は、どこまで細かく残すべきでしょうか

ステージ移動の判定に必要な情報と、次の担当者が引き継げる情報の2つに絞るのがよいかなと思います。すべてを記録しようとすると、入力負荷で運用が止まります。

具体的には、ステージごとの必須プロパティ（2〜3項目）とアクティビティの履歴があれば、レビューにも引き継ぎにも十分です。

Q4. 連絡不通の案件は、何回試したら閉じてよいのでしょうか

回数のルールを社内で決めて、その回数を記録に残す運用が確実です。「3回架電して不通なら、メールとSMSを1通ずつ送り、それでも反応がなければ閉じる」といった形です。

重要なのは回数よりも、閉じた案件が後から検証できる状態にしておくことです。試行回数を残しておけば、ルール自体を実データで見直せます。

Q5. HubSpotのStarterプランでも、この設計はできますか

7ステージのパイプライン設計、必須プロパティの設定、タスクによる次アクション管理までは、上位プランでなくても構成できます。一方で、期限切れの自動通知（ワークフロー）、シーケンス、ステージ計算プロパティは、いずれも公式ドキュメント上ProfessionalまたはEnterpriseが必要とされています（出典は本文中に記載）。

まずはステージ定義とタスク運用を型として定着させ、手作業の確認が限界に来た段階で自動化を検討する順番が現実的です。仕組みを買ってから型を作るのではなく、型を作ってから仕組みで固めるほうが失敗が少ないかなと思います。

まとめ

不動産の追客管理は、担当者の意欲ではなく管理の型で決まります。要点を整理します。

• 追客は取引（Deal）で持ち、反響1件＝取引1件とする。 コンタクトのライフサイクルステージには「人の状態」を持たせ、役割を分けます。
• ステージ定義は客観的に判定できる条件で書く。 「温度感が上がったら」ではなく「架電またはSMSを1回以上実施した」「予算・エリア・時期・希望日の4項目が埋まっている」と書きます。
• 離脱の受け皿を、長期追客・他決・連絡不通の3つに分ける。 失注理由を必須にし、選択肢は7つ程度に絞ります。長期追客を残すと滞留日数が意味を失います。
• 仕組みはタスク → 期限切れ通知 → シーケンスの順で1つずつ入れる。 同時に導入すると通知が飽和します。
• ステージを増やす基準は「前後で受注確度が変わるか」。 変わらないものはプロパティで持ちます。

最初の一歩としておすすめなのは、いま「追客中」に入っている案件を、上記7ステージのどこに当てはまるかで仕分けてみることです。一次対応すら終わっていない案件がどれくらいあるのか、どこで止まっているのかが、その場で見えてきます。そこから設計を始めると、机上のパイプラインよりずっと現場に合ったものになります。

自社の追客プロセスにどう当てはめるかを具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の運用をうかがったうえで、設計の方向性をご提案します。