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

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

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

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

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

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

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

そこで、失注理由を次の4層に分けて残します。表の「例」は、各層に何を書くかを示したものです。

層	残す内容	例
顧客発言	顧客が実際に述べた判断理由	「他社は導入支援まで料金に含まれていた」
確認事実	メール、見積書、商談履歴などで確認できる事実	自社の料金ページに支援範囲の記載がない
営業側の解釈	営業担当者が考えた原因仮説	料金差より、対応範囲の見えにくさが影響した可能性
未確認	聞けていない、判断できない事項	最終決裁者がどこを比較したか不明

この4層を混ぜなければ、「顧客が言ったこと」と「社内でそう考えていること」を別々に集計できます。表の例のように、顧客発言と確認事実を先に残し、営業側の解釈は別の欄に分けておくと、解釈を事実と取り違えずに改善先を考えられます。

4層に分けて記録しておくと、後から同じ条件で失注理由を比較できます。次の節では、この4層を日々の記録項目に落とし込みます。

失注理由は、まず「顧客発言」と「営業側の解釈」に分けて記録する

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

ただし、選択肢を作れば分析に使える記録が残る、というわけではありません。選択式は集計しやすい一方で、理由の背景までは残りにくいためです。そのため、選択式と自由記述を組み合わせます。

なお、前の節の4層にある「営業側の解釈」は、記録項目では「営業側の仮説」という名前で残します。同じものを指しています。

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

次の項目を同じフォーマットで残すと、後から商談を比較しやすくなります。「情報源」の欄では、顧客発言なのか、メールや見積書で確認できた事実なのか、営業担当者の推測なのかを区別します。

項目	記録内容
商談の基本条件	商材、顧客規模、業種、商談金額、流入経路
失注日・失注フェーズ	いつ、どの段階で終了したか
主な失注理由	料金、機能、実績、対応範囲、競合、稟議、時期など
顧客発言	顧客が伝えた内容を要約
情報源	顧客発言、メール、見積書、営業推測など
競合・代替手段	他社、内製、延期、見送りなど
比較された条件	料金、機能、支援範囲、実績、契約条件など
営業側の仮説	なぜその結果になったと考えるか
未確認事項	判断材料が不足している点
Web改善候補	料金ページ、事例、サービスページ、FAQなど
次回確認日	改善後に再集計する日

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

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

分類は、細かすぎると入力が続かず、粗すぎると改善策が決まりません。そこで最初は、改善先が変わる単位で分けるのが実務的です。次の表は、8つの主分類と、それぞれをWebのどこで確認・改善しやすいかを対応付けたものです。

主分類	具体例	Webで確認・改善しやすい場所
料金・契約条件	高い、料金体系が分かりにくい、契約条件が合わない	料金ページ、料金FAQ、比較表
機能・仕様	必要機能がない、できることが分からない	サービスページ、機能一覧、FAQ
実績・信頼	同業実績が見えない、導入後が想像できない	導入事例、実績一覧、担当者情報
対応範囲・体制	どこまで任せられるか不明、サポート範囲が不明	サービス範囲、支援体制、進行フロー
比較・競合	他社との違いが分からない、比較軸で負けた	比較記事、選び方記事、サービス説明
稟議・決裁	社内説明に必要な材料が足りない	費用対効果、導入手順、セキュリティ、FAQ
時期・優先度	今期は見送り、予算時期が合わない	再検討用コンテンツ、メールでの継続接点
対象不適合・その他	規模・業種・要件が対象外	ターゲット、対象条件の明示

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

一方、「対応範囲が伝わっていない」「同業実績が見つからない」「料金に含まれる内容が分からない」は、サイト上の情報設計で改善余地を確認できます。分類したあとで「Webで直せるか」を見分ける方法は、後述のSTEP3で説明します。

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

「価格」は、失注理由として集計しやすい反面、そのままでは打ち手が粗くなります。そこで、少なくとも次の4つに分けて確認します。右列は、それぞれに対応する改善候補です。

