CRMの失注理由と買い手の回答を、同じ案件の上で照合し、両方を残す

二つの記録を、同じ案件の上に並べる

利用許可を得たCRMのエクスポートを一つのクローズ済み期間について用意し、手元にある失注ヒアリングやアンケートの記録と組み合わせます。CRMからは、元システムの案件ID、クローズ日、ステージまたは結果、記録されたままの失注理由、対象を定める製品や顧客区分が必要です。買い手側からは、回答者の役割、回答のIDと日付、対象の案件、発言の原文とその位置、すでに書かれている解釈があればそれを別の欄として持ち込みます。スナップショットの日付と元ファイル名も記録し、照合に不要な連絡先は含めません。

営業が入力した失注理由は、この作業で調べる対象そのものです。判定は先送りにしてください。才流の失注を招く9つの要因は、SFAに残る薄い記入と買い手への直接の問いかけとの差を扱い、買い手が本音を教えてくれるとは限らないとも注意しています。Salesforce日本法人の失注する9個の要因は、社内の分析で仮説を立ててから、可能であれば顧客に直接ヒアリングして答え合わせをする進め方を勧めています。この記事の照合表は、その答え合わせを案件単位で残す道具です。Clozdの受注・失注分析ガイド（英語、PDF）も、営業と買い手の回答を並べて比べ、混ぜないよう勧めています。この記事はその方針に従い、どちらかを自動的に優先することはしません。

買い手の回答をまだ集めていないなら、先に調査チームがなくても回せる受注・失注分析で集めてください。文字起こしはあるが根拠をたどれる形に整理していないなら、インタビューの分析を済ませてから比較します。

照合表は、対象案件ごとに一行の要約と、その下に紐づく買い手の記録で構成します。

理由を読む前に、案件の同一性と回答の範囲を確かめる

失注理由を一つも読まないうちに、両方のファイルを点検します。列名、生の行数、重複を除いた案件ID数、IDが空の行、IDが重複する行を数えます。対象案件の件数は、CRM側で同じ期間を絞り込んだ画面の件数と突き合わせ、フィルタが一部の区分を落としていないかをここで確かめます。

突き合わせは、確認済みの元システムの案件IDで行います。CRMとアンケートツールで識別子が違うなら、明示した対応表を使います。IDがない場合、会社名やクローズ日や製品の一致は、担当者が確認する候補を作るだけで、自動的な結合には使いません。同じ取引先の複数案件、社名の変更、クローズ日の変更は、見た目には整った誤結合を生みます。

案件と回答者は別の単位です。一つの取引先から三人がアンケートに答えたなら、一つの案件の下に三行を紐づけ、案件としては一件と数えます。最初に一致した一行に丸めてはいけません。

Claudeに、あとから検証できる照合表を作ってもらう

コード実行とファイル作成を有効にすれば、Claudeは両方のエクスポートを読んで照合表を作れます。Anthropicのファイルの作成と編集に関するページは、データ分析用のPythonスクリプトを作成できることと、無料プランを含む各プランで使えることを記しています。ファイルの容量上限は、Anthropicのページによって追加先ごとに異なる数字が示されているため、自分のワークスペースに表示される上限を確認し、エクスポートは小さく保ち、大きすぎる場合は案件の境界で分割してください。

一回だけなら通常のチャットで足ります。定期的に繰り返すなら、スキーマ、対象の条件、確認済みの対応表をClaudeのプロジェクトにまとめます。プロジェクトは無料プランでも使え、プロジェクトの管理ページによれば、プロジェクト内のチャット間で共有されるのはナレッジに追加した情報です。対応表、区分の定義、各期間の出力はファイルとして保存し、過去のチャットに頼らないようにします。

1. 結合の前に両方のファイルを点検する

   ファイルごとに列名、生の行数、重複を除いた案件ID数、空のID、重複するIDを報告してもらいます。確認点は、報告された対象件数がCRMの絞り込み画面の件数と一致することです。

2. 確認済みのIDだけで結合する

   IDの列か対応表を渡し、推測による結合を禁じます。確認点は、確認済みの一致にならなかった記録がすべて、件数付きのいずれかの例外リストに載っていることです。

3. どちらの記録も書き換えずに比較表を作る

   CRMの値、紐づく発言とその出典と日付をそのまま求め、回答がない案件は「なし」のまま残してもらいます。確認点は、入力したすべての記録が表のどこかに現れ、複数の回答者がいる案件には複数の行が紐づいていることです。

4. 解釈案は別の欄に置く

   照合できた案件ごとに、Claudeの解釈案を専用の欄に書いてもらいます。確認点は、各案が開いて読める発言を指しており、原文が解釈で置き換わっていないことです。

