失注分析の設計と活用｜商談データから受注率を改善するフレームワーク

「失注した案件をそのまま放置してしまっている」「なぜ負けたのか、営業担当者の感覚的な報告でしか把握できない」「受注率を上げろと言われるが、どこを改善すればいいかわからない」——失注案件を「負けた案件」として片付けてしまっている企業は少なくありません。

失注分析とは、失注した商談データを体系的に分類・集計し、敗因のパターンを可視化して、営業プロセス・提案内容・商材開発の改善につなげるフレームワークです。受注率の改善は、新しい営業スキルを身につけることよりも、「なぜ負けているか」を正確に理解して対策を打つほうが、はるかに効率的です。

本記事では、失注分析を組織的に設計・運用するためのフレームワークと、CRM/HubSpotでの具体的な実装方法を解説します。

この記事でわかること

• 失注分析が受注率改善に直結する理由
• 失注理由の分類フレームワーク（5カテゴリ）
• CRM/HubSpotでの失注データ収集・可視化設計
• 失注分析から改善アクションにつなげるプロセス
• 「失注→掘り起こし」のナーチャリングサイクル設計
• よくある失敗パターンと回避策

失注分析とは？

失注分析とは、商談パイプラインで失注（クローズロスト）となった案件のデータを体系的に分類・集計し、敗因のパターンを特定して改善策を導出するプロセスです。個別の商談の「なぜ負けたか」ではなく、組織全体の失注パターンを構造的に把握し、再現性のある改善につなげることが目的です。

なぜ失注分析が重要なのか

受注率1%の改善は、リード数の増加よりインパクトが大きい

例えば、月間100件の商談があり、受注率が20%の場合、月間受注は20件です。リード数を10%増やして110件にしても、受注は22件（+2件）に過ぎません。一方、受注率を20%から25%に改善すれば、100件×25%=25件（+5件）。受注率5ポイントの改善は、リード数25%増加に相当します。

そして、受注率を改善するための最も直接的なアプローチが、「なぜ負けているか」を分析して対策を打つこと、つまり失注分析です。

営業とマーケの連携を強化するデータ

失注理由の中で「製品機能の不足」が多い場合、それはプロダクト開発チームへのフィードバックになります。「時期が合わなかった」が多い場合、マーケティング側のナーチャリングシナリオの見直しが必要かもしれません。「価格が高い」が多い場合、ターゲットセグメントの見直しや、料金プランの再設計が検討対象になります。

このように、失注分析は営業部門だけの話ではなく、マーケティング・プロダクト・経営を横断する全社的な改善ドライバーになります。「例えばプロダクトの製品開発とかに『こういう機能を入れてください』というのをマーケ側に共有しやすくなるので、営業とマーケの連携がしやすくなる」というのが、失注分析の副次的な効果です。

スプレッドシートでは構造的な分析ができない

失注理由をExcelで管理している場合、自由記述のテキストが多く、構造的な分析が困難です。「なんとなく価格が理由で負けている気がする」という感覚的な理解にとどまり、具体的なアクションにつながりません。CRM上で失注理由をカテゴリ分類して蓄積し、円グラフやバーチャートで可視化することで、初めてデータに基づいた改善が可能になります。

失注理由の分類フレームワーク

失注分析の精度は、失注理由の分類設計で決まります。ここが結構ミソになってくるポイントです。以下の5カテゴリで設計することを推奨します。

カテゴリ1：価格・予算

• 価格が予算を超えている
• 費用対効果が見合わないと判断された
• 予算が確保できなかった / 凍結された

カテゴリ2：競合

• 他社ツール/サービスを選定した
• 既存ツールの継続を決定した（リプレースしない判断）

カテゴリ3：製品・機能

• 必要な機能が不足している
• セキュリティ要件を満たさない
• 技術的な制約（連携先がない等）

カテゴリ4：タイミング

• 導入時期が合わなかった（来期以降に延期）
• 社内体制が整っていない
• 組織変更・人事異動による検討中断

カテゴリ5：プロセス・自社要因

