失注コメントを分類して失注理由を集計する

処理の起点を決める

毎月1日の朝9時など、時刻起動にします。

失注が発生するたびに1件ずつ処理する構成にもできますが、この業務では意味がありません。集計は月次でしか見ないため、月1回まとめて処理したほうが、API呼び出しも運用も単純になります。

入力データを集める

案件情報を渡す理由は、コメントの解釈が案件の文脈で変わるためです。「予算が合わなかった」というコメントは、100万円の案件と5,000万円の案件では意味が違います。

データの取得方法を決める

Salesforce REST API の SOQL クエリで、前月に失注（StageName = 'Closed Lost'）となった商談を取得します。

SELECT Id, Name, Amount, CloseDate, LossReason__c, LossComment__c, Industry__c
FROM Opportunity
WHERE StageName = 'Closed Lost'
  AND CloseDate >= LAST_MONTH

HubSpot の場合は、ディールのフィルタ検索（POST /crm/v3/objects/deals/search）で dealstage が失注のものを取ります。

AIへ渡す前に整形する

1. 空コメントの除外 … コメントが空、または「-」「なし」だけの案件を対象外にします。ここをAIに渡すと、AIは案件名から理由を推測します
2. 短すぎるコメントの分離 … 10字未満のコメント（「価格」だけなど）は、分類はできますが副因は取れません。別扱いにします
3. 個人名のマスキング … コメントに書かれた顧客担当者の氏名を、外部AIへ送る前に伏せ字にします。分類に氏名は不要です

AIに処理させる

分類コードの割り当てです。コードは先に自社で決めます。AIに「適切に分類して」と丸投げすると、毎月違うカテゴリが出てきて集計になりません。

指示内容を固定する

あなたは営業データを分類する担当者です。
以下の失注コメントを、指定された分類コードに割り当ててください。

【厳守事項】
- 分類コードは下記のリストからのみ選んでください。新しいコードを作らないでください。
- コメントに書かれていない理由を推測しないでください。
  判断できない場合は必ず UNKNOWN を返してください。
- 主因は1つだけ選んでください。副因は0〜2つまでです。
- confidence は、コメントの記述だけを根拠に判断できた度合いです。
  案件金額や業種から推測して補った場合は、必ず low にしてください。
- evidence には、判断の根拠になったコメント中の文言をそのまま引用してください。
  引用できない場合は confidence を low にしてください。

【分類コードの定義】
{code_definitions}

【案件情報】
金額: {amount} / 業種: {industry} / 商談期間: {duration_days}日

【失注コメント】
{loss_comment}

evidence にコメントの原文を引用させる指示が、この構成の要です。 引用できない分類は、AIが文脈から作った推測です。引用の有無を機械的にチェックすれば、確信度の自己申告を検証できます。

出力形式を固定する

{
  "primary_reason": "",
  "secondary_reasons": [],
  "confidence": "high | medium | low",
  "evidence": "",
  "note": ""
}

primary_reason と secondary_reasons の値は、定義した10コードに限定します。JSON Schema の enum で列挙すれば、リスト外の値が返ることを防げます。Claude API の Structured Outputs は、指定したスキーマに沿った出力だけを生成するよう制約をかける仕組みです。同種の機能は他社のLLM APIにもあります。

システムへ連携する

分類結果をSalesforceの商談レコードに書き戻します。

既存の「失注理由」プルダウンは上書きしません。 営業担当が選んだ値と、AIが分類した値を別項目で持ちます。両者を比べることで、プルダウンがどれだけ実態とずれているかが分かります。これ自体が経営に報告できる情報になります。

人が確認する

confidence が low の案件と、UNKNOWN の案件だけを人が確認します。

想定では、150件のうち30件程度（2割）がここに該当します。1件2分として60分。これが残る作業です。

high の案件を全件確認する運用にすると、削減効果がなくなります。ただし導入初月だけは全件を人が確認し、AIの分類と人の判断が何割一致するかを測ってください。一致率が8割を下回るなら、分類コードの定義が曖昧です。 コードを見直してから運用に入ります。

例外に対処する

記録を残す

• 入力したコメント（マスキング後）
• AIの出力JSON（evidence を含む）
• 人が確認して変更した場合の、変更前後の値

変更ログは、分類コードの定義を見直す材料になります。「PRICE と BUDGET の取り違えが毎月起きる」と分かれば、境界の説明を書き直せます。