BtoB失注分析のやり方|CRMの失注理由を営業・マーケティングの改善につなげる

失注した理由を営業に尋ねると、「価格が高かった」「競合に負けた」「予算がなかった」といった言葉が返ってきます。しかし、それだけでは次に何を変えるべきか分かりません。値下げするのか、比較資料を見直すのか、対象顧客を変えるのか。結論を急ぐ前に、顧客が何を言い、営業が何を観察し、何が未確認なのかを整理する必要があります。

この記事ではBtoBの失注分析を、CRMの記録から営業・マーケティングの具体的な改善へつなぐ方法を扱います。8つの分類例、記入テンプレート、架空事例、6つの実行手順を掲載します。これらは編集上の実務提案であり、一定の受注率向上を保証する手法ではありません。

まず「失注」と「保留」を区別する

見積もり後に返事がなくなった案件は、競合に決まったのでしょうか。予算承認が延期されたのか、社内で担当者が変わったのか、営業側で次の予定を把握できていないのか。終了状態が曖昧なまま理由を集計すると、結果を誤って解釈します。

  • 受注:発注や契約など、自社の受注定義を満たした案件。
  • 失注:今回の獲得機会が成立せず、終了が確認された案件。競合選択だけでなく導入中止を含み得る。
  • 保留・延期:顧客による再検討の予定などがあり、終了とは区別したい案件。
  • 進行中・状態不明:まだ終了が確定していない案件。単なる未返信を理由に失注と断定しない。

CRMのステージ設計は製品・企業ごとに異なります。例えばHubSpotの標準取引プロパティには取引ステージや「Closed lost reason(失注理由)」などがあり、ステージやクローズ日にも定義があります。まず自社のレコードが何を意味するかを確認します。

理由を集計する前に「根拠の強さ」を残す

「失注理由」欄だけを使うと、顧客の発言と営業の推測が同じ分類に混ざりがちです。例えば営業担当者が「競合より機能が弱かった」と判断していても、顧客が実際には移行負担を懸念していたかもしれません。理由を一つに決めることと、原因を検証できたことは同じではありません。

失注理由の8分類(実務用の例)

  • ① 現状維持・計画中止:導入計画が止まった、既存の運用を継続すると決めた。
  • ② 予算・投資対効果:予算枠、費用見積もり、効果の説明が合わなかった。
  • ③ 機能・要件:必須の機能、性能、システム連携が条件に合わなかった。
  • ④ セキュリティ・法務・運用:審査、契約、移行体制、運用への懸念が残った。
  • ⑤ 競合・代替手段:他社製品や内製を選択した。どの点で選ばれたかは別に記録する。
  • ⑥ 意思決定・合意形成:利用部門、購買、決裁者などの合意が得られなかった。
  • ⑦ 時期・体制:導入タイミング、人員不足、他案件の優先などが影響した。
  • ⑧ 未確認:理由を聞けていない、説明が矛盾する、担当者の推測しかない。

これはHubSpotやSalesforceの標準分類を写したものではありません。自社の事業特性に応じて見直すための出発点です。「未確認」は都合の悪い空欄ではなく、今は断定できないという情報として残してください。理由が複数ある場合は、主分類と補足理由を別に記録し、集計方式を明示します。

分類のほかに「誰が言ったか」を記録する

  • 顧客の発言:顧客がそう説明したことは確認できている。本人の説明が唯一の原因とは限らない。
  • 行動・記録:稟議の結果、要件表、商談履歴などを確認できる。記録そのものの欠損にも注意する。
  • 営業・マーケティングの仮説:観察から推測した理由。確認できるまでは「仮説」と表記する。
  • 未確認:回答が得られない、情報が不足する、複数の説明が競合している。

CRMに残す7つの項目

入力する欄をむやみに増やすと負担になるため、まず既存の商談レコードと重複しない最小項目を決めます。以下は会議で実際に使えることを意図した記録様式です。

  1. 終了状態と確認日:受注/失注/保留など。いつ誰が確認したか。
  2. 案件の属性:商材、対象顧客、案件規模、どの商談段階まで進んだか。
  3. 主な分類:失注理由の8分類から選択。必要なら補助理由を追加。
  4. 根拠の種類:顧客本人の説明/確認できる記録/社内の推測/未確認。
  5. 具体的な情報:発言の要約や要件上の不足。社内ルールに従う範囲で参照先を記録。
  6. 反例・未確認点:他に考えられる原因、まだ聞けていない関係者。
  7. 次の判断:追加調査・変更する施策・担当者・見直す日付。変更しない判断も残す。

記入例:移行負担で止まった架空案件

結果:顧客が今期の導入中止を確認したため失注
主分類:現状維持・計画中止
顧客の説明:「移行を担当できる人がいない」
営業側の仮説:導入作業の説明が足りなかった可能性。ただし未確認
次の調査:同様の案件で移行負担がどう説明されているかを確認
改善候補:既存の導入資料に、役割分担・必要な準備が記載されているか点検

これは実在の取引ではありません。この記録だけから「資料を作れば受注できた」とは言えません。重要なのは、観察したことと、次に検証することを切り分けることです。

失注データを改善に変える6つの手順

1. 分析する期間と母集団を定義する

