商談の失注理由はどう記録・分析する？料金・機能・実績・比較情報をサイト改善へ戻す方法

監修: 菊地 将（リブランディング株式会社）

商談で「価格が高かった」「競合に負けた」と聞いても、そのままではWebサイトのどこを直すべきか決まりません。必要なのは、失注理由を集めることではなく、顧客が実際に述べた内容と営業側の解釈を分け、比較できる形で残し、改善対象までつなげることです。

この記事では、料金・機能・実績・対応範囲・稟議などの失注理由を記録する項目、分類方法、集計単位、Web改善への変換方法を整理します。読後には、失注データから「どのページを、何から直すか」まで決められる状態を目指します。

失注分析の結論は「理由の件数」ではなく「次に直す場所」まで決めること

失注分析は、受注できなかった理由を数えるだけでは不十分です。分析の出口を「次の商談で変えること」と「Webで補強する情報」に置くと、営業とマーケティングで同じデータを使いやすくなります。

たとえば「価格」が10件あっても、実態は同じとは限りません。「予算そのものが足りない」「競合より高い」「価格に含まれる範囲が伝わっていない」「費用対効果を社内で説明できない」では、必要な対策が異なります。

まずは失注理由を、次の4層に分けます。

この4層を混ぜなければ、「顧客が言ったこと」と「社内でそう考えていること」を別々に集計できます。

失注理由は、顧客が実際に述べた内容と営業側の解釈を分けて記録すると、後から同じ条件で比較しやすくなります。

まず失注理由を「顧客発言」と「営業側の推測」に分けて記録する

CRMやSFAには、失注理由を構造化して残す仕組みがあります。Salesforceの公式学習コンテンツでは、商談をClosed Lostにした際に「Lost Reason」を選択式で必須入力にする設定例が示されています。Microsoft Dynamics 365 Salesでも、商談をLostで閉じる際に競合、クローズ日、説明などを記録できます。HubSpotには「Closed lost reason」を使って失注件数を集計するレポートがあります。

重要なのは、選択肢を作ること自体ではありません。選択式は集計しやすい一方、理由の背景までは残りにくいため、選択式と自由記述を組み合わせます。

最低限そろえたい失注記録の項目

以下を同じフォーマットで残すと、後から比較しやすくなります。

顧客発言が取れなかった場合は、営業担当者の推測で空欄を埋めず「未確認」と残します。未確認が多い分類は、分析結果ではなく「次の商談で聞くべき質問」が不足しているサインとして扱えます。

失注理由は8分類程度から始め、Webで直せるものと直せないものを分ける

分類は細かすぎると入力が続かず、粗すぎると改善策が決まりません。最初は、改善先が変わる単位で分けるのが実務的です。

ここで大切なのは、すべてをWeb改善へ押し込まないことです。たとえば「決裁者の異動」「予算凍結」「事業方針変更」は、Webだけでは解決できません。

一方、「対応範囲が伝わっていない」「同業実績が見つからない」「料金に含まれる内容が分からない」は、サイト上の情報設計で改善余地を確認できます。

同じ「価格失注」でも4つに分けると改善先が変わる

「価格」は、失注理由として集計しやすい反面、そのままでは打ち手が粗くなります。少なくとも次の4つは分けて確認します。

値下げが必要なのは、この中の一部です。「高い」と言われた案件をすべて値下げ課題にすると、本来は説明不足だった案件まで料金設計の問題として扱ってしまいます。

失注データをWeb改善へ戻す5ステップ

失注理由をサイト改善へつなげるときは、案件単位の感想ではなく、同じ条件の商談をまとめて見ます。

失注理由は記録して終わりではなく、改善対象を決め、変更後も同じ分類で再確認するところまで一続きで運用します。

STEP1｜失注直後に事実を記録する

記憶が薄れる前に、顧客発言、確認できた事実、営業側の仮説、未確認事項を分けて残します。後から月末にまとめて入力すると、短い理由だけが残りやすくなります。

STEP2｜同じ条件の商談だけで集計する

新規商談と既存顧客、低単価と高単価、初回商談後と最終提案後では、失注理由の意味が違います。商材、顧客規模、流入経路、失注フェーズ、対象期間などをそろえます。

STEP3｜理由を「情報不足」と「商品・営業課題」に分ける

たとえば「実績不足」という記録があっても、本当に実績がない場合と、実績はあるがサイトで見つけられなかった場合では改善先が違います。

判断するときは、「実態が不足しているのか」「情報はあるが伝わっていないのか」を分けます。前者は商品・営業・事業側の課題、後者はWeb改善候補です。

同じ失注理由でも、商品やサービス自体の不足と、Web上の情報不足では改善先が異なります。

STEP4｜失注理由を具体的なページへ対応付ける

「サイトを改善する」ではなく、ページ単位まで落とします。

• 料金の内訳が分からない → 料金ページ
• 自社と同じ業界の実績が見つからない → 導入事例一覧・業界別事例
• 導入後の作業範囲が分からない → サービス詳細・進行フロー
• 稟議で必要な情報がない → セキュリティ、契約、導入手順、FAQ
• 他社との違いが分からない → 比較記事・選び方記事・サービス説明

1つの失注理由に対して、改善ページを1つに決める必要はありません。ただし、最初の改善では責任者を決めるため、主な改善対象を1つ置くと進めやすくなります。

STEP5｜改善後も同じ分類で再集計する

Web改善を行ったら、ページ公開で終了せず、同じ失注分類で再集計します。

