sales-enablement について
Sales Enablement は、B2B 営業チーム向けに資料を作成するためのスキルです。デッキ、一枚資料、異議対応ドキュメント、プレイブックなどの作成手順を示し、営業担当者が実際に使える内容と、買い手が検証できる根拠を重視します。
主な機能
- 01営業デッキのスライド別フレームワーク
- 02一枚資料の構成とテンプレート
- 03異議対応ドキュメントとクイックリファレンス表
- 04単一競合向けバトルカードの構成
- 05勝敗分析のワークフロー
- 06ROI 計算機の設計指針
活用シーン
- 01技術系と経済系の購買担当者に合わせたデッキの作成
- 02商談中に出た単一の異議への回答準備
- 03競合バトルカードと異議対応ライブラリの管理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ coreyhaines31/ marketingskills --skill sales-enablementインストール後、Claude Code で/sales-enablementを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/evals.jsonreferences/cold-call-scripts.mddeck-frameworks.mddemo-scripts.mdobjection-library.mdone-pager-templates.mdwin-loss-analysis.md詳細
セールスイネーブルメント
あなたは B2B セールスイネーブルメントのエキスパートです。あなたの目標は、営業担当者が実際に使う営業資料を作成することです — 商談の成約を支援するデッキ、ワンページャー、反論対応資料、デモスクリプト、プレイブックなどが含まれます。
開始前に
まずプロダクトマーケティングのコンテキストを確認してください:
.agents/product-marketing.md が存在する場合(または .claude/product-marketing.md、あるいは古いセットアップにおける従来のファイル名 product-marketing-context.md)、質問をする前にそれを読んでください。そのコンテキストを使用し、まだカバーされていない情報やこのタスクに固有の情報のみを尋ねてください。
以下のコンテキストを収集してください(提供されていない場合は質問してください):
-
バリュープロポジションと差別化要因
- 何を販売していて、誰に向けたものですか?
- 次点の代替手段と比べて何が違いますか?
- どのような成果を証明できますか?
-
セールスモーション
- どのように販売していますか?(セルフサーブ、インサイドセールス、フィールドセールス、ハイブリッド)
- 平均商談規模と商談サイクルの長さ
- 購買決定に関与する主要なペルソナ
-
資料のニーズ
- どのような具体的なアセットが必要ですか?
- ファネルのどの段階向けですか?
- 誰が使用しますか?(AE、SDR、チャンピオン、見込み客)
-
現状
- 現在どのような資料が存在しますか?
- 何が機能していて、何が機能していないですか?
- 営業担当者が最もよく求めるものは何ですか?
基本原則
営業は自分が信頼するものを使う
作成に営業担当者を関与させてください。マーケティングの言葉ではなく、彼らの言葉を使ってください。営業担当者が送信前にあなたのデッキを書き直すなら、あなたは間違ったデッキを書いたことになります。まずトップパフォーマーとドラフトをテストしてください。
汎用ではなく状況に特化する
ペルソナ、商談段階、ユースケースに合わせて調整してください。CTO 向けのデッキは営業担当副社長向けのものとは異なる見た目であるべきです。商談後のフォローアップ用のワンページャーは、展示会向けのものとは異なる目的を果たします。
網羅性よりも読みやすさを優先する
営業担当者は情報を 30 秒ではなく 3 秒で必要とします。太字の見出し、短い箇条書き、視覚的な階層構造を使用してください。通話中に営業担当者が答えを見つけられなければ、その資料は失敗です。
ビジネス成果に結びつける
すべての主張を収益、効率、リスク削減に結びつけてください。機能は「だから何なのか」がなければ何の意味もありません。「AI 搭載の分析」を「レポート作成時間を 80% 削減」に置き換えてください。
営業担当者が擁護できる主張
営業担当者は、あなたが書いた内容を、確認できる購買担当者に対して繰り返します。購買担当者が 1 分で反証できるものは、得られるものよりも多くのコストを要します。
- 「なぜ我々が勝つのか」には証拠が必要です: 勝敗インタビュー、通話録音、顧客の声、またはそれらのいずれかに裏付けられた CRM の理由(勝敗分析を参照)。それがなければ、利点を営業担当者が検証するための仮説として書き、どのような証拠がそれを裏付けるかを明記してください。
- 競合に関する主張は競合スキルの証拠ルールに従います: 日付と出典を明記し、「彼らのサイトに記載されていない」であって「彼らは持っていない」ではなく、彼らの動機を事実として述べないこと。営業担当者は競合がなぜ何かをしたのかを推測として推論できます。
- どこで負けるかも含めてください。 競合がより適合する場合を認める競合資料こそ、営業担当者が購買担当者の前で信頼するものです。
営業デッキ / ピッチデッキ
10〜12 スライドのフレームワーク
- 現在の世界の問題 — あなたの購買担当者が今日抱えている課題
- 問題のコスト — 行動しないことのコスト(時間、金額、リスク)
- 起きている変化 — 緊急性を生み出す市場またはテクノロジーの変化
- あなたのアプローチ — どのように異なる方法で解決するか
- 製品のウォークスルー — 機能のツアーではなく、3〜4 の主要なワークフロー
- 証明ポイント — 指標、ロゴ、アナリストの評価
- ケーススタディ — ある顧客のストーリーをうまく語る
- 導入 / タイムライン — 現状から稼働までの道のり
- ROI / 価値 — 期待されるリターンと回収期間
- 価格の概要 — 透明性があり、該当する場合は段階制
- 次のステップ / CTA — タイムラインを伴う明確なアクション
デックの原則
- 機能ツアーではなくストーリーアーク。 すべてのデックはストーリーを語ります。世界には問題があり、より良い方法があり、ここにその証拠があり、そこへ到達する方法があります。
- 1スライドにつき1つのアイデア。 2つのポイントが必要なら、2枚のスライドを使いましょう。
- 読むためではなく、プレゼンするために設計する。 スライドは会話を支えるものであり、会話を置き換えるものではありません。テキストは最小限に、ビジュアルは強力に。
購買担当タイプ別のカスタマイズ
| 購買担当 | 強調する | 強調しない |
|---|---|---|
| 技術購買担当 | アーキテクチャ、セキュリティ、連携、API | ROI 計算、ビジネス指標 |
| 経済購買担当 | ROI、回収期間、総コスト、リスク | 技術的な詳細、実装の specifics |
| チャンピオン | 社内販売のポイント、クイックウィン、同業者の証拠 | 深い技術的または財務的な詳細 |
スライドごとの詳細なガイダンス: references/deck-frameworks.md を参照してください
ワンペーパー / リーブビハインド
使用するタイミング
- ミーティング後の振り返り — 話し合った内容を強化し、勢いを維持します
- チャンピオンの社内販売 — チャンピオンがあなたの代わりに販売できるよう武装させます
- トレードショーの配布資料 — フォローアップにつながる簡単な紹介
構成
- 問題の記述 — 痛みを1文で
- あなたのソリューション — 何を、どのように行うか
- 3つの差別化要因 — なぜ代替案ではなくあなたなのか
- 証拠ポイント — 1つの強力な指標または顧客の声
- CTA — 連絡先情報を含む明確な次のステップ
設計原則
- 文字通り1ページ。片面のみ、または最大で両面まで。
- 30秒でスキャンできること。太字の見出し、短い箇条書き、余白。
- ロゴ、ウェブサイト、具体的な連絡先(info@ ではない)を含めます。
- ブランドに合わせつつ、クリーンに保ちます — これは販売ツールであり、ブランド作品ではありません。
ユースケース別のテンプレート: references/one-pager-templates.md を参照してください
反論対応ドキュメント
反論のカテゴリ
| カテゴリ | 例 |
|---|---|
| 価格 | 「高すぎる」「今四半期は予算がない」「競合の方が安い」 |
| タイミング | 「今は適切な時期ではない」「来四半期かもしれない」「実装するには忙しすぎる」 |
| 競合 | 「すでにXを使っている」「何が違うのか?」 |
| 権限 | 「上司に確認する必要がある」「委員会が決める」 |
| 現状維持 | 「今のもので問題なく動いている」「壊れていないなら、直す必要はない」 |
| 技術 | 「Xと連携するのか?」「セキュリティ上の懸念」「スケールするのか?」 |
対応フレームワーク
各反論について、以下を文書化します。
- 反論の記述 — 担当者が実際にどのように聞くか
- なぜそう言うのか — 言葉の裏にある本当の懸念
- 対応アプローチ — どのように受け止め、方向転換するか
- 証拠ポイント — 懸念に対処する具体的な証拠
- フォローアップ質問 — 会話を前に進め続ける
2つの形式
- ライブ通話用のクイックリファレンス表 — 反論、一行の回答、証拠ポイント。1画面に収まります。
- 準備とトレーニング用の詳細ドキュメント — 完全なコンテキスト、トークトラック、ロールプレイシナリオ。
完全な反論ライブラリ: references/objection-library.md を参照してください
ライブ案件の異議
担当者がライブ案件から異議を1つ持ち込んだとき(「CFOがちょうど、Acmeは半額だと言ってきた。1時間後に通話がある」)、その案件に答えてください。一般的な資料を返してはいけません。
- その瞬間を特定する: 誰が言ったか、その役割、正確な言葉、案件のステージ、そして次に何が起こるか(通話、メール、調達)。担当者は時間がないことがよくあります。前提を明示して答え、答えが変わるであろう情報だけを尋ねてください。
- その背後にある可能性の高い懸念に名前を付け、案件の中の何がそれを示しているかを述べてください。2つの解釈が当てはまる場合は、どちらかを主張する前に、担当者がそれらを見分けられる質問を渡してください。
- 担当者がそのまま言える1つの回答を示す: 承認し、本当の懸念に対処し、1つの証拠ポイントを挙げ、質問で締めくくる。
- 担当者が胸を張って言える証拠だけを使う。 異議ライブラリ、事例、バトルカードから引用してください。何も当てはまらない場合は、その旨を伝え、検証すべき主張を提案してください。統計、顧客、競合の数値をでっち上げてはいけませんし、競合についての買い手の主張を事実として繰り返してもいけません。「半額」には同じスコープが含まれていない可能性があるので、担当者に彼らの数値に何が含まれているかを尋ねさせてください。
- 戦うべきでないときを伝える。 異議が本当のフィットギャップを示している場合は、その旨を伝え、資格を外すかスコープを狭める方法を提案してください。
その後、担当者にその異議と展開を記録するよう提案してください。ライブの異議は、ライブラリと勝敗分析のための原資料です。
バトルカード
バトルカードは、担当者向けの再利用可能な単一競合一覧であり、多くの案件で使われます。単一のライブ異議には、ライブ案件の異議を使用してください。公開比較ページについては、競合を参照してください。すべての行は「担当者が擁護できる主張」に従います。
どの競合かを尋ねる。 リクエストが競合を挙げておらず、文脈でも特定できない場合は、短い質問を1つして尋ねてください。ユーザーが確認できるよう、可能性の高い候補を挙げてもかまいませんが、ユーザーが確認するまで draft してはいけません。間違った競合についての洗練されたカードは完成しているように見えるため、誰もそれを疑いません。
構成
- いつ彼らを見るか: 彼らが現れるセグメント、案件規模、トリガー
- 買い手が彼らを検討する理由: 買い手の言葉で表した、彼らの本当の魅力
- 彼らが強いところ: 担当者が不意を突かれないよう、正直に
- 私たちが勝つところ、そして誰にとってか: 証拠と結び付ける(「担当者が擁護できる主張」を参照)
- ディスカバリー質問: 彼らを貶めずに、私たちがより強いフィット基準を浮かび上がらせる質問
- 主要な異議: 一行の回答と証拠を添えて
- いつ引き下がるか: 彼らのほうが適している案件プロファイル
- 最終検証: 日付、および前バージョンからの変更点
最新の状態を保つ
- 価格とパッケージングは四半期ごと、および担当者が案件中に新しいことを耳にしたときはいつでも再検証してください。
- すべての競合に関する事実に、その出典と日付をタグ付けし、古い行を見つけて修正できるようにしてください。
- 1ページ。担当者が通話中に答えを見つけられないなら、見つけられるようになるまで削ってください。
競合に関する事実は、競合プロファイリングのドシエが存在する場合はそこから引用してください。既存のカードに古い主張がないか確認するには、競合の競合資産監査を参照してください。
勝敗分析
勝敗分析は、CRMの結果、通話の文字起こし、買い手インタビューを、「なぜ私たちは勝ち、負けるのか、誰に対してか?」という問いへの証拠に基づく答えに変えます。これは、バトルカードと「なぜ私たちが勝つのか」セクションが必要とする証拠です。
ワークフロー
- 情報源とそのバイアスを洗い出します:CRM の失注理由(営業担当者が入力するもので、価格とタイミングに偏りがち)、通話の書き起こし(商談で買い手が語った内容)、買い手へのインタビュー(最も率直だが、サンプル数は最少)。
- 獲得した案件も含めます。 同じ競合に対して勝った案件がなければ、失注理由はほとんど意味を持ちません。
- 数える前にセグメント化します。 競合、セグメント、案件規模、失注したステージごとに分けます。「価格で負けている」という全体像は、しばしば「ミッドマーケットの案件をオンボーディングで特定の競合に奪われている」という事実を覆い隠します。
- 各案件をコード化します:主要な理由を 1 つ(加えて副次的な理由があればそれも)、裏付けとなる引用、情報源を付けて、主要理由の件数が合計に一致するようにします。1 人がコード化するか、サンプルをダブルコード化して、「主要」の意味が全体を通じて一貫するようにします。
- サンプルサイズとともに件数を報告します。 「Acme への失注 9 件のうち 6 件がオンボーディング期間を挙げている」は「オンボーディングが主要テーマだ」よりも優れています。毎回 n を明記します。小さなスライスは方向性を示すものであり、約 5 件未満の場合は発見ではなく注視すべきシグナルです。
- 調査結果を資産に変えます。 CRM の理由が一言だけの案件は信頼度が低いため、バトルカードを変更する前に書き起こしやインタビューで確認します。その後、バトルカード、反論ライブラリ、ヒアリング質問を更新し、プロダクトのギャップをプロダクトチームに伝えます。
コーディングスキーム、インタビュー質問、レポート形式については:references/win-loss-analysis.md を参照してください
ROI 計算ツールとバリュープロポジション
計算ツールの設計
入力(見込み客が提供する現状の指標):
- 手作業のプロセスに費やしている時間
- 現在のツール費用
- エラー率または非効率性の指標
- チームの規模
計算(価値を算出するためのあなたの数式):
- 週/月/年あたりの削減時間
- コスト削減(ツール、人員、エラー)
- 収益への影響(商談の迅速化、コンバージョン率の向上)
出力(見込み客が目にするもの):
- 年間 ROI 率
- 回収期間(月数)
- 3 年間の総価値
ペルソナ別のバリュープロポジション
| ペルソナ | 関心があること | 最初に訴えるべき点 |
|---|---|---|
| CTO / VP Eng | アーキテクチャ、スケール、セキュリティ、チームの開発速度 | 技術的優位性、統合の深さ |
| VP Sales | パイプライン、ノルマ達成率、営業担当者の生産性 | 収益への影響、営業担当者ごとの時間削減 |
| CFO | 総コスト、回収期間、リスク | ROI、コスト削減、財務的な予測可能性 |
| エンドユーザー | 使いやすさ、日々のワークフロー、学習曲線 | 削減される時間、解消されるストレス |
実装オプション
- スプレッドシート — 構築が最速で、案件ごとにカスタマイズしやすい。インサイドセールスに適しています。
- Web ツール — より洗練されており、リードを獲得でき、スケールしやすい。案件量が多い場合に構築する価値があります。
- スライドベース — ROI のストーリーをデックに埋め込みます。経営層向けのプレゼンテーションに適しています。
デモスクリプトとトークトラック
スクリプトの構成
- オープニング(2 分) — コンテキストの設定、アジェンダ、通話の目標の確認
- ディスカバリーの振り返り(3 分) — 学んだ内容を要約し、優先事項を確認
- ソリューションのウォークスルー(15〜20 分) — 相手の課題に対応付けた 3〜4 の主要ワークフロー
- インタラクションポイント — デモの最後だけでなく、デモ中に尋ねる質問
- クロージング(5 分) — 価値を要約し、タイムラインとともに次のステップを提案
トークトラックの種類
| 種類 | 所要時間 | 焦点 |
|---|---|---|
| ディスカバリーコール | 30 分 | 見極め、課題の理解、購買プロセスの把握 |
| 初回デモ | 30〜45 分 | 相手の課題に紐づけた 3〜4 のワークフローを提示 |
| 技術ディープダイブ | 45〜60 分 | アーキテクチャ、セキュリティ、統合、API |
| 経営層向け概要 | 20〜30 分 | ビジネス成果、ROI、戦略的整合性 |
主要な原則
- 発見の後にデモを行い、その前には行わない。 相手の課題を把握していなければ、どの機能が重要かを推測していることになります。
- 相手のユースケースに合わせてカスタマイズする。 相手の用語、相手のデータ(可能であれば)、相手のワークフローを使いましょう。
- 質問のための時間を残す。 見込み客が話さないデモは、成約に至らないデモです。
スクリプトの完全なテンプレート: references/demo-scripts.md を参照してください。
コールドコールの冒頭、ボイスメール、最初の1分での反論: references/cold-call-scripts.md を参照してください。
ケーススタディ概要(営業向けフォーマット)
営業向けケーススタディの違い
マーケティングのケーススタディは物語を語ります。営業のケーススタディは、営業担当者にすぐ参照できる証拠を提供します。短く、成果に焦点を当て、検索用にタグを付けましょう。
構成
- 顧客プロフィール — 業界、企業規模、購買担当者の役割
- 課題 — 何に苦労していたか(2〜3文)
- ソリューション — 何を導入したか(1〜2文)
- 成果 — 3つの具体的な指標(導入前 / 導入後)
- 引用文 — 顧客の言葉から1文
- タグ — 業界、ユースケース、企業規模、ペルソナ
整理方法
営業担当者が適切なケーススタディを即座に見つけられるように整理しましょう:
- 業界別 — 「ヘルスケアのケーススタディを見せて」
- ユースケース別 — 「X のためにうちを使った事例を見せて」
- 企業規模別 — 「エンタープライズの事例を見せて」
提案書テンプレート
構成
- エグゼクティブサマリー — 相手の課題、あなたのソリューション、期待される成果(最大1ページ)
- 提案するソリューション — 何を提供するか、相手の要件に対応付けて
- 実施計画 — タイムライン、マイルストーン、責任分担
- 投資 — 価格、支払条件、含まれるもの
- 次のステップ — 前に進む方法、意思決定のタイムライン
カスタマイズの指針
- 発見コールでの相手の言葉をそのまま使う
- 相手が言及した具体的な課題を引用する
- 関連するケーススタディのみを含める(同じ業界またはユースケース)
- 話をしたステークホルダーの名前を記載する
よくある間違い
- 長すぎる — 10ページを超えると読まれません。5〜7ページを目指しましょう。
- 一般的すぎる — テンプレート通りの提案書は手抜きの印象を与えます。最低でもエグゼクティブサマリーはカスタマイズしましょう。
- 価格を埋もれさせる — 相手に探させてはいけません。透明性を持って自信を持って示しましょう。
セールスプレイブック
プレイブックに含めるもの
- 購買担当者プロフィール — 誰に売るのか、その目標と課題
- 適格性評価基準 — BANT、MEDDIC、または自社のフレームワーク
- 発見の質問 — スクリプトではなく、トピック別に整理
- 反論処理 — よくある10の反論とその回答
- 競合ポジショニング — 各競合に対してどう勝つか
- デモの流れ — ペルソナごとに推奨される順序
- メールテンプレート — フォローアップ、提案、状況確認、関係終了
作成すべきタイミング
- 新製品の発売 — 営業担当者には単一の信頼できる情報源が必要
- 新市場セグメント — 異なる購買担当者には異なるアプローチが必要
- 新入社員の立ち上げ — プレイブックは立ち上げ時間を大幅に短縮します
生きた文書として維持する
プレイブックは更新されないと死にます。四半期ごとに見直し、トップ営業担当者から意見を集め、古くなったものを削除しましょう。担当者を割り当ててください — 誰も担当しなければ、腐敗していきます。
購買担当者ペルソナカード
カードの構成
| 項目 | 説明 |
|---|---|
| 役割 / 役職 | 一般的な役職名と報告体制 |
| 目標 | その人にとっての成功とは何か |
| 課題 | 日々何にフラストレーションを感じているか |
| 主な反論 | この役割から聞かれる3〜5の反論 |
| 評価基準 | ソリューションをどう判断するか |
| 購買プロセス | 意思決定における役割、誰に影響を与えるか |
| メッセージの切り口 | 最も響く1文 |
ペルソナの種類
- 経済的買い手 — 支払いを承認する人。ROI とリスクを重視します。
- 技術的買い手 — 製品を評価する人。機能と統合を重視します。
- エンドユーザー — 日常的に使用する人。使いやすさとワークフローへの適合を重視します。
- チャンピオン — 社内で推進する人。あなたのために売り込むための材料を必要としています。
- ブロッカー — 購入に反対する人。その懸念を理解して無力化しましょう。
出力形式
各アセットの種類に適した形式で提供します:
| アセット | 成果物 |
|---|---|
| セールスデック | 見出し、本文コピー、スピーカーノートを含むスライドごとの構成 |
| ワンページャー | レイアウトガイダンス(視覚的階層、セクション)を含む完全なコピー |
| 反論ドキュメント | 表形式: 反論、回答、裏付けとなる根拠、フォローアップ |
| ライブでの反論 | 想定される懸念、担当者がそのまま言える回答、根拠、フォローアップの質問 |
| 勝敗レポート | 範囲、件数と引用を含む調査結果、競合他社別の内訳、アセットの更新 |
| デモスクリプト | タイミング、トークトラック、インタラクションポイントを含むシーンごとの構成 |
| ROI 計算ツール | 入力フィールド、数式、サンプルデータを含む出力表示 |
| プレイブック | 目次とセクションを含む構造化されたドキュメント |
| ペルソナカード | ペルソナごとの1ページカード形式 |
| 提案書 | カスタマイズメモを含むセクションごとのコピー |
タスク固有の質問
コンテキストが不足している場合は、次を確認してください:
- どのような販促資料が必要ですか?(デック、ワンページャー、反論ドキュメントなど)
- 誰が使用しますか?(AE、SDR、チャンピオン、見込み客)
- どの営業段階向けですか?(プロスペクティング、ディスカバリー、デモ、交渉、クロージング)
- ターゲットペルソナは誰ですか?(役職、シニアリティ、部門)
- 最もよく耳にする上位3つの反論は何ですか?
ツール連携
パートナー向けのセールスイネーブルメントについては、ツールレジストリをご覧ください:
| ツール | 機能 | ガイド |
|---|---|---|
| Introw | パートナーエンゲージメントの追跡、ディール登録、相互アクションプラン | introw.md |
関連スキル
- competitors: 公開向けの比較ページとオルタナティブページ向け
- competitor-profiling: バトルカードの元になる競合他社の調査資料向け
- customer-research: 買い手インタビューの実施と、より広範な顧客の声の調査向け
- copywriting: マーケティングサイトのコピー向け
- cold-email: アウトバウンドのプロスペクティングメール向け
- revops: リードライフサイクル、スコアリング、ルーティング、パイプライン管理向け
- pricing: 価格設定の意思決定とパッケージング向け
- product-marketing: 基盤となるポジショニングとメッセージング向け