• 提案内容が刺さらなかった
• フォローアップが不十分だった
• 意思決定者にリーチできなかった
• 自社の対応スピードが遅かった

CRMでの実装時には、これらをドロップダウンの選択式プロパティとして設定します。自由記述にすると集計ができなくなるため、必ず選択式（＋補足メモの自由記述欄）で設計することが重要です。

分類の粒度と数のバランス

失注理由の選択肢は、10〜15個程度が実務上のバランスです。少なすぎると分析の解像度が低く、多すぎると営業担当者が選択に迷って適当に選ぶようになります。まず上記5カテゴリを大分類として、その下に各2〜3個の小分類を設けるのが効果的です。

CRM/HubSpotでの実装設計

失注データ収集の仕組み化

HubSpotでの失注分析設計は、以下の3つのステップで実装します。

ステップ1：失注理由プロパティの作成

取引オブジェクトに「失注理由（大分類）」「失注理由（詳細）」「失注補足メモ」の3つのプロパティを作成します。大分類はドロップダウンで5カテゴリ、詳細は依存フィールド（大分類の選択に応じて表示される小分類）として設計します。

ステップ2：パイプラインルールでの必須化

取引ステージを「失注」に移動する際に、失注理由の入力を必須にするパイプラインルールを設定します。これが「仕組み」で解決する部分です。営業担当者に「失注理由を入れてね」とお願いするだけでは入力率は50%程度に留まりますが、必須化すれば100%のデータが蓄積されます。

ステップ3：ワークフローでの自動通知

失注ステージへの移行時に、営業マネージャーへSlack/メール通知を自動送信するワークフローを設定します。特に大型案件（例：取引金額500万円以上）の失注は、即座にマネージャーが状況を把握し、必要に応じて失注レビュー面談を設定できるようにします。

ダッシュボード・レポート設計

失注分析用のダッシュボードには、以下のレポートを含めると効果的です。

ダッシュボードは月次の営業会議で共有し、改善アクションの進捗を追跡する場として活用します。HubSpotではダッシュボードの定期配信機能を使って、毎週水曜の朝に自動送信する設定も可能です。

失注→掘り起こしのナーチャリングサイクル

失注分析のもうひとつの重要な活用が、「失注→掘り起こし」のナーチャリングサイクルです。失注した案件の中でも、「タイミングが合わなかった」「予算凍結だった」などの理由は、時間が経てば状況が変わる可能性があります。

HubSpotでは、以下のような設計で失注案件の掘り起こしを自動化できます。

1. 失注ステージに移行 → ライフサイクルステージを「失注掘り起こし」に変更
2. ワークフローで3ヶ月後に掘り起こし用メールを自動配信（3通のステップメール）
3. メール開封・リンククリックがあった場合、営業担当者にタスクを自動作成
4. 再商談化した場合、新しい取引レコードを作成し、ライフサイクルステージを更新

ライフサイクルステージの更新には注意が必要で、通常はステージの逆行ができないため、「一旦クリア→再設定」の2ステップでワークフローを組む必要があります。

失注分析から改善アクションへのつなぎ方

データを集めても、改善アクションにつながらなければ意味がありません。失注分析から改善を導く際のフレームワークは以下のとおりです。

重要なのは、失注分析の結果を「営業部門だけ」で閉じないことです。月次の経営会議やマーケ×営業の定例会議で共有し、部門横断で改善アクションを決定する運用を設計してください。

注意点・よくある失敗パターン

失敗1：失注理由が「その他」だらけ

選択肢に合わない失注理由が多い場合、「その他」が最多になってしまいます。これでは分析になりません。「その他」の割合が20%を超えたら、選択肢の見直しが必要というルールを設けましょう。自由記述の補足メモを定期的に確認し、新しいパターンを選択肢に追加する運用も重要です。

失敗2：失注理由の入力が営業担当者の「感覚」に依存

同じ案件でも、営業担当者によって「価格」と入力する人と「タイミング」と入力する人がいます。失注理由の定義と判断基準を明文化し、チーム内で認識を揃えることが前提です。判断に迷う場合は「マネージャーと失注レビュー面談で確認して入力する」というルールも有効です。