短いプロンプトを一つだけ使います。推測による結合と、記録が落ちる結合という、照合表を台無しにする二つの失敗を防ぐためです。

結合する前に両方のファイルを点検し、列名、行数、IDが空の行、IDが重複する行を報告してください。結合は、確認済みの案件IDか、渡した対応表だけで行い、会社名から一致を推測しないでください。元の失注理由と、紐づく買い手の出典はすべて保持し、複数の回答者は区別できるようにしてください。一致しなかった記録と、あいまいな候補は別に返し、重複を除いた案件数の検算を示してください。解釈の案は原文とは別の欄に書いてください。CRMは更新しないでください。

ファイル分析が使えない場合は、同じ照合表と確認点を表計算ソフトで行います。IDや同意が欠けているのは入力の問題なので、分析の前に解決し、結合の条件を緩めて済ませないでください。

食い違いかどうかを、発言を読んで判断する

言葉が違うことと、根拠が食い違うことは別です。CRMの「価格」と、買い手の「得られる価値に対して費用を正当化できなかった」は同じ判断を指している場合があり、買い手の言葉は価格という区分に費用対効果の文脈を加えています。検討の結果には次の四つの区分を使います。編集上の目安であり、検証された分類体系ではありません。

• 記録された理由を裏づける。 発言が同じ要因を同じ範囲で述べている。
• 詳細や別の範囲を加える。 発言が、区分では表せない仕組み、段階、選定軸を挙げている。
• 食い違いの可能性があり、確認が要る。 二つの記録が別の要因を指しており、案件を読む人が要る。
• 根拠が足りない。 発言がない、内容が不明確、または回答者が意思決定に関わっていない。

Claudeは区分を提案できますが、確定するのは責任を持つ担当者です。発言を開き、日付を確かめ、回答者が意思決定に加わっていたかを見てから決めます。二つの要因が同時に成り立たないか、一方は症状で他方は選定軸ではないかを考えます。一つの発言は一つの記録であり、結論ではありません。あとから買い手が別の要因を挙げたというだけで、営業の記録を誤りと決めつけないでください。

この記事のために作った例です。「価格」と記録された案件に、導入リスクで社内承認が止まったという買い手の発言が紐づいていたとします。この案件は両方の記録に紐づいたまま、「判断の文脈を加える。食い違いの可能性があり、確認が要る」とし、「価格は嘘だった」とはしません。別の案件で、買い手が承認済みの予算を価格が超えていたと述べていれば、「価格」の記録を裏づけます。発言のない三つ目の案件は「根拠が足りない」に置き、どちらの側にも数えません。

照合できた案件の結果と、回答のない案件数を分けて報告する

まず、照合できた同じ案件の中で、CRMの理由と買い手の説明を比べます。次に、対象案件のうち買い手の回答を確認できなかった案件数を、別の数字として示します。分子と分母をどちらも重複を除いた案件数で数えるなら、買い手の回答を確認できた案件数をCRMの対象案件数で割った割合は、回答のカバー率として使えます。ただし、特定の買い手側理由の件数をCRMの対象案件全体で割っても、一致率、不一致率、理由の出現率にはなりません。案件についての発見は案件数で数え、回答者についての発見のときだけ回答者数で数えます。

集計が傾向と呼べるようになる案件数は、検証されていません。少ない照合集合でも、すべての失注を説明することなく、特定の追加確認を裏づけることはできます。行数を増やしても、回答してくれた人の偏りは消えません。どの案件を観察したか、どの区分から来たか、その集合の中で検討した解釈が何を示すかを述べます。

発見ごとに、提案する対応と担当者を書きます。区分の定義を明確にする、案件に根拠のメモを付ける、追加確認の質問を絞る、メッセージの仮説として検証するのいずれかです。元の項目の変更はCRMの管理者が判断し、以前の値と変更理由は記録に残します。スナップショット、スキーマ、対応表、区分の定義、例外の記録、検討済みの照合表を保存しておけば、次の期間は既知の状態から始められます。

買い手の声を集め続けることが難しいとき

照合は範囲の決まった作業です。設定した対象案件について、買い手側の記録収集が続かない場合は、CRMのステージ変更に連動した催促の手順を決め、今後のヒアリングやアンケートの記録にCRMの案件IDを必ず載せるようにします。

Steveは、この収集工程の一部を担います。HubSpotの案件やSalesforceの商談が受注または失注でクローズすると、選んだ遅延の後に買い手へアンケートの案内を送ります。一方、回答の収集だけでは、この記事で扱う照合までは行われません。Steveのアンケート要約は、担当者が求めたときに生成され、構造化された回答を読みます。照合と解釈は自社に残ります。買い手側の記録収集を続けられないなら、Steveの受注・失注分析を確認してください。