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

この記事の結論

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

ブログ目次

記事の内容を、そのまま実務に落とし込みたい方向け

HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。


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

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

この記事では、反響から契約までを1本のパイプラインとして設計し、追客の抜けを仕組みで止める考え方を解説します。設計例はHubSpotのデモ環境で再現できる範囲の内容で、特定企業の実データではありません。

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

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

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


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

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

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

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

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

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

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

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

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

見落とされがちなのが育成への影響です。ステージの定義がないと、新人は「どこまでやったら次に進んでいいのか」を先輩の感覚から学ぶしかありません。逆に、ステージと必須項目を定義しておくと、それ自体が新人に「何を確認すべきか」を教えるチェックリストとして機能します。追客管理の設計は、営業管理であると同時に育成の仕組みでもある、というのが結構ミソになってくるところです。


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

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

2つの持ち方の違い

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

観点 取引(Deal)で持つ コンタクトのライフサイクルステージで持つ
数える単位 反響1件・案件1件 顧客1人
同じ人が複数案件を持つ場合 案件ごとに別レコードで並行管理できる 1人につき1つの状態しか持てない
進捗の可視化 ボードビューでステージ別に一覧できる リストやレポートでの集計が中心
金額・確度の管理 取引金額・ステージ確度で加重集計できる 金額は持てない
向いているもの 反響から契約までの案件進捗 顧客の関係性の段階(見込み・顧客・OB)

HubSpotの公式ドキュメントでは、ステージ確度について「ボードビューに表示される加重金額を決定するために使用され、各ステージの合計金額にステージ確度を掛けて計算されます」と説明されています(HubSpot ナレッジベース/2026年8月1日確認)。

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

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

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

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

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

物件情報をどこに持つかは、別の論点として切り分ける

設計を進めると「提案した物件をどこに記録するか」という論点が必ず出てきます。ここを取引のテキスト項目に詰め込むと、後で「この物件を提案した案件の一覧」が出せなくなります。物件を独立したデータとして持つ設計は物件をカスタムオブジェクトで管理するで、データ全体の持ち方は不動産CRMのデータ設計で扱っています。本記事は追客の進捗設計に集中しますが、両方を同時に設計しておくと後戻りが少なくて済みます。


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

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

7ステージの全体像

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

不動産の追客パイプライン設計例。反響受付・一次対応・ヒアリング・物件提案・内見・申込・契約引渡しの7ステージと、離脱の受け皿・計測指標を示した図

図の下段には、後ほど説明する離脱の受け皿(長期追客・他決・連絡不通)と、計測する3つの指標を並べています。追客の設計は、進むルートと離脱するルートをセットで作らないと片手落ちになります。

各ステージの定義

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

# ステージ この状態の意味 次へ進む判定条件(客観的に判定できること) 必須で残す情報 確度の目安
1 反響受付 反響が着信し、担当者が割り当てられた 担当者が設定されている 反響元(媒体)/反響日時/問い合わせ物件 5%
2 一次対応 最初のコンタクトを試みた 架電・SMS・メールのいずれかを1回以上実施し、記録が残っている 一次対応日時/対応手段/接続可否 10%
3 ヒアリング完了 条件が確認できた 予算・エリア・時期・入居/引渡し希望日の4項目が埋まっている 予算/希望エリア/検討時期/人数・間取り 25%
4 物件提案 条件に合う物件を提示した 提案物件を1件以上、案件に紐づけて記録した 提案物件/提案日/提案方法 40%
5 内見・来店 実際に物件を見た、または来店した 内見・来店の実施記録(ミーティング)が完了している 内見日/内見物件/同行者 60%
6 申込 申込書を受領した 申込書の受領日が入力されている 申込日/申込物件/審査状況 80%
7 契約・引渡し 契約が完了した 契約日が入力されている 契約日/契約金額/引渡し予定日 100%

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

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

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

7ステージのボードビュー模式図。反響受付・一次対応・ヒアリング・物件提案・内見/来店・申込・契約引渡しが列として並び、各列に件数が表示されている

列の下にはステージごとの件数と合計金額が集計されます。取引に金額を入れておけば、ステージ確度を掛けた加重金額でフォーキャストが出せます。賃貸なら仲介手数料・広告料、売買なら想定手数料を入れておくと、追客の残量が金額で読めるようになります。


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

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

「誰が」を先に決める

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

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

次に各ステージの滞在期限を決めます。賃貸仲介であれば、一次対応は当日中、ヒアリング完了は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・Smart CRM・Revenue 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(現在のステージでの滞在時間)」といったステージ計算プロパティが用意されています。

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

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

運用上の注意点をひとつ。これらの指標を担当者の評価に直結させると、数字を良く見せるための入力(内見していないのに内見ステージへ動かす等)が始まります。そうなるとデータそのものが信用できなくなり、指標を見る意味がなくなります。まずはステージ定義や期限設定が現実に合っているかを見直すための数字として使い、定義が安定してから評価に組み込む、という順番をおすすめします。


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

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

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

技術的な制約はほとんどありません。HubSpotの開発者向けドキュメントには「Deal, ticket, and custom object pipelines can have up to 100 stages(取引・チケット・カスタムオブジェクトのパイプラインは最大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本、Professionalで最大15本まで作成できます(HubSpot Product and Services Catalog/2026年8月1日確認)。Starterの場合は、賃貸と売買で2本を使い切る形になります。

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

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

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

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

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

具体的には、ステージごとの必須プロパティ(2〜3項目)と、架電・メール・内見といったアクティビティの履歴があれば、レビューにも引き継ぎにも十分対応できます。

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

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

重要なのは回数そのものよりも、閉じた案件が後から検証できる状態にしておくことです。試行回数を残しておけば「3回で閉じているが、5回試した案件では復活率が高い」といった検証ができ、ルール自体を改善できます。

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

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

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


まとめ

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

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

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

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


株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化(ERP/CRM/SFA/MAの導入)」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

関連キーワード:

サービス資料を無料DL

著者情報

7-1

今枝 拓海 / Takumi Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。