失敗3：分析はするがアクションを起こさない

月次の営業会議で失注レポートを見て「今月は価格が多かったね」で終わるケースが非常に多いです。分析結果に対して「誰が」「いつまでに」「何をするか」を決め、次回会議で進捗を確認するところまでを含めて「失注分析」と定義してください。

正直な限界

失注分析は、ある程度の商談数がないと統計的に有意な傾向が見えません。月間の失注件数が10件未満の場合は、3ヶ月〜6ヶ月分をまとめて分析するのが現実的です。また、真の失注理由は顧客側が教えてくれないケースも多く、CRMに入力される失注理由は「営業担当者の推測」が含まれる点は認識しておく必要があります。

まとめ

失注分析の設計と活用は、以下のステップで進めるのが効果的です。

1. 失注理由の分類設計：5カテゴリ×小分類で10〜15個の選択肢を設計
2. CRMでの入力必須化：パイプラインルールで失注ステージ移行時に入力を強制
3. ダッシュボードの構築：円グラフ・ファネル・ピボットで失注パターンを可視化
4. 改善アクションの決定：月次会議で部門横断のアクションプランを策定
5. 掘り起こしの自動化：失注→ナーチャリング→再商談化のワークフロー構築

まずは失注理由のドロップダウンプロパティを作成し、パイプラインルールで入力を必須化するところから始めてください。データが3ヶ月分蓄積されれば、最初の有意な分析が可能になります。受注率の改善は、「新しいスキルを覚える」よりも「なぜ負けているかを正確に理解する」ほうが近道です。

失注分析のHubSpotでの具体的な設定方法は「失注分析の進め方｜HubSpotで失注原因を特定し受注率を改善するデータ活用術」で詳しく解説しています。パイプライン設計の基本は「HubSpotパイプラインの設計方法｜取引ステージ・角度・必須プロパティの考え方を徹底解説」も参考になるかと思います。また、ナーチャリング全体のフロー設計については「HubSpotでナーチャリングを実践する方法」もあわせてご覧ください。

よくある質問（FAQ）

Q. 失注分析はどの程度の頻度で行うべきですか？

月次の営業会議で定点観測し、四半期に1回は深掘り分析を行うのが標準的です。月次では「失注理由の分布」と「前月との変化」を確認し、四半期では「セグメント別の掛け合わせ分析」や「改善施策の効果検証」まで踏み込みます。

Q. 失注理由は営業担当者が入力するのと、マネージャーが入力するのとどちらがよいですか？

基本は営業担当者が入力し、マネージャーが月次でレビューする体制を推奨します。営業担当者は顧客との接点を持っているため、一次情報として最も正確です。ただし、大型案件の失注については、マネージャーと失注レビュー面談を実施し、客観的な評価を加えた上で確定するのが望ましいです。

Q. 失注した顧客への掘り起こしは、どのタイミングが適切ですか？

失注理由によって異なります。「タイミングが合わなかった」場合は3ヶ月後、「予算凍結」の場合は新年度のタイミング、「競合を選んだ」場合は6〜12ヶ月後（契約更新時期の前）が目安です。HubSpotのワークフローで失注理由に応じた遅延設定をしておくと、最適なタイミングで自動的にフォローアップが開始されます。

Q. 失注率の適正値はどの程度ですか？

BtoB営業の場合、パイプライン全体の受注率は20〜30%程度が一般的です（つまり失注率は70〜80%）。重要なのは絶対値よりも「改善トレンド」です。3ヶ月前と比較して失注率が下がっているか、特定の失注理由が減っているかをモニタリングしてください。

Q. Salesforceでも同じフレームワークで失注分析は可能ですか？

はい。失注理由の5カテゴリ分類、パイプラインルールでの入力必須化、ダッシュボードでの可視化という設計はCRMの種類に依存しません。Salesforceの場合は、商談オブジェクトの「クローズ時の項目」や「バリデーションルール」で同等の実装が可能です。