Google Analytics 4では、フォーム送信などビジネス上重要な行動をキーイベントとして計測できます。Google Search Consoleでは、検索クエリやページごとのクリック、表示回数、CTRなどを確認できます。改善前後のWeb行動と失注理由の推移を合わせて見ることで、変更後に何が動いたかを確認できます。

ただし、改善前後の数字が動いたことだけで因果関係を断定しないことも重要です。営業担当、案件構成、広告、季節性などが同時に変わるため、条件をそろえながら継続して比較します。

Web改善の優先順位は「件数」だけで決めない

件数が多い失注理由から着手すると、直しやすさや売上影響を見落とします。実務では、次の4軸で優先順位を付けると整理しやすくなります。

1. 発生件数
2. 商談金額への影響
3. 根拠の確かさ
4. Webで改善できる度合い

失注件数だけでなく、理由の確かさ、Webで改善できるか、商談金額への影響も合わせて改善順を判断します。

各軸を1〜3点で評価し、合計点だけを見るのではなく、「高い項目が複数あるもの」を優先候補にします。この1〜3点は統計指標ではなく、自社で改善順を決めるための実務上の評価尺度です。

たとえば、失注件数は少なくても、大型案件で繰り返し「導入実績が確認できない」と言われているなら、事例ページの改善優先度は高くなります。

逆に、件数が多くても「顧客都合の延期」が中心なら、サイト改修より再提案時期の管理を優先した方がよい場合があります。

失注理由からWeb改善へつなげる記録テンプレート

最初から複雑なダッシュボードを作る必要はありません。スプレッドシートでもCRMでも、以下の形で記録できれば分析を始められます。

この表で重要なのは、「失注理由」と「Web改善候補」を別列にすることです。失注理由そのものをページ名へ置き換えると、営業の事実とマーケティング側の改善仮説が混ざります。

失注分析でよくある失敗

自由記述だけで集める

営業担当ごとに表現が変わり、同じ理由を集計しにくくなります。Salesforceの公式学習コンテンツでも、同じ対象を異なる文字列で入力すると分析しづらくなるため、事前定義した選択肢を使う考え方が示されています。

主分類は選択式、背景は自由記述に分けると扱いやすくなります。

営業担当者の推測を顧客理由として扱う

「価格で負けたと思う」と「顧客が価格を理由に挙げた」は別データです。情報源を残し、確度が違うものを同じ件数として扱わないようにします。

1件の大型失注だけで全面改修する

重要案件の失注は確認価値がありますが、1件だけで全体傾向とは判断できません。まず個別案件の改善候補として扱い、他案件でも同じ理由が出ているか確認します。

Webで解決できない理由までサイト課題にする

予算凍結、組織変更、事業撤退などは、サイト改善では解決できないことがあります。Webで変えられるのは「情報がない」「見つけにくい」「比較しにくい」「社内説明に使いにくい」といった情報面の課題です。

よくある質問

失注理由は選択式と自由記述のどちらがよいですか

両方を使います。選択式は集計、自由記述は背景確認に向いています。

失注理由は1つに絞るべきですか

集計用の主因は1つ決め、必要なら補足要因を追加する方法が扱いやすいです。主因を判断できない場合は、無理に確定せず未確認事項を残します。

何件たまったらWeb改善を始めるべきですか

一律の件数基準はありません。高額案件で具体的な顧客発言がある場合は、1件でもページを確認する価値があります。一方、全面改修の判断は、複数案件で同じ傾向が出ているかを確認してから行う方が安全です。

顧客が失注理由を教えてくれない場合はどうしますか

「未確認」と記録します。推測で埋めず、商談履歴や提案内容など確認できる事実と、営業側の仮説を分けて残します。

未確認が多い項目は、次回の商談設計や失注後ヒアリングの質問改善へ戻します。

受注案件も記録した方がよいですか

可能であれば、比較条件や選定理由を受注案件にも残します。失注案件だけを見ると、その特徴が本当に失注特有なのか判断しにくいためです。

たとえば「決裁者と会えなかった」が失注案件に多くても、受注案件でも同程度なら、別の要因を優先して確認する必要があります。

失注理由の記録・分類テンプレートを使って運用を始める

失注分析を営業の振り返りだけで終わらせず、Web改善へ戻すには、案件ごとの記録項目をそろえることが出発点です。

顧客発言、営業側の仮説、主分類、比較条件、Web改善候補を同じフォーマットで残すと、月次や四半期の振り返りで改善優先度を決めやすくなります。

自社用の記録フォーマットを作る際は、資料ダウンロードページのテンプレートもあわせて活用してください。

まとめ

失注理由は、「価格」「競合」「タイミング」と記録するだけでは、Web改善の優先順位まで決まりません。

実務では、顧客が実際に述べた内容、確認できた事実、営業側の仮説、未確認事項を分け、料金・機能・実績・対応範囲・比較・稟議などへ分類します。そのうえで、Webで改善できる理由だけを料金ページ、事例、サービス詳細、FAQ、比較コンテンツなどへ対応付けます。

最後に、改善後も同じ分類で失注理由を取り続けます。失注データを「営業の反省材料」ではなく、「何を直し、次に何を確かめるかを決める共通データ」にすると、営業とマーケティングの改善をつなげやすくなります。

失注データ以外の指標も含めてサイト改善のPDCAを見直したい場合は、オウンドメディアの効果測定・改善の全体像を確認してください。

失注理由の記録に加えて、受注につながった商談側のデータも合わせて見たい場合は、記事別の商談・受注貢献をCRMで測る方法が参考になります。

参考文献・データ元

‹ 親記事: オウンドメディアの効果測定・改善とは？見るべき指標・使うツール・PDCAの回し方の全体像