失注分析のAI活用商談メモ8件から理由を分類
し、
原文と件数を確かめる

失注理由の欄が「価格」「タイミング」に偏り、値下げすべきか、提案の出し方を変えるべきか判断できない。

商談メモは残っているものの、営業会議では担当者の印象が中心になっている責任者向けの記事です。

失注分析のAI活用は、顧客が述べた理由と社内の推測を分け、根拠の原文を残して分類するところから始めます。

分類した件数は表計算などで数え、結果を原因の断定ではなく、次に確かめる営業上の仮説へつなぎます。

この記事では、架空の8案件を使い、受注・失注・保留の区別、複数理由、不明な理由、件数と分母、改善候補の決め方を示します。

実際の商談データやAI実行、成約率の改善を測った報告ではありません。

この記事で分かること

• 顧客が述べた理由と、営業側の推測を別の列へ残します
• 不明と複数理由を消さず、案件数と分類数を分けて数えます
• 分類から原因を断定せず、次に確かめる営業上の仮説へ進みます

顧客が述べた理由と、
営業側の推測を分ける

「今回は予算を超えます」は、相手から言われた内容の記録です。

「提案の価値が伝わらなかったと思う」は、担当者の印象です。

この二つは、同じ種類の情報ではありません。

両方を残しても、根拠と仮説を別の列にします。

「価格」とあれば、
値下げが正解ですか？

価格という記録だけで、値下げすべきとは決められません。

予算、対象範囲、比較条件、購入時期など、相手が何を理由にしているかを確かめる必要があります。

例えば、顧客が「予算を超え、導入時期も来期になります」と話したなら、価格と時期の両方が理由の候補です。

価格だけへ分類すると、今期に導入しない事情が消え、値下げで解決できるように見えてしまいます。

メモにない内心や能力を補わない

「返答がない」から予算不足、「競合にした」から担当者の説明力不足、と推測して確定しません。

顧客の内心、信用や支払能力をAIに推定させる用途にも使わないでください。

失注理由が確認できない案件は、不明として件数に残します。

不明が多ければ、分類の問題より先に、失注時の聞き方や記録する項目を変える判断につながります。

分析表に、案件の
状態・
原文・分類・追加確認を並べる

元の商談メモを残し、分類の結果を隣へ追加します。

案件の状態と対象期間を決めることで、失注していない保留案件を失注件数へ混ぜずに済みます。

分類の定義を、
短い言葉でそろえる

この例の「価格」は、顧客発言に予算や提示額を見送る理由がある場合です。

「時期」は、導入や購入の時期が理由として述べられた場合。

「要件」は、必要な内容を提案で満たせないという発言がある場合にします。

「既存取引」は、今の取引先を続けることが理由として明記された場合です。

どれにも根拠がない場合は不明とします。

この5分類は本例の設計で、すべての営業に適した標準分類という意味ではありません。

たとえば「予算」は価格、「年度の都合」は時期、と機械的に語だけで振り分けると、否定や補足を落とします。

「価格は問題ないが、必要な連携がない」なら価格ではなく、要件を支える文脈です。

個人情報や社外秘を
渡す前に、入力範囲を決める

初回は、顧客名・担当者名・連絡先・実際の取引額を含まない架空メモで試します。

実データを使う段階では、会社が利用を認めたAI、契約、保存・処理条件、アクセス範囲を確認してください。

氏名を消しただけでも、商品、時期、規模などで案件を推測できる場合があります。

分類に不要な情報は外し、元の商談へ戻る対応表は権限のある保存先で管理します。

架空8案件を分類し、
不明と保留を残す

以下は、同じ対象期間に確認した8案件という架空の入力です。

6件が失注、1件が受注、1件が保留。

状態は営業側で確認した前提とし、AIが決めた状態にはしません。

D05を価格へ入れた
分類は、どう直す？

顧客の理由が記録されていないため、不明へ戻します。

「担当者が価格だと思う」という記述は社内の推測として残し、価格分類を確定する根拠にはしません。

不適切な整理例：
D05／失注理由は価格。顧客の予算に合わなかった。
改善は値引き。

修正する理由：
顧客の理由は記録なし。「価格だと思う」は社内の推測。
予算不足も、値引きの効果も確認できていない。

