月次の営業会議で、AIが分類した失注の集計表が画面に映る。先月は「競合に負けた」が最多だった。今月は「タイミングが合わなかった」が最多になっている。営業の動きは変わっていないのに、最多の理由だけが入れ替わった。
誰かが聞く。「先月と同じ基準で分類しているのか」。誰も答えられない。AIに渡したのは失注メモだけで、分類の基準は毎回その場の指示文に書いていたからだ。
この記事では、失注メモをAIに分類させる前に 人が決めておくこと と、そのまま使える 分類用・集計用のプロンプト を整理する。
失注分析とは
失注分析とは、受注できなかった案件を分類・集計し、次の商談の進め方を変える材料にする取り組みである。よくある誤解は、「失注の理由を集めれば原因がわかる」というものだ。
理由は、本人が事後に振り返って書く 見立て である。見立ては書く人の記憶と都合で変わる。AIに分類させても、元が見立てである以上、きれいに整った見立ての一覧ができるだけだ。失注分析の価値は、集めた量ではなく、集めたものが 次の工程に接続しているか で決まる。
よく追われているKPIと、空振りする理由
失注分析でよく置かれるのは、失注件数、失注理由の一覧、失注分析レポートの作成数、AIによる失注要約の件数である。
空振りする理由は2つある。
- 出力が増えるだけで、見る人と見る場所が決まっていない。 AIで要約や分類を自動化すると、出力の量は一気に増える。増えた分を読む人がいなければ、実施件数だけが積み上がる。
- 理由が「逃げ場」に集まる。 自由に書かせると「価格」に集中しやすい。価格は誰も責めない理由だからだ。「追えなくなった」「次の約束を取れないまま止まった」といった、本人の行動に近い理由ほど書かれない。AIはその偏りを直さず、整えて見せる。
大全の判定で仕分ける
判定は営業KPI大全の5分類に従う。
| KPI | 判定 | 理由 |
|---|---|---|
| 失注理由の記録率（分母は失注全件） | ①-A 刈り取り（次の工程が定義されている場合） | 失注した全件が分母なので絞れない。記録の先に分析と打ち手の工程がなければ②に落ちる |
| 失注確定の入力が期限内に行われた割合 | ①-A 刈り取り | 分母は失注した全件で固定。放置された案件を残さない行動で、本人が今日から変えられる |
| 失注分析レポートの作成数 | ② 空振り | 作っても獲得率とつながらない。作成は成果ではない |
| AIが分類・要約した失注の件数 | ② 空振り | 出力量を数えているだけ。自動で増えた件数は、読まれなければ売上に接続しない |
| 失注件数・失注率 | ③ 結果（評価に入れずモニタリング） | 獲得率の裏返し。本人が直接は動かせない。評価に入れると、失注を保留に書き換える動きが出る |
| 失注理由に占める「価格」の割合 | ③ 結果（診断用） | 高いときは、価格が真因なのか、分類の設計が逃げ場になっているのかを疑う材料として見る |
分かれ目は、大全で示した問いと同じである。その数字が積み上がった先に、それを売上に変える工程が定義されているか。 分類の結果を読み、打ち手を決め、次の期に確かめる工程がある場合だけ、記録は①-Aになる。
AIに分類させる前に決める｜MECEな分類の設計
AIは、定義された基準に沿って振り分ける作業を速くする。だが基準そのものは持っていない。基準がなければ出力はもっともらしく、毎回少しずつ違う。冒頭の「最多の理由が入れ替わった」は、AIの精度の問題ではなく、基準が毎回書き直されていたことが原因だった。
「価格＋機能不足」では、モレる
失注理由を「価格」と「機能不足」の2つで分けている組織は多い。だがこの2つは失注の一部にしか触れていない。「検討が止まった」「決裁者に届かなかった」「競合に先行された」「追えなくなった」が抜け落ちる。モレた分類をAIに渡すと、AIはモレた案件を無理にどちらかへ押し込む。MECEの考え方そのものはMECEとはに委ね、ここでは失注に固有の切り方だけを書く。
第1階層：案件に何が起きたか（排他的な3つ）
最初の切り口は、理由ではなく 起きたこと で置く。1件の失注が必ずどれか1つに入り、2つには入らないようにする。
| 第1階層 | 定義 | 判定に使う事実 |
|---|---|---|
| A 比較の土俵に乗らなかった | 顧客が検討そのものを止めた、または始めなかった | 提案書を出していない／比較検討の段階に入っていない |
| B 比較の土俵で選ばれなかった | 提案まで進み、競合・内製・現状維持のいずれかに決まった | 提案済み／決まった先が確認できている |
| C 自社が追えなくなった | 顧客の判断が出る前に、次の約束が途絶えた | 最後の商談で次回アポが入っていない／連絡が途絶えた日付 |
境界の判定は見立てではなく事実項目で行う。「提案書を出したか」「最後の商談で次回アポが入ったか」は、書く人によってぶれない。AIにとっても、メモの文面より事実項目のほうが拠り所になる。
第2階層：Bだけを、機能・非機能に分ける
「選ばれなかった」理由は、ソフトウェア開発の言葉を借りて 機能要件 と 非機能要件 に分けると整理しやすい。営業の商材がソフトウェアでなくても使える。
| 第2階層 | 中身 | 打ち手の持ち主 |
|---|---|---|
| B-1 機能（要件を満たせなかった） | 顧客が必要とした働き・仕様を、自社の商材が持っていなかった | 商品・開発へのフィードバック |
| B-2 非機能（要件は満たしたが、条件で負けた） | 価格、導入時期、導入・運用の負担、サポート体制、実績、セキュリティ・規程への適合など | 提案設計・営業・契約条件 |
機能と非機能を分ける意味は、打ち手の持ち主が変わる ことにある。機能で負けたなら営業の努力ではなく商品へのフィードバックの話で、非機能で負けたなら提案や条件の設計で動かせる。「価格」を代表にしないのは、非機能の一項目にすぎないからである。
分類が使えるかを確かめる3つの問い
- 直近の失注を10件取り出して、全件が1つの箱に入るか（モレの確認）
- 2つの箱に入ると迷う件がないか（ダブりの確認）。迷うなら定義文か事実項目に曖昧さがある
- 「その他」「要確認」が増えていないか。増えているなら、第1階層のどこかにモレがある
3つ目は毎月見る。分類は一度作って終わりではなく、「その他」「要確認」の増減で見直す対象である。
失注分析のプロンプト
分類の定義ができたら、プロンプトに固定して使う。毎回その場で指示文を書き換えないことが、冒頭の「最多の理由が入れ替わる」を防ぐ。AIに任せるのは 仮の振り分け と 件数の集計 までで、原因の判断と打ち手は人が決める。
プロンプト1：分類用
# 役割
あなたは営業の失注記録を分類する担当です。
原因の推定、評価、打ち手の提案はしません。分類だけを行います。
# 入力
案件ごとに、次の2つを渡します。
- 失注メモ（自由記述）
- 事実項目：提案書を出したか／最後の商談で次回アポが入ったか／決まった先（競合・内製・現状維持・不明）／決裁者と会えたか
# 分類の定義
第1階層（必ず1つだけ選ぶ）
A 比較の土俵に乗らなかった：顧客が検討そのものを止めた、または始めなかった。提案書を出していない。
B 比較の土俵で選ばれなかった：提案まで進み、競合・内製・現状維持のいずれかに決まった。
C 自社が追えなくなった：顧客の判断が出る前に、次の約束が途絶えた。最後の商談で次回アポが入っていない。
第2階層（Bの場合のみ選ぶ）
B-1 機能：顧客が必要とした働き・仕様を、自社の商材が持っていなかった。
B-2 非機能：要件は満たしたが、価格・導入時期・導入運用の負担・サポート体制・実績・セキュリティや規程への適合などの条件で負けた。
# ルール
1. 根拠は、失注メモと事実項目に書かれていることだけにする。書かれていないことを推測で補わない。
2. 事実項目とメモの内容が食い違う場合は、事実項目を優先し、「要確認」にして食い違いを書く。
3. 2つ以上に当てはまり、1つに決められない場合は「要確認」にする。無理に選ばない。
4. 「その他」は使わない。どこにも入らない場合は「要確認」にする。
5. 分類の根拠として、メモから該当箇所を短く引用する。引用できない場合は「要確認」にする。
# 出力形式
次の表だけを出力する。解説や提案は書かない。
案件ID | 第1階層 | 第2階層 | 根拠（メモの引用） | 要確認の理由ポイントは3つある。事実項目を優先することで、見立てに引きずられない。「その他」を使わせず「要確認」に回すことで、AIが迷いを隠して押し込むのを防ぐ。根拠の引用を必須にすることで、人が確認すべき箇所がすぐ見つかる。
プロンプト2：集計用
集計に渡すのは、人が「要確認」を確定させた後の分類表である。AIの仮分類をそのまま集計に流さない。
# 役割
あなたは確定済みの失注分類表を集計する担当です。
数えること以外はしません。原因の断定、評価、打ち手の提案は書きません。
# 入力
月ごとの分類表（案件ID／第1階層／第2階層／事実項目）
# 集計内容
1. 第1階層（A・B・C）の件数と構成比
2. Bのうち、第2階層（B-1・B-2）の件数
3. 「要確認」だった件数と、確定後の振り分け先
4. 事実項目との突合：Bのうち決裁者と会えていなかった件数、Cのうち最後の商談で次回アポが入っていなかった件数
5. 前月との件数の増減（構成比ではなく件数で示す）
# ルール
- 件数が少ない区分では、割合を強調しない。件数をそのまま書く。
- 増減の理由は推測しない。
# 出力形式
表1枚のみ。集計表を見て最も多い型を1つ選び、対応する行動を決めるのは人である。プロンプトに「打ち手を提案させる」と書かないのは、提案の量が増えるほど、現場が何を変えればよいか分からなくなるからだ。
プロンプトを使う前の検証
プロンプトは書いただけでは使えない。次の順で確かめる。
- 直近の失注を10件選び、人が先に手で分類する
- 同じ10件をプロンプト1で分類させ、人の結果と並べる
- 食い違った件を見る。AIの誤りではなく、定義文や事実項目の曖昧さが原因であることが多い
- 定義文を直し、再度分類させる。食い違いが「要確認」に回るようになれば、運用に入れる
- 運用に入れたプロンプトは固定し、変更したら日付と理由を残す
何を数えれば動くのか
分解式でいえば、記録は獲得率（今期ルートも残物件ルートも共通の項）に効く。獲得率そのものは③なので現場に追わせず、手前の行動に落とす。
1. 「失注」の定義を先に決める。 失注の入力が遅れる組織では、失注した案件が「保留」のまま残る。大全でも触れたとおり、次回アポが2週間以内に入っているかどうかは、日付で判定できる基準の候補になる。
2. 記録項目を、分類の階層と事実項目に分ける。 選択式は6〜8項目に収め、「価格」を最初の選択肢に置かない。事実項目は、見立てが入らないはい・いいえで取る。
3. 入力のタイミングと分母を固定する。 失注を確定した時点で、その場で入力する。分母は失注した全件にする。記録しない失注を許すと、記録率の分母が操作できてしまう。
4. プロンプトで仮分類し、「要確認」は人が確定する。 確定した分類表だけを集計に渡す。
5. 月次で打ち手を1つだけ決め、次の期に同じ表で確かめる。 たとえば「追えなくなった（C）」が多いなら、次回アポのその場設定率を置く。打ち手が複数あると、どれが効いたか判別できない。