%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
失注分析は、商談の敗因を組織の改善材料に変える取り組みです。分類・入力・可視化・改善を一つの流れとして設計することが核心です。
失注分析は、商談の敗因を組織の改善材料に変える取り組みです。分類・入力・可視化・改善を一つの流れとして設計することが核心です。
失注分析とは、失注した商談の理由を共通の分類で記録し、ステージ別・理由別に集計して、営業プロセスや提案内容の改善につなげる取り組みです。HubSpotでは、取引に選択式の失注理由プロパティを作り、「失注」ステージへの移動時に必須入力にし、レポートとダッシュボードで傾向を確認する、という3段階で仕組み化できます。本記事では、分類の考え方に加えて、画面の場所と設定手順、掘り起こしワークフローの作り方までを解説します。
「失注した案件が、そのまま営業担当者の記憶に埋もれている」「負けた理由が感覚的な報告にとどまっている」「受注率を改善したいが、見直す場所を特定できない」——このような状態では、商談件数を増やしても同じ失注を繰り返す可能性があります。
失注分析とは、失注した商談の理由を体系的に分類し、傾向を可視化して、営業プロセスや提案内容、商材の改善につなげる取り組みです。個別案件の反省だけで終わらせず、組織が次の商談で活用できる知見へ変えることが目的です。
本記事では、失注分析を組織的に設計・運用するためのフレームワークと、CRM/HubSpotでの具体的な実装方法を解説します。
本記事は「セールスイネーブルメントの設計と実践｜営業組織を仕組みで強くする方法」シリーズの一部です。
この記事でわかること
「失注理由が『その他』ばかりで分析できない」「負けた商談から学ぶ仕組みがない」とお感じの方に、特に読んでいただきたい内容です。
- 失注分析の目的 — 案件ごとの反省ではなく、組織全体の失注傾向を把握し、受注率の改善につなげる考え方を解説します。
- 失注理由の分類フレームワーク — 価格・競合・製品や機能・タイミング・自社プロセスという観点から、敗因を整理する方法を紹介します。
- CRMとHubSpotでの実装方法 — 取引プロパティ、パイプラインルール、レポートを組み合わせて、データ収集を仕組み化する流れを説明します。
- 部門横断の改善方法 — 失注データを営業だけで抱えず、マーケティングやプロダクトの施策へつなぐ考え方を整理します。
- 失注後の掘り起こし設計 — 失注理由に応じてナーチャリングへ戻し、再商談化を検討する運用を解説します。
最後まで読むと、自社の失注理由の分類案、HubSpotでの設定手順（プロパティ・必須項目・レポート・ワークフロー）、運用開始後の見直し方を持ち帰れます。なお、画面のメニュー名は英語版の表記を基準にしており、HubSpotの更新や言語設定によって表示が異なる場合があります。
失注分析とは何か
失注分析は、失注した案件を一覧にするだけの作業ではありません。商談がどの段階で止まり、どのような理由で選ばれなかったのかを共通の基準で記録し、次の意思決定に使える形へ整えるプロセスです。
個人の経験を共有するだけでは、担当者の異動や引き継ぎによって知見が失われます。CRMに共通の分類と判断基準を持たせることで、新人や後任者も過去の傾向を確認できる仕組みに変えられます。
個別案件の反省と組織分析の違い
| 区分 | 確認すること |
|---|---|
| 個別案件の振り返り | 顧客とのやり取りや提案の経緯を詳しく確認する |
| 組織としての失注分析 | 複数の案件を同じ軸で比較し、繰り返し発生している傾向を探す |
例えば、担当者ごとの自由記述だけでは、「予算が合わない」「価格が高い」「費用対効果を示せなかった」といった表現が別々に蓄積されます。
内容が近くても表現が異なるため、集計時に手作業で読み直さなければなりません。
そこで、集計に使う選択式の失注理由と、案件固有の事情を残す補足メモを分けます。共通項目で全体傾向を把握し、必要な案件だけ補足メモを確認する設計が扱いやすい形です。
失注データを改善材料に変える流れ
失注分析は、記録から改善までをつなげて初めて機能します。基本となる流れは次のとおりです。
- 失注理由を共通の選択肢で記録します
- パイプライン上の離脱地点と組み合わせて集計します
- 発生頻度や商材との関係を確認します
- 対応する改善施策と担当部門を決めます
- 施策の実施後に失注傾向の変化を確認します
分析結果を眺めるだけでは、受注率の改善にはつながりません。失注理由と改善アクションを対応させ、次回の確認方法まで決めておくことがポイントになってきます。
営業プロセス全体での位置づけ
失注分析は、営業活動の末端に置かれた集計作業ではありません。コンタクトの獲得から取引の作成、商談、受注後の顧客管理や請求へ進む業務フローの中で、商談から離脱した案件を学習材料へ戻す役割を持ちます。
失注理由に応じて、次のように扱います。
- タイミングが理由 ── ナーチャリングへ戻す判断につながります
- 製品や機能が理由 ── プロダクトへのフィードバックになります
- 自社の対応が理由 ── パイプラインや営業プロセスの見直しが必要です
このように、失注分析はCRMを単なるデータベースではなく、営業プロセスの標準化、部門間連携、意思決定を支える仕組みとして活用するための重要な接点です。
さらに深掘りしたい方は営業マネジメントの型化もあわせてお読みください。
失注分析が受注率の改善に必要な理由
受注率を改善するには、受注案件の成功要因だけでなく、失注案件で繰り返されている障害を把握する必要があります。
受注案件だけを見ていると、顧客が比較の途中で離れた理由や、提案が進まなかった条件を捉えにくいためです。
失注データを共通の基準で蓄積すれば、営業個人の感覚ではなく、組織として改善対象を検討できます。
商談件数を増やす前に改善点を特定できる
新しいリードや商談を増やしても、同じ理由で失注し続ければ、営業活動の負荷が増える一方です。
まず既存の商談がどこで止まっているかを確認すると、見直す対象を絞り込めます。次のような対象があります。
- 提案資料
- ヒアリング
- フォローアップ
- ターゲット設定
ここで重要なのは、失注を営業担当者の力量だけに結びつけないことです。次のような仕組み側の要因も確認します。
- 入力項目
- ステージ定義
- 提案資料
- 社内連携
- フォローのタイミング
個人への注意や研修だけで対処すると、担当者が変わったときに同じ問題が再発しやすくなります。
誰が担当しても同じ判断基準で動けるように、CRMと営業ルールへ改善内容を反映させることが大切です。
営業とマーケティングの共通言語になる
営業が顧客から得た失注意見は、マーケティングにとっても重要な情報です。
- タイミングによる失注が目立つ場合 ── 検討を継続する見込み顧客への情報提供を見直せます
- 競合による失注が目立つ場合 ── 比較時に伝えるべき差別化ポイントを整理できます
製品や機能に関する失注は、プロダクト側が検討すべき要望を把握する材料になります。
ただし、個別の要望をそのまま開発判断へ置き換えるのではなく、同じ傾向が繰り返されているか、対象とする顧客層に共通するかを確認する必要があります。
営業の感想ではなく、失注理由と商談情報を組み合わせて共有することで、部門間の議論を具体化しやすくなります。
Excelやスプレッドシート管理の限界を補える
Excelやスプレッドシートで失注案件を管理すると、次のような問題が起きやすくなります。
- 担当者ごとに入力表現が変わりやすい
- 取引情報と顧客情報が別々のファイルに分かれることがある
- 更新のたびに転記が発生すると、入力漏れや古い情報の残存にもつながる
CRMでは、次のことができます。
- 取引レコードに失注理由を持たせ、関連するコンタクトや会社、活動履歴と結び付けて確認できる
- 選択式のプロパティを使えば、表記の揺れを抑えながら集計できる
ただし、CRMを導入しただけで分析できるわけではありません。選択肢が現場の営業プロセスと合っていなければ、入力されても判断に使えないデータになります。
先に分類と運用ルールを設計し、その後にCRMへ実装する順序が重要です。
実務での応用については営業生産性を向上させる仕組みで具体例とともに紹介しています。
失注理由を分類するフレームワーク
失注分析の精度は、失注理由の分類設計に左右されます。分類が粗すぎれば改善対象を絞れず、細かすぎれば営業担当者が選択に迷います。
最初から完成形を目指すのではなく、代表的な観点から始め、補足メモに現れた傾向を見ながら調整する方法をおすすめします。
代表的な失注理由の整理
| 分類 | 失注理由の例 | 確認する論点 |
|---|---|---|
| 価格・予算 | 予算を超えている、費用対効果が合わない、予算を確保できない | 価格だけが理由か、価値を十分に伝えられたか |
| 競合 | 他社を選んだ、既存ツールを継続した | 比較された条件と選定理由は何か |
| 製品・機能 | 必要な機能がない、セキュリティ要件に合わない、連携上の制約がある | 対象顧客の共通要件か、個別要望か |
| タイミング | 導入時期が合わない、社内体制が整わない、検討が中断した | 再検討時期とフォロー条件を把握できるか |
| プロセス・自社要因 | 提案が課題に合わない、フォローが不足した、意思決定者へ届かない | 営業プロセスや提案方法をどう見直すか |
同じ案件でも、表面的な理由と背景にある理由が異なる場合があります。「価格」と回答された案件でも、価値の説明が不足していた可能性や、対象顧客との適合が弱かった可能性があります。
そのため、選択式の分類だけで判断を終えず、顧客の発言や商談経緯を補足メモへ残します。集計しやすさと案件理解の両方を維持する設計が必要です。
大分類と詳細理由を分ける
失注理由は、大分類と詳細理由を分けると整理しやすくなります。
- 大分類 ── 部門横断の傾向把握に使います
- 詳細理由 ── 営業プロセスや施策の改善に使います
例えば、大分類が「タイミング」であっても、社内体制が整っていないケースと、導入時期が先になったケースでは、次の対応が異なります。
- 前者 ── 体制づくりに役立つ情報提供が候補になります
- 後者 ── 再検討時期に合わせたフォローが候補になります
一方で、詳細理由を増やしすぎると入力者が判断できなくなります。次の点を意識します。
- 実際の失注案件で使われる分類に絞り、役割が重複する選択肢は統合する
- 使われていない項目を残し続けない（入力画面を扱いやすくするポイントです）
選択式と補足メモを併用する
集計対象となる失注理由は選択式にします。自由記述だけで運用すると、同じ意味の表現が分散し、集計前に文章を読み直す作業が発生します。
ただし、選択式だけでは顧客の背景や営業担当者の判断根拠を残せません。そこで、補足メモには次のような内容を記録します。
- 顧客から伝えられた理由
- 営業担当者が把握した背景
- 比較された条件
- 再検討の可能性
- 次に連絡する際の注意点
選択式は分析のため、補足メモは文脈を理解するために使います。この役割を明確にすると、入力項目を増やしすぎずに必要な情報を残せます。
この領域に関心がある方には営業プロセスの可視化と標準化もおすすめです。
パイプラインから失注分析を設計する方法
失注理由だけを独立して設計すると、商談のどの段階で問題が起きたのかを判断できません。取引ステージ、受注確度、ステージの定義、移行時に入力するプロパティを一体として設計することが重要です。
この設計によって、失注分析は商談終了後の記録ではなく、営業プロセス全体を改善する仕組みになります。
取引ステージを離脱地点として捉える
取引ステージは、営業担当者の作業状況ではなく、顧客の意思決定がどこまで進んだかを表す基準として設計します。ステージの境界が曖昧だと、同じ状態の案件が異なるステージに置かれ、離脱傾向を比較できません。
初期の商談で失注する案件と、見積もり提示後に失注する案件では、見直すべき内容が異なります。
| 失注した段階 | 論点 |
|---|---|
| 初期の商談 | ターゲットやヒアリング |
| 見積もり提示後 | 提案内容、価格、競合比較など |
失注理由と直前の取引ステージを組み合わせることで、「何が理由だったか」に加えて「どの段階で発生したか」を確認できます。
受注確度とフォーキャストを切り分ける
各ステージには、受注の見込みを表す考え方があります。ただし、営業担当者の期待だけで受注確度を判断すると、案件ごとの基準が揃いません。
ステージの定義と受注確度を対応させ、どの条件を満たしたら次へ進むのかを明文化します。失注案件についても、どの条件を満たせずに止まったかを確認しやすくなります。
失注分析では、担当者の感覚的な見込みと、実際の商談状態を混同しないことが重要です。
パイプラインの基準を共有することで、フォーキャストと失注分析の両方に使えるデータを整えられます。
ステージ定義を共通化する
ステージ名だけでは、営業担当者ごとの解釈を防げません。「提案中」が、提案資料を送った状態なのか、顧客が社内検討を始めた状態なのかによって、商談の意味は変わります。
ステージごとに、次の項目を定義します。
- 顧客の状態
- 完了条件
- 確認すべき情報
新人や後任者も同じ基準で案件を更新できるため、引き継ぎや営業育成にも活用できます。
定義は営業現場だけで作るのではなく、次を組み合わせて整理します。
- マネージャーや成果を出している担当者が持つ知見
- 過去の受注・失注傾向
個人の経験をパイプラインへ落とし込むことが、営業プロセスを組織の資産に変えるうえで要になる部分です。
移行時に必要なプロパティを決める
ステージを移動するときに入力する項目は、その後の営業活動やレポートで使う情報に絞ります。失注時であれば、次のような項目が候補です。
- 失注理由
- 詳細理由
- 補足メモ
- 再検討の可能性
入力項目を増やしすぎると、更新の負担が高まり、内容が形骸化します。レポート、フォロー、マネジメントのいずれにも使わない項目は、設定の必要性を見直します。
一方で、失注理由のように分析の前提となる項目は、ステージ移行時の必須プロパティとして設定します。
入力を担当者の記憶や善意だけに任せず、システム側で抜けを防ぐ設計にすることで、継続的にデータを蓄積しやすくなります。
CRMとHubSpotで失注データを収集する設計
HubSpotで失注分析を行う場合は、取引プロパティ、パイプラインルール、レポートをつなげて設計します。画面上に項目を作るだけではなく、入力する場面と分析する場面まで一気通貫で考えることが重要です。
最初は基本的な失注理由と必須入力から始め、実際の運用で必要性が確認できた項目やレポートを段階的に追加します。
取引プロパティを設計する
取引オブジェクトには、失注理由の大分類、詳細理由、補足メモを設定します。
- 大分類と詳細理由 ── 選択式にします
- 補足メモ ── 案件固有の背景を残す欄として使います
項目名だけでなく、各選択肢の判断基準も社内で共有します。同じ案件を見た担当者が異なる分類を選ぶ状態では、集計結果を比較できません。
項目を設計するときは、レポートで何を確認したいかを先に決めます。分析に必要な情報が取引レコードに揃っているかを確認します。例は次のとおりです。
- 商材別に比較するなら商材情報
- パイプラインの離脱地点を見るなら直前ステージ
HubSpotでの取引プロパティの作り方は次のとおりです（出典：Create and edit properties）。
- 上部ナビゲーションの設定（歯車アイコン）から左サイドバーの「Properties」を開き、「Select an object」で「取引」を選びます
- 表の上の「Create property」を選び、下の表のプロパティを作成します。失注理由の大分類・詳細は、集計のために選択式（ドロップダウン）にします
- 標準の失注理由プロパティ（Closed lost reason）が自由記述になっている場合は、集計用の選択式を別に作り、標準のものは補足の自由記述として使い分けると、既存データを壊さずに移行できます。自社のポータルで標準プロパティの種類を確認してから決めてください
| プロパティ名（例） | 種類 | 選択肢・入力の例 |
|---|---|---|
| 失注理由（大分類） | ドロップダウン | 価格・予算／競合／製品・機能／タイミング／プロセス・自社要因 |
| 失注理由（詳細） | ドロップダウン | 予算超過／費用対効果が合わない／導入時期が合わない／体制が整わない など。大分類の定義に沿って絞る |
| 失注補足メモ | 複数行テキスト | 顧客の発言、比較された条件、次に連絡する際の注意点 |
| 再検討可能時期 | 日付 | タイミングが理由の失注で、再確認する月日 |
| 競合名 | ドロップダウン | 「競合」が理由のときだけ使う。選択肢は実際に比較された製品名に絞る |
失注時の入力を仕組み化する
取引ステージを失注へ移動するときに、失注理由を必須入力として設定します。営業担当者へ入力を依頼するだけではなく、日常の操作の中で入力が完了するように設計することがポイントです。
入力後の確認方法も決めます。マネージャーが定期的に内容を確認し、分類と補足メモが一致しない案件や、判断が曖昧な案件を見直します。
ただし、項目の必須化だけでは正しい分類を担保できません。選択肢の定義が理解されていなければ、入力を終えることが目的になります。
営業会議や失注レビューで具体的な案件を確認し、判断基準を揃える運用も必要です。
「失注」ステージの必須項目は、次の手順で設定します（出典：Set up and customize your deal pipelines）。
- 設定（歯車アイコン）＞ データ管理 ＞ オブジェクト ＞ 取引 を開き、「パイプライン」タブで対象のパイプラインを選びます
- 「失注」ステージの行で「条件付きロジックのルール」列にカーソルを合わせ、「ルールを追加」を選びます
- 「依存プロパティ」で「プロパティを追加」を選び、失注理由（大分類）・失注補足メモを指定して「Required」をオンにし、「ロジックを保存」します
- テスト用の取引を「失注」へ移し、値を入れるまで進めないことを確認します。この設定は手動のレコード作成やステージ移動に適用されるため、フォームや連携経由で取引が作られる場合は、別途ワークフローで入力を確認します
運用開始後の最初の1か月は、「その他」の件数と補足メモを週次で確認し、選択肢を足すか定義を直すかを決めます。週次の見直しの型は、週次パイプラインレビューとデータ品質ダッシュボードの作り方が参考になります。
取引ボードで商談の現在地を確認する
HubSpotの取引ボードでは、取引をステージごとのカードとして確認できます。失注分析では、カードを移動する運用と、移動時に必要な情報の入力を結び付けます。
以下の画面は、初回訪問、意思決定者、見込み、見積提示、受注内示といった列に取引カードを配置したHubSpotの取引ボードです。
ボードを見れば、案件がどの段階に集まっているかを把握しやすくなります。
ただし、カードの配置だけでは失注原因はわかりません。各ステージの定義と、失注へ移動するときの入力ルールを組み合わせる必要があります。
ダッシュボードから改善アクションを決める方法
失注データは、集めるだけでは営業活動を変えません。ダッシュボードやレポートで傾向を確認し、改善アクション、担当部門、確認方法まで決める必要があります。
レポートを増やすこと自体を目的にせず、会議で判断に使うものへ絞ることをおすすめします。
失注分析で確認するレポート
| レポート | 表示形式 | 確認する内容 |
|---|---|---|
| 失注理由の分布 | 円グラフ | どの理由が多いか |
| 失注件数や金額の推移 | 折れ線グラフ | 失注傾向がどのように変化したか |
| 営業担当者別の失注傾向 | 横棒グラフ | 担当者ごとに異なる課題があるか |
| 競合別の失注状況 | バーチャート | 競合対策を検討すべき領域はどこか |
| ステージ別の離脱状況 | ファネルチャート | パイプラインのどこに停滞があるか |
| 失注理由と商材の関係 | ピボットテーブル | 商材ごとに異なる課題があるか |
すべてのレポートを同時に作る必要はありません。まず失注理由の分布とステージ別の離脱状況を確認し、判断に必要な切り口が見つかった段階で商材や担当者との掛け合わせを追加します。
集計の定義は、先にそろえておきます。同じ「受注率」でも、数え方によって数値が変わるためです。
| 指標 | 計算の例 | 決めておくこと |
|---|---|---|
| 受注率（件数） | 受注件数 ÷（受注件数 ＋ 失注件数） | 対象期間は、取引の作成日かクローズ日か。保留中の取引を含めるか |
| 受注率（金額） | 受注金額 ÷（受注金額 ＋ 失注金額） | 金額が未入力の取引の扱い。見積の改定をどう数えるか |
| ステージ別の通過率 | 次のステージへ進んだ件数 ÷ そのステージに入った件数 | ステージ定義が担当者間でそろっているか |
| 失注理由の構成比 | 理由別の失注件数 ÷ 失注件数の合計 | 「その他」の比率。月ごとの件数が少ない場合は、期間をまとめて見る |
外部の平均値や業界の目安は、商材・価格帯・検討期間によって大きく異なります。他社の数値を目標にせず、自社の過去の数値を基準にして、改善施策の前後で同じ定義のまま比べてください。
HubSpotでの作り方は次のとおりです。
- Reporting（レポート）から Reports を開き、取引をデータソースにしたカスタムレポートを作成します。カスタムレポートの作成には、レポートの「Create/own」と「Edit」の権限が必要で、対象製品のProfessionalまたはEnterpriseが前提です（出典：Create custom reports with the custom report builder）
- 取引のステージが「失注」のものに絞り、失注理由（大分類）別の件数を円（ドーナツ）チャートで、直前ステージ別の件数を棒グラフで作ります
- Reporting から Dashboards を開き、「Create dashboard」で「失注分析」ダッシュボードを作ってレポートを追加します。作成時のアクセス権は「Private to owner」か「Everyone」から選べます（出典：How to Create, Clone, Delete, and Manage Dashboards in HubSpot）
- 営業会議の議題に、このダッシュボードの確認と、次回までの改善アクションを入れます
カスタムレポートは作成できる数が契約によって異なるため、会議で使わないレポートは整理してください。
失注理由と改善アクションを対応させる
| 失注理由の傾向 | 改善アクションの候補 | 関係する部門 |
|---|---|---|
| 価格・予算 | 価格体系、対象顧客、価値の伝え方を見直す | 経営、マーケティング、営業 |
| 競合 | 比較資料、差別化ポイント、提案対象を整理する | マーケティング、営業 |
| 製品・機能 | 要望の共通性を確認し、連携や提案方法を検討する | プロダクト、営業 |
| タイミング | 情報提供と掘り起こしの流れを見直す | マーケティング、インサイドセールス |
| プロセス・自社要因 | ヒアリング、提案、フォローのルールを見直す | 営業 |
失注理由から改善施策を決める際は、表面的な分類だけで結論を出さないことが大切です。価格による失注が多くても、背景にはターゲットのずれや価値説明の不足があるかもしれません。
補足メモや商談履歴を確認し、共通する背景を整理してから施策を選びます。分析結果と現場の会話を組み合わせることで、実行可能な改善案へつなげやすくなります。
会議を報告の場で終わらせない
営業会議でレポートを共有しても、「価格理由が多かった」という確認だけで終われば、次の商談は変わりません。会議では、次の項目を決めます。
- 見直す対象
- 担当する部門
- 実施内容
- 次回確認する指標
営業だけで解決できない失注理由は、関係部門へ共有します。改善主体は、例えば次のように明確にします。
- 製品や機能に関する傾向 ── プロダクト
- タイミングや情報不足 ── マーケティング
- 提案やフォロー ── 営業
CRMのダッシュボードは、会議資料を作るためだけの機能ではありません。共通のデータを見ながら、部門ごとの行動をそろえるための基盤として活用します。
失注案件を掘り起こしへつなげる方法
失注した案件の中には、将来も対象にならない案件と、状況が変われば再検討される案件があります。両者を同じように扱うと、見込みのない案件への連絡が増える一方で、再検討の機会を逃す可能性があります。
失注理由を使って対象を分け、ライフサイクルステージとワークフローをつなぐことで、失注後の対応を整理できます。
掘り起こし対象を失注理由で分ける
失注した案件は、理由によって次の対応が異なります。
- タイミングや予算の都合で検討が止まった案件 ── 再検討の余地があるケースです
- 対象条件が合わない、要件を満たせないといった案件 ── 同じ内容での継続的な連絡が適さないことがあります
失注時には、理由だけでなく、再検討の可能性や連絡時に確認すべき条件も残します。営業担当者が変わっても、過去の経緯を確認して対応できる状態を作ります。
掘り起こし対象の判断基準を共通化すると、担当者の記憶に頼らず案件を管理できます。これは失注分析をナーチャリング全体へ接続するための重要な設計です。
HubSpotでの設定例を示します。取引ベースのワークフローで、失注理由が「タイミング」の取引だけを対象にします（出典：Create workflows、Choose your workflow actions）。ワークフローは、対象製品のProfessionalまたはEnterpriseが必要です。
- Automation ＞ Workflows で「Create workflow」＞「From scratch」を選び、オブジェクトタイプを「取引」にします
- 登録トリガーを「取引ステージが失注」かつ「失注理由（大分類）がタイミング」にします
- アクション「Delay」で、日付プロパティ「再検討可能時期」まで待機します
- アクション「Create task」（CRM actions）で、担当営業に「再検討状況の確認」のタスクを作成します。関連コンタクトの「再アプローチ対象」プロパティを「はい」にしたい場合は、「Edit record」で関連付けられたレコードのプロパティを編集できます
- 「Review and publish」で、過去の失注分まで一斉に登録するかを選びます。過去分は件数と内容を確認してから別途対応するため、通常は「No」を選びます
「再検討可能時期」が空の取引は、待機の対象になりません。失注時に日付を入れる運用か、空の場合の分岐を決めておいてください。
ライフサイクルステージとワークフローをつなぐ
失注案件を掘り起こし対象として管理する場合は、ライフサイクルステージと取引ステージの役割を分けます。取引ステージは商談の状態、ライフサイクルステージは見込み顧客との関係を表すものとして整理します。
掘り起こしの流れは、次のように整理できます。
- 失注理由に応じて掘り起こし対象へ移す
- ワークフローで情報提供や営業タスクの作成につなげる
- 反応があり、再び具体的な商談になった段階で、新しい取引レコードを作成して管理する
ライフサイクルステージの更新では、通常の進行方向と異なる動きが必要になる場合があります。一旦値をクリアしてから再設定する流れを検討します。既存の運用やレポートへの影響を確認してから設定してください。
自動化に任せすぎない
ワークフローを使えば、失注後のフォローやタスク作成を自動化できます。ただし、すべての失注案件に同じ連絡を送る設計は適しません。
次の点を踏まえて、自動化する対象と人が判断する対象を分けます。
- 失注理由
- 顧客との関係
- 過去のやり取り
特に顧客から明確な要望や懸念が示されている場合は、定型的な連絡よりも担当者が内容を確認して対応するほうが適しています。
自動化は判断そのものを置き換えるものではなく、対象の抽出、タスク作成、情報の受け渡しを支える仕組みとして使います。
失注分析で起きやすい失敗と限界
失注分析は、入力項目やダッシュボードを作れば完了する取り組みではありません。分類の偏り、入力基準のずれ、分析後の放置が起きると、データを蓄積しても改善に使えません。
運用開始後は、使われ方を確認しながら分類とルールを見直します。
「その他」に情報が集まる
既存の選択肢に当てはまらない案件が多いと、「その他」に情報が集中します。この状態では、同じ失注パターンが繰り返されていても集計から把握できません。
「その他」が選ばれた案件は、補足メモを定期的に確認します。共通する理由が見つかった場合は、次のいずれかで対応します。
- 新しい選択肢として追加する
- 既存の分類定義を調整する
ただし、一度しか現れていない理由まで選択肢にすると、入力項目が増え続けます。繰り返し発生しているか、改善判断に使えるかを基準に追加を検討します。
担当者によって分類が変わる
同じ状況でも、担当者によって「価格」「タイミング」「競合」の判断が分かれることがあります。これは担当者の問題ではなく、分類の定義が十分に共有されていない状態です。
- 各選択肢の整理 ── 該当する条件と判断に迷いやすいケースを整理します
- 迷う案件 ── マネージャーと確認し、判断結果を次の分類ルールへ反映します
入力ルールを文書化し、失注レビューで具体的な案件を確認することで、チームの判断基準をそろえやすくなります。
データだけでは真の理由を断定できない
CRMに記録される失注理由には、顧客から直接伝えられた内容だけでなく、営業担当者の推測が含まれる場合があります。
顧客側が選定理由を詳しく説明しないケースもあるため、入力内容を事実と推測に分けて扱う必要があります。
また、商談件数が少ない状態では、一部の案件が全体傾向のように見えることがあります。短い期間だけで結論を出さず、案件の内容を確認しながら判断します。
失注分析は、原因を機械的に断定するものではありません。改善仮説を作り、実行後の変化を確認するための材料として扱うことが現実的です。
自社の営業プロセスに合わない分類を使う
一般的な分類をそのまま導入しても、自社の商材や販売方法に合わなければ活用されません。検討期間、意思決定者、提供方法、商材の種類によって、重要な失注理由は変わります。
最初は代表的な分類から始め、実際の入力内容と会議での使われ方を確認します。判断に使われない項目は整理し、不足している観点は補います。
ただし、見直しのたびに分類名を大きく変えると、過去データとの比較が難しくなります。変更理由と影響を確認し、分析の連続性を保ちながら調整してください。
失注分析をCRMへ落とし込む考え方は「SFA導入で営業組織はどう変わる？導入メリットと成功のための5つの条件」でも解説しています。
このテーマに関連する記事はセールスマネジメントカテゴリで網羅的にまとめています。
StartLinkの進め方：分類の設計からレビューの定着まで
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援実績をもとに、失注分析を次の順で進めています。現状の整理・要件定義（過去の失注案件の表現を読み、共通の分類案を作る）、設計・構築（取引プロパティ、失注ステージの必須項目、レポートとダッシュボード）、データ移行（過去の失注理由を新しい分類へ対応付け）、テスト・検証（テスト取引で入力から集計まで通す）、定着・運用改善（週次レビューで分類を見直す）です。最初から全ステージを対象にせず、失注の入力と1枚のダッシュボードから始めるスモールスタートで広げ、準委任で伴走します。AI（BreezeやClaudeなど）を使って、補足メモの要約や分類候補の提示を業務設計に組み込む方法も扱っています。詳しくはHubSpot導入・構築支援とHubSpot×AIの支援をご覧ください。ワークフローの設計全般はHubSpotワークフロー設計ガイドが参考になります。
よくある質問
失注分析はどのような頻度で行えばよいですか？
営業会議などの定例の場で傾向を確認し、分類の見直しや部門横断の検討は一定期間のデータをまとめて行う方法があります。商談件数が少ない場合は、短期間の変化だけで結論を出さず、案件の内容を確認しながら判断してください。
重要なのは頻度そのものではなく、改善アクションを決め、次の会議で進捗と傾向を確認する流れを維持することです。
失注理由は営業担当者とマネージャーのどちらが入力しますか？
顧客とのやり取りを把握している営業担当者が一次情報を入力し、マネージャーが分類や内容をレビューする運用が考えられます。担当者だけで判断しにくい案件は、失注レビューで経緯を確認してから分類します。
入力者と確認者の役割を分けることで、現場の情報を残しながら、組織としての判断基準もそろえやすくなります。
失注理由は自由記述だけでも分析できますか？
自由記述だけでは表現の揺れが発生し、集計前に内容を読み直す作業が必要になります。集計に使う理由は選択式にし、顧客の発言や案件固有の事情は補足メモへ記録する方法が適しています。
選択式と自由記述の役割を分けることで、傾向の把握と案件の文脈確認を両立できます。
失注案件はすべて掘り起こし対象にすべきですか？
すべてを同じ対象にする必要はありません。タイミングや予算の事情で検討が止まった案件と、要件が合わない案件では、次の対応が異なります。
失注理由、再検討の可能性、顧客とのやり取りを確認し、自動フォローの対象、人が内容を確認する対象、継続対応しない対象に分けて運用します。
まとめ
失注分析は、失注理由を記録するだけではなく、営業プロセスと改善活動をつなぐ仕組みです。要点は次のとおりです。
- 取引ステージ、受注確度、ステージ定義、必須入力プロパティを一体として設計すると、失注した理由と発生した段階を組み合わせて確認できます
- 失注データは営業部門だけで閉じず、マーケティング、プロダクト、経営と共有します
- 価格、競合、製品や機能、タイミング、自社プロセスのどこに課題があるかを整理し、担当部門と改善アクションを決めることが重要です
まずは、現在の失注案件で使われている表現を確認し、重複する理由を共通の分類へまとめるところから始めてください。そのうえで、次の流れを進めます。
- 失注理由の選択式プロパティと補足メモを用意します
- 失注ステージへの移行時に入力する仕組みを設定します
- レポートで傾向を確認し、改善アクションと担当部門を決めます
運用が定着したら、失注理由に応じた掘り起こしや、商材・ステージとの掛け合わせへ分析を広げます。
小さく始め、実際に使われるデータを確認しながら調整することで、失注案件を組織の学習材料へ変えやすくなります。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