修正後の記入見本：
D05／状態：失注／顧客理由：記録なし／社内推測：価格が理由だと思う
分類：不明／根拠：失注理由の発言記録なし
追加確認：失注時のメールや面談記録に理由が残っているか、担当へ確認
改善候補：今後の失注記録へ、顧客発言と担当の所感を別欄で残す

これは問題のある出力と修正見本を手で用意した設計例です。

特定AIが失敗した実験結果ではありません。

分類が自然な文章でも、根拠がない値を足していないかを入力へ戻って照合します。

分類候補を出す指示文

上の架空表と分類の定義を渡し、次の指示で候補の形を試せます。

実データに置き換える際は、許可された項目だけを使います。

顧客への連絡やCRM更新を、自動で行わせない状態から始めます。

案件ごとに、失注理由の分類候補を整理してください。
状態は入力の受注・失注・保留を変更しません。
失注案件だけを理由の分類対象にします。
顧客の発言と社内の推測を別列にし、混ぜないでください。
分類は、提示した定義の価格・時期・要件・既存取引・不明を使います。
根拠は入力の原文から短く引用し、ない理由を補いません。
複数の理由がある場合は、無理に一つへ絞らず複数ラベルを残します。
顧客の内心、信用、支払能力、担当者の能力を推定しません。
出力列：案件ID、状態、顧客理由、社内推測、分類候補、根拠引用、追加確認。
改善施策の効果や原因を断定しないでください。

担当者はD04に2つのラベルが残ること、D05が不明、W01とP01が対象外になっていることを先に確かめます。

さらに全行の根拠引用が入力にあるかを読み、分類の定義と食い違う行を直します。

分類が割れた行は、
元のメモと定義へ戻す

担当者によって違うラベルが付いたら、多数決だけで決める前に、見ている原文と分類の定義が同じかを確かめます。

分類が割れる理由を残すと、次回も同じ誤りを繰り返すかを試せます。

否定を含む発言の場合

追加の試行文に「価格は問題ないが、必要な既存システムとの連携がありません」とある場合を考えます。

価格という単語があっても、価格理由へ数えません。

要件を支える部分を引用し、価格を理由として採用しない判断を残します。

この追加文は8件の集計とは別の試験用で、上の件数へ足しません。

顧客発言と担当の要約が違う場合

D04の原文は価格と時期の両方ですが、既存の理由欄に価格だけ入っている場合があります。

元の理由欄を消さず、新しい分析表では2つの根拠を保持します。

担当の要約を正解として原文を短く変えるのではなく、何を集計する分類なのかを定義へ戻して合わせます。

記録の話者が分からない場合

「予算なし」とだけ書かれていれば、顧客が述べたのか、担当者が推測したのかは判別できません。

顧客発言の列へ自動で移さず、話者未確認として担当へ戻します。

元の連絡が確認できなければ、その曖昧さを残したまま、確定理由の集計と区別します。

分類ルールを修正したら、修正に使った行だけでなく、ほかの既存行にも影響がないかを見ます。

特に「複数理由を残す」方針へ変えた場合、過去の単一分類と比べる条件が違います。

新しい分類の版と、再分類した対象期間を記録してください。

件数と割合は、
案件数・
理由数・分母を分けて数える

この例の失注は6案件ですが、D04に2つの理由があります。

分類別の件数は、1つの案件へ同じラベルを1回だけ付けて数えるルールにします。

AIが返す合計を信じるのではなく、案件IDへ戻れる表で集計してください。

割合は小数第1位へ丸めた説明用の値です。

複数ラベルと不明を含む分類件数の合計は7で、失注案件数6とは違います。

割合も合計100％にはなりません。

8案件のうち6失注なら、
失注率75％ですか？

全8案件を分母にすれば計算上75％ですが、保留1件を含む値です。

受注・失注が決まった7件を分母にするなら6÷7で約85.7％となり、意味が違います。

率を出す前に、どの状態を分母へ含めるかを定めます。

この架空8件から市場全体の傾向や営業組織の実力は判断できません。

対象期間、案件の選び方、商品や商談段階を添え、少数の記録を改善の手がかりとして読む範囲にとどめます。

追加の確認でD05の理由が分かった場合も、いつ誰がどの資料で確かめたかを追記します。

理由不明だった過去の集計を保存し、更新後の表と比較できるようにしてください。

