# 情報の古さが見える営業バトルカードのテンプレート

> 商談で使える営業バトルカードの完全テンプレートと記入例。質問、反論への応答、検証手順を整理し、Browse AI、Notion、Slack、Zoomの確認済み事例で解説します。


「その機能は、先方のプランにもう含まれています」

デモの途中で買い手にそう言われると、古い比較スライドを使っている営業担当者は説明に追われます。その後の数分は、どちらの情報が正しいかを議論する時間に変わります。買い手の本当の課題は後回しです。

小さな SaaS チームにとって、競合の提供内容が変わったと知るには高くつく方法です。創業者はすべての商談に同席できません。プロダクトマーケティング担当者も、昼までにすべての資料を書き直すわけにはいきません。営業に必要なのは、古い機能比較表と「念のため再確認を」という注意書きよりも役立つものです。

役に立つバトルカードは、商談の進め方を示します。何を聞くか、競合のどこに実力があるか、どの違いが重要か、それをどう証明するか、買い手から反論されたらどうするか。競合に関する各主張には、それぞれ根拠と日付も必要です。表紙だけ新しくしても、古い主張は救えません。

以下では、営業バトルカードの完全テンプレート、Browse AI の記入例、Notion、Slack、Zoom を使った詳しい事例を紹介します。撤回すべき具体的な言い方、その代わりに聞く質問、そして優位かもしれない点を説明に耐える優位性へと変える確認手順がわかります。