価格の中身	顧客側で起きていること	主な改善候補
予算不足	そもそも予算枠に入らない	プラン設計、対象顧客の見直し
競合より高い	同条件だと認識され、金額差で比較された	比較条件、価格に含む範囲の明示
価値が伝わらない	得られる成果と費用が結びつかない	成果事例、導入効果、活用例
稟議が通らない	社内説明に必要な材料が足りない	費用対効果、導入手順、FAQ、資料

この表を見ると、「予算不足」は、プラン設計や対象顧客の見直しが中心になります。一方、「競合より高い」「価値が伝わらない」「稟議が通らない」は、価格に含む範囲、成果事例、費用対効果の説明といった、情報の出し方で改善できる余地があります。

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

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

失注理由をサイト改善へつなげるときは、案件ごとの感想ではなく、同じ条件の商談をまとめて見ます。次の5ステップで進めます。

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

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

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

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

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

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

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

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

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

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

「サイトを改善する」で終わらせず、ページ単位まで落とします。対応の例は次のとおりです。

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

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

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

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

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

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

Web改善の優先順位は、件数だけでなく4つの軸で決める

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

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

このうち「根拠の確かさ」は、その失注理由を顧客発言や見積書などでどこまで確認できているかを表します。後述するテンプレートの「根拠区分」の列に当たります。

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

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

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

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

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

最初から複雑なダッシュボードを作る必要はありません。スプレッドシートでもCRMでも、次の形で記録できれば分析を始められます。表の3行は、記入のイメージを示す例です。

商談ID	主分類	顧客発言	営業仮説	根拠区分	比較条件	Web改善候補	優先度	次回確認
例A	実績・信頼	同業界の導入例を確認できなかった	業界別事例が探しにくい	顧客発言あり	実績	事例一覧	高	翌月
例B	料金・条件	他社は支援範囲込みだった	料金差より範囲表現の差が大きい	顧客発言＋見積確認	料金・範囲	料金ページ	高	翌月
例C	稟議・決裁	社内説明で効果を示せなかった	稟議材料不足	顧客発言あり	効果・導入手順	導入事例・FAQ	中	四半期末

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

失注分析でよくある4つの失敗

失注分析では、次の4つの失敗が起こりがちです。

自由記述だけで集める

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

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

営業側の解釈を顧客の理由として扱う

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

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

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

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

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

よくある質問

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

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

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

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

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

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

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

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

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

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

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

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

まず記録項目をそろえて、失注分析の運用を始める

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

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

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

まとめ

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

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

失注データを「営業の反省材料」ではなく、「何を直し、次に何を確かめるかを決める共通データ」にすると、営業とマーケティングの改善をつなげやすくなります。まずは次の失注から、顧客発言と営業側の仮説を別の欄に分けて残しましょう。

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

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

参考文献・データ元

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

関連記事

• › オウンドメディア記事のリライト・統合・削除判断｜古い記事を棚卸しする基準
• › 記事別のCV貢献を測る方法｜直接CV・間接CV・閲覧経路から改善優先度を決める
• › オウンドメディアの記事制作コストとROIを測る方法｜原価台帳・更新費・投資判断まで
• › オウンドメディアのテーマ不足を確認｜検索意図・記事役割を整理
• › 記事別の商談・受注貢献をCRMで測る方法｜CV後の商談化率・受注率・リード品質を評価
• › 営業が記事を商談で使った効果を測る方法｜SFAで送付・閲覧・案件進行を追う
• › 記事再配信の効果測定方法｜SNS・メルマガ・営業資料を共通KPIで比較
• › 記事の読了・スクロール・内部リンククリックをGA4で測る方法｜エンゲージメント指標の実装と改善判断
• › ホワイトペーパーをダウンロードしても商談に進まない理由を調査する方法｜期待差・社内共有・追加検索・比較を可視化
• › GA4とは？導入手順と最初に見るレポート・データ保持期間

関連テーマ

AIO SEO MEO 口コミ・風評対策 採用改善