同じ商談のメモが
複数あったら、どう数える？

案件IDで対応させ、1案件の記録としてまとめてから分類します。

初回面談と失注連絡を別案件として数えると、詳しく記録された案件だけが重くなるためです。

過去の「価格が心配」という発言と、最終の「必要な連携がない」という理由が混ざる場合も、日付と話の位置づけを残します。

商談中の懸念と、失注時に顧客が述べた理由を同じ欄へ足し続けないようにしてください。

集計から決めるのは、
原因の
断定ではなく
次の確認と改善候補

価格が2件あっても、全案件を値下げする判断には直結しません。

理由の原文へ戻り、提案範囲や聞く時期を変えて確かめる案へ進めます。

価格・時期・要件から、
違う次の作業を選ぶ

同じ提案を受けた受注案件も見るなら、顧客規模、必要範囲、商談時期などの条件が違わないかを残します。

W01の受注1件を見て、「同じ説明をすれば失注を防げる」と結論づけることはできません。

改善候補に、担当と
評価する条件を付ける

例えば営業責任者が「初回商談で必須連携を聞く欄を追加する」と検討します。

次の対象商談で記録が埋まるか、提案後に未把握要件が出るかを見ます。

短期間の受注率だけで、欄を追加した効果と断定しないようにします。

再連絡が候補になっても、連絡先や相手の意向、社内ルールを確かめる工程は必要です。

AIが候補を挙げたことを理由に、顧客へ自動送信する運用へ広げません。

担当者の能力評価へ使わない

失注理由の分類は、記録と業務改善のためのものです。

担当者によって扱う商品、顧客、案件段階が違う状態で、失注件数から個人の能力を判定しません。

記録が丁寧な人ほど理由が多く見える可能性もあります。

人の評価が必要な業務と、商談の分類を分け、確認する人と閲覧範囲を決めます。

共有する集計に生の商談発言を載せる必要があるかも、目的に応じて見直してください。

CRMから継続するなら、
分類の版と見直す担当を残す

件数が少なければ、人がメモを読んで表を埋める方法でも始められます。

CRMや複数のメモから毎回集め、分類を直して集計する負担が残る段階で、収集と記録の連携を検討します。

既存の理由欄と
集計機能を先に見る

HubSpot公式の取引プロパティには、失注理由を記録する項目が示されています。

利用中のCRMで記録とレポートが足りるなら、まずその機能を使えるか確認します。

製品や契約で使える範囲は異なります。

AIの分類結果を直接その理由欄へ上書きせず、元の理由、分類候補、担当者が採用した結果を分けます。

分類の定義を変えたら、どの版で分析したかを記録し、前月と比べる条件もそろえる必要があります。

継続集計では、増減の
理由を確認できる形にする

翌月に価格ラベルが増えても、商材や担当範囲、対象の商談段階、記録の方法が変わっていないかを見ます。

分類の版が変わっただけなら、顧客の事情が変わったことの証拠にはなりません。

分母と不明件数も同じ表へ残すと、読み違いを避けやすくなります。

CRMへ反映する仕組みなら、同じ案件を再分析して、候補が重複して増えないかを試します。

採用前の結果が、確定理由を上書きしないことも確認します。

読み取る対象と書き込む対象を絞り、失敗した行は担当が見直せる一覧へ戻してください。

自動連絡や個人評価は、この分析の実装へ付け足しません。

機密を含まない8件から、
期待する判断をそろえる

初回は上のような架空データで、不明・複数理由・受注・保留を含めます。

全件が1つの分類へきれいに収まることを目標にせず、担当者が根拠と違いを読んで判断できるかを確かめてください。

商談1件の記録を整えるなら、商談議事録から確認と次の作業へつなぐ方法へ進めます。

聞き方や説明を練習する段階は、営業ロープレのAI活用で扱います。

相談には、機密を含まない商談メモ、案件の状態、分類の定義を持参できます。

期待する結果、不明な場合の扱い、現在のCRMと確認担当も整理します。

まず失注理由の原文と社内所感を別欄へ分けるところから始めてください。

まるっとAIの営業業務の支援へは、商談記録の収集から分類、集計、担当者が見直す運用まで相談できます。

接続できる資料とCRM、変更する範囲は個別に確認し、成約率の改善を保証する話にはしません。