[バトルカードのテンプレートへ](#営業バトルカードのテンプレート)、または [Browse AI の記入例から読む](#バトルカードの記入例browse-ai-と-amazon-s3)。

## 1枚のカードに買い手と意思決定を1つずつ定める

営業バトルカードは、特定の競合との比較商談に向けた短い社内ガイドです。次に何を話し、何を見せるかの判断を助けます。製品カタログでは、その役割を果たせることは多くありません。

実際の商談に登場する競合を選び、購入を検討している状況を明記します。「Notion 対策」では広すぎます。「専用の検索ツールと、Notion Business に含まれる AI 機能を比較しているサポートチーム」なら、買い手、既存の選択肢、検討する理由が定まります。

最近の商談、反論が書かれたメール、受注・失注メモから始めてください。現在の業務手順も含め、買い手が実際に何を比較しているかを書き出します。表計算や既存の契約を使い続けることが、商談で最も手ごわい競合になる場合もあります。

競合ごとに基本のカードを1枚用意し、会話が本当に変わる場合だけ、用途別の短い節を設けます。買い手、評価基準、証拠が異なる場合にはカードを分ける意味があります。機能ごとに作り始めると、すぐに誰も保守しない資料集になります。

2つの層に分けて管理します。

- **商談用シート：** 買い手の状況、ヒアリングの質問、競合の確かな強み、証明済みの違い、反論への応答、次の行動。営業担当者が会議前に目を通せる量にします。
- **根拠メモ：** 正確な出典、プランの制約、テスト結果、日付、担当者、撤回した表現。商談用シートを調査報告書に変えずに、その内容を裏づけます。

最初は創業者が両方を担当しても構いません。チームが大きくなったら、プロダクトマーケティングが表現を管理し、製品の専門担当者が技術的な主張を検証し、商談責任者が買い手の状況を提供できます。仕事には個人名を割り当ててください。「営業とマーケティング」では承認手順になりません。

## 営業バトルカードのテンプレート

[Markdown の完全テンプレート](/downloads/sales-battlecard-template.ja.md)と [Browse AI の記入例](/downloads/sales-battlecard-browse-ai-example.ja.md)をダウンロードして、社内 wiki や CRM にコピーしてください。以下の質問は記入のための設問であり、見込み客にそのまま見せる文章ではありません。

編集できる Word 版の[未記入テンプレート](/downloads/sales-battlecard-template.ja.docx)と[記入例](/downloads/sales-battlecard-browse-ai-example.ja.docx)も利用できます。

### 商談用シート：営業担当者が会議で必要とする情報

| 項目 | 記入する内容 | 品質の確認 |
| --- | --- | --- |
| 買い手と検討のきっかけ | 役割、達成すべき仕事、現在のツール、今評価する理由。 | 自社製品の説明をせずに、この商談が生まれた理由を説明できるか。 |
| 競合の確かな強み | 合理的な買い手が競合を選ぶ理由。 | 買い手が公平な説明だと認めるか。 |
| 適合性と案件の見極め | 自社の提案を評価する価値がある条件と、合わない条件。 | ある回答によって、提案を押し続けるのをやめられるか。 |
| ヒアリング | 質問、追加質問、各回答によって変わる判断。 | 競合を攻撃する誘導ではなく、要件を明らかにする質問か。 |
| 証明済みの違い | 買い手の要件 → 確認済みの違い → 実務上の影響 → 証拠。 | 比較する両者について根拠があるか。 |
| 反論への応答 | 妥当な指摘を認め、要件を明確にし、証拠を示し、次の行動に合意する。 | 営業担当者が数文で自然に話せるか。 |
| デモまたは評価 | 買い手の作業、テスト条件、合格基準、担当者。 | 両社が同じテストに取り組めるか。 |
| 費用と乗り換えの確認 | 対象プラン、利用量、追加オプション、移行作業、権限、契約日程。 | 実際に利用できる完全な提供内容を比較しているか。 |
| 次の行動 | 氏名を記した担当者、成果物、合意した日付。 | 最も重要な未解決の問いを解消するか。 |
| 言ってはいけないこと | 撤回済みまたは未確認の表現と、その代わりの案内。 | 古いスライドを見つけて修正できるか。 |

差別化の主張は「それで何が変わるのか」という問いに答えられる必要があります。たとえば、現在のツールがすでに S3 に対応している買い手に「S3 対応」と言っても、意味はほとんどありません。「運用責任者が AWS 管理者を待たずにこのエクスポートを完了できる」なら重要かもしれません。ただし、その作業を実演し、競合が実際に求める条件も確認した後に限ります。

重要な比較には、次の作業用の形式を使ってください。

```text
買い手の要件：
この商談で重要な理由：
競合の確認済みの機能と制約：
自社の確認済みの機能と制約：
意味のある違いがあれば、その内容：
証拠または再現可能なデモ：
聞くべき質問：
承認済みの表現：
この違いが重要でなくなる条件：
次の行動：
```

### 根拠メモ：その表現を安心して使える理由

重要な主張には S3-01 のような固定 ID を付けます。商談用シートの該当する文の横にも ID を記載すれば、出典が変わるたびにすべての文を手作業で探す必要はありません。

```text
主張 ID：
正確な主張：
適用範囲：製品 / プラン / 地域 / 公開段階 / 買い手の構成
競合の出典 URL、抜粋、保存したキャプチャ：
自社の出典 URL またはテストの証拠：
観測した変更日（わかる場合）：
最終確認日：
確認者：
根拠の種類：ベンダー文書 / テスト済み / 買い手からの報告 / 未確認
状態：使用可 / 使用前に要確認 / 撤回済み
承認済みの表現と必要な条件説明：
この根拠では証明できないこと：
次回確認日または確認のきっかけ：
影響を受けるカード、資料、定型文、進行中の商談：

変更履歴
日付 | 主張 ID | 旧表現 | 置き換え | 理由 | 担当者
```

**根拠の種類と状態は、別の問いに答えます。** 「ベンダー文書」は出典の性質です。「使用可」は、その出典が示す範囲内で、担当者が特定の一文を承認したという意味です。ベンダーが文書化した連携は、その連携が存在するという使用可能な根拠になります。一方、買い手の環境での性能は未検証のままかもしれません。

買い手からの報告は、許可を得て範囲を明確にし、その買い手の経験として記録します。ある移行が難しかったからといって、すべての顧客が同じ経験をするとは証明できません。機密性のある商談メモは、顧客向け資料に含めないでください。

必要な事実が足りない場合は **使用前に要確認** にします。証拠が表現と矛盾している場合や、適用範囲の示し方が誤解を招く場合は **撤回済み** にします。どちらでもカード全体を止める必要はありません。営業担当者はヒアリングの質問をし、ほかの確認済みの主張を使えます。

![個別の主張カードの上に置かれた真鍮の日付印。主張ごとの確認を表しています。](/img/blog/battlecard-claim-dates.png)

## バトルカードの記入例：Browse AI と Amazon S3

当社の [Browse AI の記録](/companies/browse/)では、データの出力先への対応が目に留まりました。その手がかりを追い、Browse AI の現在の [Amazon S3 ページ](https://www.browse.ai/integrations/amazon-s3)と[設定ガイド](https://help.browse.ai/en/articles/10715592-aws-s3-integration-guide)を確認しました。機能欄のチェックマークよりも、バトルカードの根拠としてはるかに役立ちます。

Browse AI は CSV と JSON のエクスポート、すべてのプランで追加の連携料金なしに S3 を使えること、通常のロボット実行クレジットを消費することを文書化しています。設定ガイドでは、CloudFormation スタックと IAM ロールを作成する権限を持つ AWS アカウント、および出力先のバケットが必要です。こうした具体的な事実を使って考えます。

以下は、**架空の競合データ抽出ベンダーを想定したバトルカードの作成例**です。買い手の状況と営業向けの提案表現は説明用です。どちらの製品も顧客環境ではテストしておらず、架空の売り手に優位性があると主張するものではありません。

### 買い手と適合性

**状況：** 運用責任者が、定期的に取得するウェブデータを自社の S3 バケットへ届けたいと考えています。権限は AWS 管理者が管理しています。買い手は Browse AI と別の抽出ツールのどちらを使うか評価しています。

**Browse AI の確かな強み：** 必要な出力先とファイル形式への対応が、すでに文書化されています。S3 にデータを置きたい買い手には、候補に入れる理由があります。その強みを「単なる連携」と片づけてはいけません。

**案件の見極め：** 作業のどこが難しいのかを確認します。正しい項目を抽出すること、AWS アクセスを承認すること、想定どおりのファイルを届けること、実行失敗から復旧することは、それぞれ別の仕事です。買い手が本当に支援を必要とする仕事で比較してください。

**置き換えが適さない条件：** Browse AI が、抽出、アクセス、後続処理の要件を許容できる費用ですでに満たしているなら、連携のチェック項目だけでは乗り換える理由として弱すぎます。移行を提案する前に、実際の未解決課題を確かめてください。

### 判断につながるヒアリング

| 質問 | 追加質問 | 回答によって変わること |
| --- | --- | --- |
| 「出力したファイルは何が読み込みますか」 | 「CSV と JSON のどちらか、特定の項目名、決まったフォルダー構成が必要ですか」 | 両社が生成すべき出力サンプルを定義する。 |
| 「AWS 接続を承認できるのは誰ですか」 | 「必要な IAM ロールと CloudFormation スタックを作成できますか」 | 導入上の依存条件と、参加してもらう人を特定する。 |
| 「データはどの程度新しい必要がありますか」 | 「エクスポートが遅れたり重複したりすると、後続処理に何が起きますか」 | 配信と障害対応の受け入れテストを定める。 |
| 「設定後は誰が担当しますか」 | 「動かなくなったら、誰に通知が届き、誰が復旧しますか」 | 継続的な作業について意味のある話し合いを始める。 |

これらの質問は、Browse AI が要件を満たさないと示唆するものではありません。提供内容を比較する前に、何を確かめるべきかを定めます。

### 主張の記録と反論への応答

**S3-01 — 使用可、ベンダー文書、2026年9月10日確認：** Browse AI は CSV と JSON のエクスポートが可能な S3 連携を文書化しています。FAQ では全プランに含まれると説明していますが、通常のロボット実行クレジットは引き続き適用されます。設定に必要な AWS 権限はガイドに記載されています。

**この架空の表現は撤回：** 「Browse AI は自社のクラウドストレージに出力できません」

**これも避ける：** 「S3 エクスポートは無料なので、利用コストはかかりません」。連携の料金と、抽出を実行する費用は別のものです。

**買い手の反論：** 「Browse AI はすでに S3 にデータを送れます」

**応答の提案：** 「はい、その連携は文書化されています。後続処理が必要とする出力と、それを誰が保守するかを比較しましょう。両方のツールが要件を満たすなら、残る抽出、運用、契約・費用面の違いで判断するのがよいでしょう」

この応答は、買い手の情報が正しいと認めています。同時に、存在しない機能差を作らずに、営業担当者へ有用な次の行動を示します。

### 公平な検証の進め方

デモの前に買い手と要件を合意します。データ抽出の許可を得たうえで、両社に同じ元ページと必須項目を使い、出力先は本番環境以外にします。

1. **サンプルを作成する。** 合意した項目を買い手が選んだ形式で出力します。項目の抜け、項目名、欠損値の表現を確認します。
2. **配信を調べる。** 意図したバケットとプレフィックスにファイルが届くことを確認します。後続処理が実際の出力を取り込めるかを確かめます。
3. **アクセスを確認する。** AWS の責任者に権限と設定手順を確認してもらいます。「ノーコード」という宣伝から推測せず、買い手に必要な作業を記録します。
4. **繰り返し実行をテストする。** 管理されたテスト用のデータ源で値を変更し、再実行します。更新、ファイル名、重複がどう扱われるかを記録します。
5. **復旧と費用を確認する。** 失敗がどう通知され、どう復旧するかを聞き、テストでの実際の利用量を記録します。残るサポート対応や定期的な運用作業を特定します。

合格基準は、買い手が必要とする出力、許可されたアクセス、合意した配信動作です。ここで示しているのはテストの提案であり、結果の報告ではありません。実際の証拠が得られたら、カードに追加してください。

**次の行動：** 商談責任者がサンプル仕様を送り、買い手側の AWS 管理者がアクセス要件を確認し、製品の専門担当者が両方の出力と未解決の問いを記録します。カードに任意の締め切りを置くのではなく、関係者と日付を合意してください。

## 参考になるバトルカードの追加事例3件

以下の事例は、2026年9月10日に確認したベンダー文書を使っています。カードが陥りうる、異なる種類の誤りを示すものです。過去の発表には日付を明記しており、今週発見した4件の製品変更として紹介しているわけではありません。悪い表現と営業担当者の応答例は教材用で、実在する営業チームからの引用ではありません。

### Notion：昔の追加料金の話ではなく、現在のセット内容を比較する

「Notion AI は必ず別料金」と書いたカードは、提供内容の重要な変更を見落とします。Notion は [2025年5月13日のリリース](https://www.notion.com/releases/2025-05-13)で、Business と Enterprise に Notion AI を含めると発表し、企業内検索、リサーチモード、AI 会議メモを挙げていました。

[現在の料金ページ](https://www.notion.com/pricing)では、Business に Notion Agent、AI Meeting Notes、Enterprise Search を掲載しています。一方、Custom Agents は Notion クレジットを使用すると別に説明されています。したがって、昔の発表にある「無制限」という言葉だけでは、買い手が求める現在の具体的な機能の確認に代わりません。

**買い手の状況：** チームはすでに Notion に料金を払い、別の AI 検索ツールや会議ツールを評価しています。最初に気になるのは、現在の契約だけで十分ではないか、という点でしょう。

| カードの要素 | 役立つ記入内容 |
| --- | --- |
| 撤回する | 「Notion AI のすべての機能は個別の有料オプションです」 |
| 逆方向の言いすぎも避ける | 「Notion でのすべての AI 作業は利用料金なしで含まれています」 |
| 最初の質問 | 「Notion のどのプランを利用し、会議メモ、検索、自律的なタスクのどの仕事を比較していますか」 |
| 追加質問 | 「その仕事では、どの情報源、権限、出力が必要ですか」 |
| 応答の提案 | 「必要な機能の一部は、すでに含まれているかもしれません。別のツールに料金を払う前に、実際の業務手順をテストしましょう」 |
| 証明方法 | 必要な情報源に対して、同じ許可済みの質問群または会議の作業を実行する。回答の質、引用、アクセス制御、情報の欠落を確認する。 |

**営業の進め方が変わる点：** 付属の機能が要件を満たすなら、単独製品の競合は追加購入の理由を実証する必要があります。不十分なら、満たせなかった要件を具体的に示し、自社の結果を見せてください。「より専門的です」は説明です。買い手の作業で再現できる違いが証拠になります。

**費用の確認：** 買い手が実際に契約している現在のプランと、代替製品の利用に必要な内容全体を比較します。必要なアップグレード、席数、従量課金機能、導入作業を記録してください。有料の前提条件を省いたまま、定価だけの比較をカードに載せないことです。

### Slack：履歴へのアクセスと完全削除を分ける

「Slack は90日で全部消える」という言い方は、複数の異なるルールをひとまとめにして誤解を招きます。

Slack の[無料ワークスペースの文書](https://slack.com/intl/en-ie/help/articles/115002422943-Usage-limits-for-free-workspaces)では、直近90日間のメッセージとファイルにアクセスできると説明しています。[保持期間の文書](https://slack.com/help/articles/203457187-Customize-data-retention-in-Slack)では、無料ワークスペースのオーナーが90日または1年の保持を選べます。完全削除と関連する例外も記載されており、Enterprise 組織がスポンサーとなる特定の Slack Connect メッセージなどが含まれます。有料プランの設定は異なります。

**買い手の状況：** 過去の決定を探し出せないため、チームが共同作業ツールを評価しています。本当の要件は、検索できる履歴、保持ポリシー、エクスポート権限、あるいは法的な要件かもしれません。それらを「履歴」という1つのチェック項目にまとめるべきではありません。

| カードの要素 | 役立つ記入内容 |
| --- | --- |
| 撤回する | 「Slack のメッセージはすべて90日後に削除されます」 |
| 最初の質問 | 「見つからないメッセージは、プランの履歴制限で表示されないのですか。それともワークスペースの保持設定で削除されたのですか」 |
| 追加質問 | 「従業員はどこまで過去を検索する必要があり、組織からは何を保持し、何を削除するよう求められていますか」 |
| 応答の提案 | 「プランと保持設定を別々に確認しましょう。アクセスの変更、ポリシーの変更、別製品のどれが必要か判断できます」 |
| 証明方法 | 許可されたテストデータで、対象プランの検索・取得、エクスポート権限、保持動作を検証する。例外も記録する。 |
| 約束しないこと | 完全に削除されたデータの復旧、または未確認の法的要件への適合。 |

**営業の進め方が変わる点：** 現在のサービスのアップグレードで、アクセスの問題が解消するかもしれません。別ツールへの移行は、消えたデータを戻せないまま移行作業だけを増やす場合があります。カードは、乗り換えを勧める前に営業担当者がその可能性を見つけられるものにします。

**移行の確認：** 買い手が実際に出力できるメッセージとファイル、承認できる人、移行先が取り込める内容を確かめます。ポリシーの解釈が必要な場合は、セキュリティまたは法務の責任者を加えてください。営業用の比較はコンプライアンス評価ではありません。

### Zoom：会社のアカウント名目ではなく、ホストのライセンスを確認する

カードに正しい数字が載っていても、適用する顧客を間違えることがあります。

Zoom の[会議時間制限の文書](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0059213)では、Basic ユーザーが主催するほぼすべての会議は40分に制限され、有料アカウント内の Basic ユーザーも対象だと説明しています。有料ライセンスを割り当てられたユーザーは、通常、最大30時間の会議を開けます。文書には、特定の Zoom Room の参加や、アイドル状態の会議に関する条件などの例外も記載されています。

**買い手の状況：** 会社は「Zoom に料金を払っている」と言っていますが、特定のホストの通話は依然として早く終了します。アカウントが有料というだけでは、そのホストの利用権限は確定しません。

| カードの要素 | 役立つ記入内容 |
| --- | --- |
| 撤回する | 「有料 Zoom アカウントの全ユーザーが長時間の会議を主催できます」 |
| これも避ける | 「Zoom の会議は40分までです」 |
| 最初の質問 | 「問題が起きた会議のホストには、どのライセンスが割り当てられていますか」 |
| 追加質問 | 「定期的に主催するのは誰で、どの種類の会議を開き、どれくらいの時間が必要ですか」 |
| 応答の提案 | 「まずホストに割り当てられたライセンスを確認しましょう。そのうえで、チームに実際に必要なライセンスと会議条件を比較できます」 |
| 証明方法 | 権限を持つ管理者がライセンスの割り当てを確認し、代表的な会議構成を文書上の制限と照合する。 |

**営業の進め方が変わる点：** 割り当てを直すだけで解消するかもしれません。より広いライセンスや業務手順の問題が残る場合は、主催者全体と必要な機能を比較します。管理上の問題を、競合に機能がないという証拠として示さないでください。

これらは異なる失敗の例です。存在する連携を「ない」と説明する、セット内容が古い、保持ルールから条件を落とす、利用権を別のユーザーに当てはめる。良いカードは、商談中に重要な区別を思い出しやすくします。

## 意思決定を軸に反論への応答を作る

反論の欄には、「使いやすい」「価値に集中する」以上の内容が必要です。現実を認め、根拠の確認へ進める応答を営業担当者に渡してください。

**認める → 明確にする → 証明する → 次の行動に合意する**、の4段階を使います。次の行動は、ありきたりなデモをもう一度押しつけるのではなく、買い手の不確かさを解消するものにします。

| 買い手の言葉 | 役立つ応答の型 | 必要な根拠 |
| --- | --- | --- |
| 「それはもうあります」 | 「そうかもしれません。まだ手間がかかるのはどこですか。置き換えを話す前に、そこをテストしましょう」 | 現在の機能、買い手の未充足要件、公平な比較の結果。 |
| 「先方のほうが安いです」 | 「どのプランと処理量を比較していますか。両方について必要な席数、利用量、設定作業を含めましょう」 | 比較可能な提供内容と、買い手に即した利用量の前提。 |
| 「乗り換えは大変すぎます」 | 「移すのが最も難しいのはどこですか。何を移行でき、誰が担当するか確認しましょう」 | エクスポート・インポートの制約、必要な権限、導入作業、日程。 |
| 「今ので十分です」 | 「現在の構成が要件を満たしているなら、変更する理由はないかもしれません。何がきっかけで評価を始めましたか」 | 売り手が好む機能ではなく、実在する未解決の必要性。 |

それぞれに対応する中止条件も書きます。買い手が未充足の要件を挙げられず、現在のツールが合意したテストを満たすなら、変更理由を作り続けるのはやめてください。案件として適格でないと判断した理由を記録します。架空の優位性が並ぶバトルカードより、そのフィードバックのほうが役立ちます。

創業者主導のチームなら、実際に受けた反論を1つ選び、同僚とカードの使い方を練習します。出典、プラン、「それで何が変わるか」を問い直してもらってください。長い説明なしでは答えが成り立たないなら、主張を短くするか、質問に置き換えます。

## 最初の週を過ぎても役立つカードにする

進行中の商談に使う主張から先に見直します。主張単位の変更確認リストを使い、新しい連携やプラン改訂が影響する文を特定できるようにします。[機能リリースの追跡ガイド](/ja/blog/competitor-feature-launch-tracking/)では、リリースノート、製品ページ、文書がその確認をどう分担するかを説明しています。

**シグナル → 動機 → 行動** は、観測と解釈を分ける助けになります。Browse AI は S3 出力を文書化しています。より多くのデータ業務に対応したいというのは、考えられる動機です。買い手が実際に行うエクスポートを検証するのが行動です。追加の証拠がなければ、動機は仮説のままです。営業が事実として話すための文ではありません。

小さなチームでも維持できる見直しルールを使います。

- **次の関連商談の前：** 矛盾が判明した主張を撤回し、争点になっている利用権限を確認し、重要な料金の不確かさを解消する。
- **週次の見直し：** 現在比較している競合への影響を調べ、新しいテストや表現が必要な主張を決める。
- **重要な評価や提案の前：** 出典と、買い手の正確なプラン、地域、構成を再確認する。週次の要約は、個別商談の約束を承認できない。
- **カードの定期見直し：** 使わない節を削除し、繰り返される反論を追加し、担当者を確認する。頻度は主張が変わる速さに応じて決める。

何が変わったかを営業に具体的に伝えます。「S3-01：S3 に出力できないという表現は使用を中止。Browse AI は全プランでの連携を文書化しています。出力と保守についての質問を使ってください。自社との比較テストは未完了です」。改訂したカードへリンクし、利用中の資料、メール定型文、商談メモを修正します。古いプレゼン資料から復活しないように、撤回した表現は変更履歴に残します。

カードが役立っているかを測ります。繰り返される反論、未回答の証拠の要求、営業担当者が疑問を持つ主張を記録します。受注率の変化を解釈する前に、対象の商談でカードが使われたかを確認してください。標本が小さい場合や案件構成が変わった場合、それだけではカードが改善を引き起こしたとはいえません。

カードが完成したと判断する前に、営業担当者1人に、買い手の質問、根拠を示せる回答、その出典、次の行動を、助けなしで探してもらいます。見つけられなければ、商談用シートを簡潔にしてください。詳細は根拠メモに残します。

## Competitor Tracker & Co. が役立つ場面

バトルカードの保管場所はあるものの、公開されている競合の変更が担当者の目をすり抜けてしまうチームに、Competitor Tracker & Co. は向いています。

- 「連携の不足が解消した可能性があれば教えてほしい」
- 「古い比較を再利用する前に、プランの変更を見せてほしい」
- 「変更されたページと証拠を添えた、短い確認リストがほしい」
- 「創業者とプロダクトマーケティングが、変化した主張の確認に時間を使えるようにしたい」

当社の AI エージェントの群れは、競合の公開ページを追跡し、日常的な編集を除き、月曜の調書を届けます。チームはその観測をカードに結びつけ、該当する主張を確認し、表現を承認します。[週次の競合調書テンプレート](/ja/blog/weekly-competitor-dossier-template/)が、その見直しの出発点になります。

公開情報の追跡では、非公開の受注・失注インタビューを用意したり、買い手の製品評価を実行したり、セキュリティや法務に関する主張を承認したりはできません。そうした情報は、適切な担当者とともに公開出典の横に保管します。API と MCP のアクセスにより、自社のエージェントが競合データを取得できます。それでも、最終的な営業上の約束には責任を持つ人が必要です。

効果は実務的です。買い手が「その機能は先方のプランにもう含まれています」と言ったとき、営業担当者はそれを認め、適切な追加質問をし、意思決定の話を続けられます。

[調書のサンプルを見る](/ja/demo/)、または Competitor Tracker & Co. と[調査を始める](/ja/#engage)。

— C. T. Lucky


---

Source: https://competitortracker.io/ja/blog/battlecards-go-stale-dossiers-do-not/
Updated: 2026-09-10