「直近四半期に終了した新規案件」など、対象期間・商材・営業段階を先に決めます。進行中案件を失注率の分母に混ぜないようにします。例えば終了済み案件の受注率なら、受注件数 ÷(受注件数+失注件数)という定義が考えられますが、保留・再オープン・再受注の扱いはあらかじめ決めてください。

集計日付にも注意が必要です。HubSpotのクローズ日プロパティの説明では、ステージ変更によって日付が設定・更新される場合があります。集計前に自社の設定と履歴を確認し、違う定義の日付を混ぜないようにします。

2. 未確認の割合を最初に見る

失注理由を円グラフにする前に、未入力、顧客確認済み、営業の仮説のみ、の件数を確かめます。空欄を都合の良い理由へ割り振ると、改善施策も根拠のないものになります。

3. 件数と金額、どこで止まったかを分ける

多く失注した理由が、失注金額の大きな理由と一致するとは限りません。初回商談で対象外と分かった案件と、稟議の最終段階まで進んだ案件を同じ「機能不足」にまとめても、次の打ち手を決めにくいでしょう。商材、顧客規模、商談段階も分けて見ます。

HubSpotの公式セールスレポート解説には、失注理由を取引担当者・チーム別に扱うレポートのほか、ファネルや受注・失注を分析するレポートがあります。ただし、利用可能なレポートや機能は契約内容に依存します。

4. 受注案件や保留案件と照合する

「失注案件はセキュリティ審査で止まる」と分かったら、受注案件も同じ審査を経験していないか確認します。失注案件に頻出する情報が、そのまま失注を引き起こした原因とは限りません。比較対象の業種・案件規模・検討時期が違えば、その違いも記録します。

5. 分からない点を顧客の言葉に戻す

確認できる関係性があるなら、失注・保留した顧客へ中立的に聞き取ることを検討します。「当社の価格が高かったからですか」ではなく、「最終的な判断では何と比較し、どの条件が決め手になりましたか」と聞く方が、結論を先取りしません。聞き方は顧客インタビューの実務ガイドも参照してください。

6. 次の行動と、仮説を見直す条件を決める

「失注の多い理由が分かった」だけでは分析は終わりません。対応できる問題なのか、製品・営業・マーケティングのどこに手を入れるべきかを検討します。決めた施策、責任者、確認日、改善仮説が外れたと判断する条件を残します。十分な件数がないときは追加観察にとどめる選択もあります。

失注理由から次の施策を考える

  • 予算・価格:値引きの前に、総費用・期待効果・投資承認の条件を確認する。
  • 機能・要件:製品の不足と説明不足を分け、必要なら開発やSEに引き継ぐ。
  • セキュリティ・運用:審査を通すための情報が早く提供できたかを点検する。
  • 合意形成:利用者・情報システム部門・決裁者それぞれが必要とした情報を確かめる。
  • 現状維持:競合に負けたと決めつけず、導入自体を見送った理由を考える。現状維持を扱う関連記事も参考に。

30分のレビュー会議例

まず少数の案件で運用が回るかを試すための編集上の会議例です。「30分が最適」と実証されたルールではありません。

  1. 5分:対象の失注案件と「未確認」の件数を共有する。
  2. 10分:事例を2〜3件選び、顧客の発言と社内の解釈を切り分ける。
  3. 10分:受注案件も見て原因仮説と改善候補を検討する。
  4. 5分:担当者・再確認日・保留事項を決める。

担当者の責任追及の場にしないことも大切です。「営業が負けた理由」ではなく「今回の顧客判断から何を学べるか」を共有する場にします。変更する対象が製品・契約・運用なら所管部門と協議します。

よくある間違いと限界

  • 未返信を失注扱いする:状態が未確認なら未確認と残す。
  • 「価格」というラベルを真因とみなす:顧客の説明と別の可能性を区別する。
  • 失注案件だけを見る:受注案件でも生じていた課題かを確認する。
  • 小さい母数で全体に一般化する:少数の例は仮説づくりに使う。
  • 商談履歴を外部AIへ無断投入する:個人情報、機密、契約、保存期間、権限を確認する。

CRMがなくても始められるか

必要な項目を定義できるなら、管理権限を設定したスプレッドシートから始めることもできます。ただし、個人・顧客情報を扱う責任は変わりません。最初に詳細なデータ分析環境を作るより、少数の案件で記録と判断がつながるかを確かめる方が合理的な場合もあります。

まとめ:理由を埋めるより、次の判断を改善する

失注分析で大切なのは、すべての案件を一つの理由へ押し込むことではありません。結果、顧客の説明、確認できる記録、社内の仮説、未確認事項を分け、何を変えるかを決めることです。まずは直近の終了案件を数件選び、記録を実際に試してください。

関連して、定性データと定量データの使い分け、営業・マーケティング連携、KPI設計も読み進めると、失注を改善へ戻す考え方がつながります。全体像はBtoBマーケティング総合ガイドへ。

参考資料と位置づけ

以下は実際のCRM項目・レポート機能に関する提供元の公式資料です。本文の分類、テンプレート、会議の進め方は編集上の提案であり、ベンダー公認の標準モデルや成果保証ではありません。

次の問いを探す

言葉・人物・作品・仕事など、気になるキーワードからほかの記事へ。

編集方針と運営者について →