Win-Loss分析ツールは、回らなくなった作業から選び、各ベンダーに証拠を出してもらう

回らなくなった作業から始める

招待、催促、回答の整理、レポート作成のどれも滞っていないなら、いまの手順は機能しており、買うものはありません。失注が何件を超えたら表計算では回らなくなる、という基準はありません。

作業量は推測せず数えます。直近の期間のクローズ済み商談の件数、1件あたりの招待・催促・回答確認にかかる分数、前回のレポート作成にかかった時間を出し、担当者が使える時間と並べます。入力値はすべて自社の記録から取り、わからない項目は「未確認」と書きます。この記事のために作った例です。クローズ済み商談が40件、1件あたりの招待と催促の作業が20分なら約13時間で、レポート作成の1日を加えると、期間あたりおよそ3営業日です。それを続けられるかどうかは、担当者が他に何を抱えているかで決まります。

買う前に、いちばん安い対処を試します。承認済みの送付先リスト、使い回せる中立的な質問、催促の予定表、根拠を1か所に集めるシート、名前の決まったレビュー担当者です。この手順の維持そのものが繰り返し止まるなら、ツールを評価します。維持できているなら、そのまま続けます。

買い手への顧客ヒアリングと、手元の記録の分析を分ける

Win-Loss分析には、性質の違う2つの仕事があります。1つは、インタビューやアンケートで買い手から新しい説明を集めることです。もう1つは、CRMやSFAの失注理由、商談の履歴、通話の記録など、すでに手元にある記録を分析することです。クリエイティブホープの解説は、Win-Loss分析を受注・失注の両方の商談について結果を左右した要因を分析する手法と定義し、CRMの記録と顧客ヒアリングを組み合わせて説明しています（クリエイティブホープ「B2BのWin-Loss分析」）。カイロスマーケティングのSFA機能ページが説明する、受注率・失注率・平均所要日数の自動集計は、既存の商談記録の集計です（カイロスマーケティング「受注・失注分析」）。ヒアリングの記載がないのはそのページの範囲の話で、他の製品がない証明ではありません。最初の問いはこうなります。既存の商談記録を整理したいのか、買い手から新しい説明を集めたいのか、その両方か。

Klueは、Win-Lossと競合インテリジェンスを1つのプラットフォームで提供し、Win-Lossの結果がバトルカードに自動で流れると説明しています（KlueのWin-Lossページ（英語））。Clozdは、同社のインタビュアーが買い手と30分の会話を行うと説明し、AIが進行するFlowにはベータと近日公開のラベルを付けています（Clozd（英語））。Cirrus Insightのガイドは、インタビュー、書き起こしのAI分析、予測、CRMの自動化と、手法ごとにツールを分けています（Cirrus Insight（英語、2026年5月））。いずれも2026年9月に読んだベンダー自身の説明であり、動作を観察した結果ではありません。このカテゴリに明確な境界はないので、評価する製品に、次の6つの作業のどれが含まれるかを尋ね、ベータ、オプション、近日公開といった提供状況の表現も答えの一部として記録します。

ベンダーのページを開く前に評価基準を6つ書く

次の6つは提案する評価基準です。それぞれ、確認できる事柄と、責任を持つ担当者を組にしています。エクスポート、固定のアンケートフォーム、絞り込んだ対象への調査は、チームによっては正しい答えです。失格になるのは、仕組みを見せられない、結果を出典までたどれない、責任者を言えない答えです。

「非同期チャット」とは、買い手がリンクを開き、都合のよい時間に1問ずつ答えていく形式で、担当者は同席しません。自社のCRM、使う言語、回答者の制限を入れて自分たちの版を書き、先に調査の問いを固定してください。「AI」や「連携」とだけ書いた基準は、まだ書き終えていません。運用コストも基準に含めます。Zoho CRMの編集部による失注分析の記事は、CRMやSFAが社内に定着するには操作性が重要だと述べ、機能、継続費用、サポートを選定項目に挙げています（Zoho CRM「失注分析の方法」）。文脈はCRM/SFAの選定ですが、問いは同じです。たどれる発見の形はWin-Lossインタビューの分析で説明しており、ツールのレポートにも同じ水準を求めます。

Claudeで公開ページを根拠と未確認事項に分ける

候補の評価はClaudeのプロジェクト内のチャットで行い、評価基準を固定します。プロジェクトは無料プランでも使え、無料ユーザーは最大5つまで作成できます（Anthropic「プロジェクトとは何ですか」）。プロジェクトの指示はその中のすべてのチャットに適用され、チャット間で共有されるのはプロジェクトナレッジに追加した情報だけです（Anthropic「プロジェクトを作成および管理するには」）。6つの評価基準と自社の制約を指示に書き、取得した各ページをURLと日付付きでナレッジに入れます。ウェブ検索を有効にすると、ClaudeはURLを渡したページを直接取得できます（Anthropic「ウェブ検索を有効にして使用する」）。取得できないときは、許可された抜粋を貼ります。1回きりなら、同じ依頼文を貼った通常のチャットで足ります。これは提案する方法で、私たちが評価を実行した記録ではありません。

