# 営業の指摘を、確認済みのバトルカード修正へつなげる 営業が指摘した記載と商談の条件を確認し、根拠の範囲で修正。承認後に共有版を差し替え、出典と未確認事項を営業へ返す手順です。 URL: https://www.hiresteve.ai/ja/blog/battlecard-feedback 最終更新: 2026-09-16 営業からの指摘は、記憶の正しさを争うのではなく、確認できる修正につなげます。問題の記載と商談の条件を受け取り、関係する資料を確認し、根拠のある範囲だけを承認してください。修正版と未確認の質問を営業へ返せば、次の確認にも使える履歴が残ります。 成果物は、営業が使えるバトルカードと短い修正記録です。修正記録には、変更点、根拠、適用範囲、承認者を残します。営業は回答を使え、次の担当者は判断の経緯をたどれます。 ## 確認できる形で指摘を受け取る まず、営業が疑問を持った一文をそのまま受け取ります。顧客が話した内容、対象プランや市場、利用できる出典も確認してください。調査に不要な氏名や機密情報は削除します。 自由記述だけにせず、次の項目で短く受け付けます。 - **問題の記載:** 共有中のカードから一文を転記します。 - **顧客の条件:** 関係する顧客層、市場、プラン、契約条件を記録します。 - **起きたこと:** 許可がある場合は顧客の言葉を残し、難しければ内容を正確に要約します。 - **手がかりとなる資料:** 指摘のきっかけになった見積もり、ページ、社内メモを示します。 - **必要な対応:** 修正版、顧客に聞く質問、または両方のどれが必要かを書きます。 営業の報告から分かるのは、その商談にカードが合わない可能性です。競合の全プランや全顧客に同じ条件が当てはまるとは判断できません。確認中は該当する一文を「要確認」とし、その主張が確認中であることを示します。 内容ではなく探しにくさが問題なら、事実確認とは分けて直します。[バトルカードのテンプレート](/ja/blog/battlecards-sales-actually-uses/battlecard-template)では、反対意見、一文の回答、日付付きの根拠、競合の切り返しと対応を分けています。 ## 指摘の種類と根拠を分ける 営業からの指摘は、いくつかの問題を含みます。文言を直す前に、どの問題かを決めます。 | 指摘の種類 | 確認するもの | 修正の判断 | | --- | --- | --- | | 事実と異なる可能性 | 現在の社内資料と競合資料 | 修正または保留する | | プランや市場が合わない | カードと出典に書かれた適用範囲 | 適用範囲を狭める | | 営業が回答を見つけられない | 見出し、反対意見の表現、共有場所 | 名称や配置を直す | | 商談で次の行動につながらない | 顧客の質問とカードの確認事項 | 回答や追加質問を直す | 競合についての記載は、現在の料金、製品、ヘルプ、更新情報のうち、該当箇所を開いて確認します。過去の保存ページは、当時の根拠として扱います。自社についての記載は、承認済みの社内資料を使い、提供条件を残します。顧客の発言は商談の条件を示しますが、製品資料の代わりにはなりません。 重要な主張ごとに、根拠の該当箇所、出典、適用範囲、確認日、担当者、状態を記録します。状態は「根拠確認済み」「要確認」「追加説明が必要」「使用終了」などで十分です。ここで使う状態は作業用の分類で、信頼度の点数ではありません。 資料同士が食い違う場合は、プラン、市場、契約形態、適用時期の違いを調べます。それでも解決しなければ、問題の文言を共有版から外し、営業には確認が必要な条件を返します。 ## Claudeで適用範囲を保った修正版を作る 継続して扱う場合は、承認済みの会社情報、競合ごとの資料、出力ルールをClaudeのプロジェクトにまとめます。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)では、プロジェクトのナレッジと指示が、そのプロジェクト内の作業に文脈を与えると説明されています。資料の維持方法は[プロジェクト設定の手順](/ja/blog/claude-project-setup)を参照してください。一度だけの修正なら、同じ範囲の資料を一つのチャットに渡して進められます。 Claudeには、問題の一文、顧客の条件、利用できる資料の該当箇所を渡します。修正版、必要な適用範囲、各説明の根拠、未確認の条件を分けて出すよう依頼してください。出力は下書きです。出典の該当箇所を開き、資料で言える範囲を修正版が超えていないか確認します。 次は架空の練習例です。共有中のカードに「競合のBusinessプランにはSSOが含まれない」とあります。営業から、顧客の見積もりにはSSOが含まれていると連絡がありました。この報告はカードを確認する理由になりますが、すべての契約でSSOが含まれるとは示していません。 保存していた過去の料金ページは、当時表示されていた条件であれば旧表現を支えます。現在のプランページには、特定の契約形態でSSOを提供するとありますが、ほかの契約については説明がありません。修正版には、その範囲を残します。 - **回答:** 競合のSSO提供条件は、プランと契約形態によって異なります。 - **確認すること:** 見積もりに記載されたプランと契約形態は何ですか。 - **根拠:** 現在のプランページにリンクし、保存ページは過去の資料と明記します。 - **未確認:** ほかの契約形態の条件は、これらの資料だけでは分かりません。 この修正では、根拠のない一般化を削り、営業が次に聞く質問を残しています。古い一般化を別の一般化に置き換えてはいけません。 ## 承認し、共有版を更新して営業へ返す カードの責任者が、修正版を根拠の該当箇所と顧客の条件に照らして確認します。判断と確認者を記録し、旧表現は変更履歴に残して「使用終了」とします。共有中のカードには、適用範囲を読み取れる形で記載してください。 最初に管理中のカードを更新します。その後、提案資料、CRMの文面、Claudeのプロジェクトへアップロードした資料など、把握しているコピーを差し替えます。可能であれば管理中の版へのリンクを案内し、次の修正で追うコピーを減らします。リンクを使う場合も、営業が閲覧できるか確認が必要です。 指摘した営業には、修正した文言、出典、未確認の質問を返します。指摘のきっかけになった商談の疑問に答えたかも聞いてください。受領の返事から分かるのは、修正版が届いたことまでです。文言が実際に使われたか、商談結果が変わったかまでは分かりません。 ## 続けられるフィードバック運用にする 問題の記載、報告者、顧客の条件、根拠、判断、担当者、状態を短い一覧で管理します。繰り返し出る指摘、未解決の項目、営業が見つけにくいカードを確認してください。コメント数だけを利用状況や売上への効果として扱うことはできません。 参照元の内容が変わったとき、営業から指摘があったとき、カードの適用範囲が現在の提供条件と合わなくなったときに再確認します。確認間隔は、情報の変わりやすさと誤った場合の影響で決めます。この手順には、すべてのカードに共通する確認頻度はありません。 確認やコピーの差し替えが負担になったら、どの作業が止まり、誰が担っているかを書き出してから、別の運用を選びます。[内製、自社での自動化、競合インテリジェンス製品の比較](/ja/blog/build-vs-buy-competitive-intelligence)では、競合社数を導入基準にせず、三つの運用方法を比較しています。 ## よくある質問 ### 営業がバトルカードの記載を指摘するとき、何を共有しますか? 問題の記載、顧客が話した内容、対象プランや市場、共有できる出典を確認します。調査に不要な顧客情報は除きます。営業の報告は確認を始める手がかりであり、すべての条件で記載が誤りだと示す証拠ではありません。 ### 一件の指摘だけで、バトルカードの記載を誤りと判断できますか? いいえ。一件の指摘から分かるのは、確認すべき記載と顧客の条件です。現在の利用可能な資料と照合し、根拠の範囲に合わせて文言を修正、限定、または保留します。 ### 競合の最新資料同士で説明が違う場合はどうしますか? プラン、市場、契約、適用時期の違いを説明できるまで、問題の記載を共有版から外します。食い違いが残る場合は、自社に有利な資料を選ばず、未確認の条件と営業が顧客に聞く質問を残してください。 ### バトルカードのフィードバックは、いつ対応済みにしますか? 責任者が修正を承認し、管理中のカードと把握しているコピーを更新し、営業へ新しい文言、根拠、未確認事項を返した時点です。その商談の疑問に答えたかを記録し、受領の返事だけで商談結果への効果を判断しません。