# 受注・失注分析の気づきをメッセージに反映する判断と、変更前の検証の進め方 どの気づきならメッセージを変える根拠になるかを見極め、裏付けのある一文と仮説を分けて書き、限られた範囲で検証し、判断の記録を残す方法を解説します。 URL: https://www.hiresteve.ai/ja/blog/win-loss-to-messaging 最終更新: 2026-10-12 まず、変えるかもしれないメッセージを1つと、それが支える買い手の判断を決めます。そのうえで、整理済みの気づきがそのメッセージに何を求めているかを判断します。訂正か、検証か、別の担当者への引き継ぎかです。成果物は短い変更案の記録です。現在の文言、出典IDを付けた買い手の発言、反対の根拠、変更案の文言とそれを裏付ける製品の事実、検証で答えるべき問い、判断する人を書きます。断定的な主張は、確認できた反例が1件あれば取り下げる根拠になります。繰り返し出る要望は、メッセージに載せる前にまず検証の対象になります。 ## 変えるかもしれないメッセージから始める この記事は、[インタビューの整理](/ja/blog/analyze-win-loss-interviews)を終え、抜粋とインタビューまたは案件のIDが付いた気づきの一覧がある段階から始めます。CRMの失注理由と買い手の回答が食い違っているなら、[先に照合](/ja/blog/win-loss-vs-crm)してください。[調査チームなしで進める受注・失注分析](/ja/blog/win-loss-analysis-without-a-research-team)は気づきの置き場所を示します。この記事は、その置き場所に載せる価値があるかを判断します。 対象のメッセージを1つ選び、それがどの買い手のどの判断を助けるものかを決めます。料金ページの一文、提案資料のスライド、バトルカードの1行などです。手元に、整理済みの気づき、IDと日付付きの原文の抜粋、今回の調査が対象にした顧客層・受注／失注・質問項目の一覧、現在の承認済み文言、その裏付けになる製品の事実をそろえます。使うのは、個人情報を除き、利用が認められた資料に限ります。足りない情報は足りないままにします。整った要約から、記録にない受注／失注の結果を推測することはできません。 成果物は変更案の記録です。メッセージ1つにつき1枚、次の項目を書きます。 - 現在の文言と、それが載っている資料と対象の読み手。 - 観察された事実。根拠になる行ごとに、抜粋とインタビューまたは案件のIDを付ける。 - 反対の根拠。今回の調査の中で逆の方向を示す買い手や案件。 - 考えられる説明。仮説であることを明記する。 - 変更案の文言と、それを今日の時点で正しいものにする製品の事実。 - 検証で答えるべき問いと、その観察方法。 - 担当者と判断。採用・修正・保留・引き継ぎのいずれかと、日付。 ## 数える前に、気づきの範囲を確かめる ここで混同しやすい作業が2つあります。案件を数えるのは、今回の調査の中で、いくつの別々の購買判断にその気づきが表れたかを知る作業です。情報源を突き合わせるのは、1つの話が裏付けられるかを確かめる作業です。Outreachの受注・失注分析ガイド（英語）は、[傾向に基づいて動く前に、独立した2つ以上の情報源を求める](https://www.outreach.ai/resources/blog/how-to-run-a-win-loss-analysis)ことを勧めています。これは裏付けについての助言であり、2人の買い手が言うまでメッセージを変えてはいけないという基準ではありません。 根拠になる行を、案件と顧客層ごとにまとめます。同じ案件から出た複数の抜粋は1つの購買判断です。ただし、同じ案件を別々の人が語っていれば、細部の裏付けにはなります。購買に関わる複数の担当者を、互いに独立したサンプルとして数えないでください。すべて失注だった、買い手が1つの顧客層に偏っていた、といった条件は記録の冒頭に書きます。1件しか聞いていない顧客層では、同じ気づきが繰り返しようがないためです。件数が表すのは渡した資料の範囲であり、買い手全体での頻度ではありません。 この整理は、[プロダクトマーケティング用に用意したClaudeのプロジェクト](/ja/blog/claude-project-setup)のチャットで頼めます。Anthropicの公式ページには、各プロジェクト内で[ドキュメントをアップロードし、コンテキストを提供し、焦点を絞ったチャットができる](https://support.claude.com/ja/articles/9517075-%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%A7%E3%81%99%E3%81%8B)とあります。プロジェクト管理のページ（英語）では、[プロジェクト内のチャット間で共有されるのは、ナレッジとして追加した情報だけ](https://support.claude.com/en/articles/9519177-how-can-i-create-and-manage-projects)だと説明されています。現在の気づきの一覧、調査範囲の一覧、承認済みの文言をファイルとして渡してください。以前のチャットは根拠の資料にはなりません。受け取ったファイルと足りない情報を挙げてもらい、次に、各気づきに実際の抜粋を紐づけ、買い手の発言と営業担当者の解釈を分け、案件と顧客層ごとにまとめてもらいます。そのあと、候補になった行の原文を自分で開きます。 ## 訂正か、検証か、別の担当者の課題かを決める **確認できた誤りは、2人目の買い手を待たない** 自社のメッセージにある断定的な主張が誤りだと1人の買い手が示し、製品側でその事実を確認できたなら、その場で取り下げるか範囲を狭めます。訂正の根拠になるのは製品側の確認で、2人目の買い手を待つ必要はありません。急ぎの1件の修正は[営業の指摘からバトルカードを直す手順](/ja/blog/battlecard-feedback)で扱い、この記事は調査1回分の仕分けを扱います。 それ以外の気づきは、3つのいずれかに分けます。複数の別々の案件で出た指摘や、1件でも今後繰り返すと見込める指摘は検証候補です。記録に文言案と検証方法を書き、検証が終わるまで配布しません。根拠が薄い、または矛盾している気づきは保留にし、何が分かれば判断できるかを行に書きます。製品の不足、購買手続きの制約、営業プロセスの問題を表す気づきは、範囲を付けてその課題の担当者に回します。文言を書き換えても解決しないためです。 最後の分類には、一見すると関係のなさそうな失注も含まれます。親会社が別のベンダーを指定していた、商談の途中で予算がなくなった、といった失注理由は、案件の見極めや顧客層の適合に関する気づきです。同じ顧客層で続けば、営業責任者が見極めの条件を変える判断材料になります。才流の失注要因の解説も、[複数の要因を分けて捉え、組織で共有する](https://sairu.co.jp/method/6720/)ことを勧めています。どの分類にも最低件数はなく、少数意見を自動的に捨てることもしません。各行には、なぜ文言の変更が対応策なのか、あるいはなぜそうではないのかを書きます。 ## 裏付けのある一文と、仮説を分けて書く 1つの気づきには、別々の場所に置くべき3つの要素があります。観察された事実は買い手が言ったことです。説明はその理由についての推測です。文言は営業担当者やページが次に言うことです。この3つを1つの文にまとめると、推測が主張に変わります。 説明のために作った例です。 | 要素 | 内容 | 置き場所 | | --- | --- | --- | | 観察された事実 | 別々の2案件（ID 14と22）の買い手が、Webサイトを見てもどのプランが自社に合うか分からなかったと話した。 | 気づきの一覧。抜粋を添える | | 説明 | 料金ページはプランを機能一覧で説明しており、どちらの買い手も自社の利用量と結び付けられなかった。 | 変更案の記録。仮説と明記する | | 変更案の文言 | 「プランは月間の利用量で決まります。初回の打ち合わせで、どの区分に当たるかを確認します。」 | 変更案の記録。プランが実際に利用量で決まる場合に限る | | 検証で答える問い | この一文を聞いた買い手は自社の区分を正しく判断できるか。聞いたあとに誤ったプランを選ぶ人は残るか。 | 変更案の記録 | 変更案の文言が約束しているのは、製品がすでにそうなっている事実だけです。説明すれば買い手が正しく選べるようになる、とは言っていません。2人の買い手が迷ったという事実からは、それは示せないからです。裏付けになる製品の事実がなければ、担当部署に確認を求めるか、すでに正しいと分かっている補足説明を選びます。将来の買い手が否定しうる一文はよい仮説であり、製品の事実が確認でき、検証を終えたときにメッセージになります。 下書きができたら、最初に承認済みのメッセージと比べます。承認済みの位置づけと矛盾する文言は[ポジショニングの問題](/ja/blog/positioning-brief)として、カードを変える前にその判断を通します。確認を通った文言は、[メッセージングのテンプレート](/ja/blog/messaging-template)で最終的な形に整えます。 ## 不確かな点を検証し、起きたことを記録する 検証で答えるのは、記録に書いた問いだけです。確認済みの事実に基づく文言は、その課題が生じる商談や会話に限って使います。記録するのは3点です。文言が実際に使われたか、買い手がそれをどう理解したか、反論や反例が出たかを確かめます。見直しの時期は、その課題を観察できる実際の機会に合わせます。観察機会が少ない場合、短い固定期間を区切っても、判断に使える記録が集まらないことがあります。 3種類の結果を区別します。「使われなかった」は、文言か説明の仕方についての気づきです。「使われたが誤解された」は、文の直しが必要です。「理解されたが本当の問題に届かなかった」は、記録に書いた説明が誤っていたということで、気づきは保留に戻ります。少人数の営業担当者による検証で分かるのは、文言が使いやすく、意図どおりに伝わるかまでです。受注率が変わったかは分からず、数件の商談に因果関係を語らせることはできません。Mazricaのバトルカードの解説は、[営業担当者が会話で使える実用的な書き方](https://mazrica.com/product/senseslab/sales/sales-battle-card/)を勧め、使ったあとの効果測定にも触れています。この記事の検証はそれより小さく、配布の前に行うものです。 利用が認められた観察記録は、プロジェクトのチャットに戻します。渡した使用記録と結果ラベルを仮説と照合し、食い違う箇所を挙げるようClaudeに依頼します。挙がった箇所は、出典IDと原記録に戻って確かめます。記録されていない商談は対象にできないため、観察記録はファイルとして渡します。採用するかどうかは人が決めます。 ## 採用しても見送っても、根拠を残す 判断（採用・修正・保留・引き継ぎ）、担当者、影響を受ける資料、根拠の日付、次の見直し時期を、どの結果でも記録します。承認済みメッセージのファイルはプロジェクトのナレッジで明示的に更新し、置き換えた文言と原文の抜粋を隣に残します。あとから読む人が、なぜその一文が変わったのかをたどれるようにするためです。才流は、[失注理由が営業個人に蓄積されても組織全体の改善にはつながらない](https://sairu.co.jp/method/6720/)と指摘しています。メッセージの判断も、個人のチャット履歴に残る状態では次の調査に使えません。 次回以降の調査では、保留した気づきに似たものが出てきます。似ていることは見直しのきっかけであり、自動的に採用する理由ではありません。2つの観察を同じ気づきとして扱う前に、製品のバージョン、顧客層、質問の文言、期間が比較できるかを確かめます。料金ページを書き換える前のプラン選びの迷いと、書き換えた後の迷いは、別の気づきです。 ## SteveのWin/Lossは、材料の収集をどこまで支えるか 買い手の声を継続的に集める作業が自社で滞るなら、定期的な依頼の予定、常に最新の根拠ファイル、メッセージの担当者との短い確認の場を用意します。 SteveのWin/Lossは、HubSpotの取引またはSalesforceの商談がクローズすると、選んだ遅延の後にCRM連動で買い手へサーベイを送ります。サーベイは、案件のクローズ時に自動で送る方法と、リンクを手動で送る方法のどちらでも使えます。 新しい回答が届いたら「要約を生成」を実行します。要約は、その時点で得られている回答から作られます。要約には、全体の概要、受注の理由、失注の理由、競合に関する示唆、質問をまたいだ傾向が含まれます。テーマはAIが検出するので、買い手本人の回答と照らして確かめます。 SteveのWin/Lossは、買い手のテーマをバトルカードや反論への回答と照らして見直せるように示します。文言の選択・検証・記録は自社で行います。導入時の設定と、レポートを継続的に確かめる手間が必要です。継続的な収集が課題なら、[Steveの受注・失注分析](/ja/products/winloss)を確かめてください。すでに十分な根拠を集められているなら、変更案と判断の記録は共有文書で足ります。 ## よくある質問 ### 何件のインタビューで同じ気づきが出れば、メッセージを変えてよいですか？ 検証された最低件数はありません。断定的な主張が誤りだと1人の買い手が示し、製品側でも確認できたなら、その1件で取り下げる根拠になります。繰り返し出る要望は検証候補にし、根拠が薄い気づきは保留します。Outreachが勧める「独立した2つの情報源」は、1つの話の裏付けに関する助言です。買い手の人数の基準は示していません。 ### 1人の買い手しか言っていない気づきは、どう扱いますか？ 範囲を付けて残し、どの種類の対応が必要かを決めます。事実の誤りが確認できれば訂正し、もっともらしい指摘は検証候補にし、製品の不足や購買手続き、営業プロセスの問題は担当者に回します。1件だけという理由で捨てることはしません。 ### 気づきの仕分けをClaudeに任せられますか？ この作業では、現在のチャットで渡した資料か、プロジェクトのナレッジに明示的に追加した資料を使うようClaudeに依頼します。抜粋を紐付け、案件と顧客層ごとに整理し、変更案を下書きするよう依頼します。渡していない記録や結果ラベルは足りないままです。候補は出典IDと原文に戻って確かめます。 ### 新しい一文は、どう検証しますか？ その課題が生じる商談や会話に限って、確認済みの事実に基づく一文を使います。営業担当者が使ったか、買い手がどう理解したか、反論や反例が出たかを記録します。少人数の検証で確かめられるのは使いやすさと理解のされ方までで、受注率への影響は分かりません。 ### Steveは気づきをメッセージに自動で反映しますか？ Steveは買い手の回答からテーマを検出し、買い手本人の言葉と並べて示します。ポジショニング、反論への回答、バトルカードのどこを変えるかは自社で見直して決め、文言を検証して記録します。