1. 許可された情報源を1つずつ評価する

   評価基準ごとに、記載されている機能、短い原文の引用、URLと日付、未回答のまま残る点を求めます。確認点は、すべての機能に根拠の文があり、ページが触れていない基準は「非対応」ではなく「記載なし」と書かれていることです。

2. 提供状況の言葉を残す

   ベータ、オプション、近日公開、エンタープライズ限定は、主張の一部です。確認点は、そのラベルが対象の機能の隣に残ったまま根拠シートに移っていることです。

3. 引用をすべて自分で開く

   ページ上で見つからない引用は、項目の内容にかかわらず根拠の欠陥です。確認点は、引用された各文がそのURLに存在し、シートの記述と同じ意味であることです。

4. 空欄を動作確認の依頼に変える

   どのページも答えなかった基準が、ベンダーへの質問になります。確認点は、依頼にその基準が列挙され、ベンダーが製品案内ではなく回答を用意できることです。

そのまま使う価値がある指示文は1つだけです。根拠の境界を決める文だからです。実際のベンダーページで検証したものではないので、出発点の言い回しとして扱ってください。

この情報源だけを使って、私たちの6つの評価基準を評価してください。基準ごとに、記載されている機能、根拠となる短い原文の引用、未確認のまま残る点を書いてください。ベータやオプションなどの提供条件はそのまま残してください。情報源に記載がない場合は「記載なし」と書き、「非対応」に言い換えないでください。

この記事のために作った例で言えば、良い出力は「ベンダーはCRMを起点とした回収を説明しているが、設定するステージと再送の方針には触れていないので、両方を動作確認で確かめる」と書きます。悪い出力は「Salesforce連携があるので、インタビュー、照合、承認済みバトルカードまで自動で進む」と、1つの単語から3つの機能を推測します。

この方法の範囲で、Claudeが評価するのは渡した記述です。渡せない情報源は未確認のままで、1回の取得で読めなかったページが他の経路でも読めないとは限りません。アクセス制限は回避せず、尊重してください。製品の動作確認、セキュリティの確認、導入企業への照会の代わりにはなりません。

主張を試し、残る作業を数える

公開ページの主張は、動作確認の依頼に変えます。ベンダーが合意した練習用の入力で、対象になる商談、買い手に届く招待、辞退の操作、内容のある回答、発見を元の回答までたどれるレポートを見せてもらいます。失敗も見せてもらいます。連絡先のない商談、重複した記録、拒否されるか失敗する工程です。実在の買い手には連絡しません。その動作を自分の目で見たときにだけ、機能を「実演済み」とします。

そのうえで、残る作業を今の手順と比べます。招待、催促、確認、維持にかかる時間は自社の経験から見積もり、導入作業、謝礼の処理、情報源へのアクセス、エクスポート、更新の手続きを加えます。何が手作業として残るかは製品ごとに違います。その工程をベンダーに見せてもらい、担当者を決めて予算に組みます。

判断メモに書くものです。

• 調査の問いと、評価を始めるきっかけになった、観察した作業の滞り。
• 6つの評価基準。それぞれに確認できる出力と担当者を付ける。
• 候補の製品ごとに、確認した引用とそのURLと日付、実演済みの動作、未確認のまま残る点。
• 人が担う作業とその担当者。同じ入力値で出した自社運用の見積もりを隣に置く。
• 合わない点の明記、結論（導入、または今の運用の継続）、更新前にベンダーの情報を見直す日付。

メモと引用は、別の評価者がその製品が通った理由を再現できる場所に残します。

SteveのWin/Lossが合う場合

SteveのWin/Loss（受注・失注分析）が合うのは、滞っている作業が予約と回収である、という限られた場合です。HubSpotまたはSalesforceで商談が受注または失注でクローズすると、Steveは自分で選んだ遅延のあとに買い手を招待します。買い手は、追加質問をするAIインタビューに回答します。Steveは3日目、7日目、12日目に最大3回まで催促を送り、招待は30日で期限切れになります。ワークスペースのメンバーが「Generate Summary」（要約の生成）ボタンを押すと、Steveはその時点で集まっている回答から、受注の決め手、失注の要因、競合に関する知見、質問をまたいだ傾向などの項目を含む要約レポートを作ります。

引き換えに残るのは、人が担う工程です。買い手へのギフトカードは、完了した回答を自社のチームが1件ずつ承認してから送られます。各発見は買い手自身の言葉の隣に表示されるため、引用する前にその言葉を確認してください。レポートは回答とCRMの失注理由を比較せず、その照合は自社の作業です。発見をバトルカードやメッセージに移す処理もありません。同席型の人によるヒアリング、CRMとの自動照合、回答ごとの自動レポート、承認なしの謝礼支払いが要件なら合いませんし、いまの手順で足りているチームには買うものがありません。予約した回収と対象を絞った催促が不足している工程なら、SteveのWin/Lossを確認してください。