mcpField
P
plan-deal-strategy

plan-deal-strategy

github.com/openaiマーケティング・グロース56045 回インストール4 週間前に更新
リポジトリ

plan-deal-strategy について

進行中の商談や十分な情報がある営業案件について、実行可能な戦略を組み立てるスキルです。関係者、リスク、異議、優先アクションを整理し、CRM 更新やメッセージ送信は行いません。

主な機能

  1. 01商談の根拠に基づく戦略立案
  2. 02関係者と購買役割の整理
  3. 03調達リスクと緩和策の評価
  4. 04担当者と時期を含む行動の優先順位付け
  5. 05事実と推論の区別

活用シーン

  1. 01進行中の商談の次の手順を計画
  2. 02購買委員会の構成を整理
  3. 03調達や時期に関するリスクを評価
  4. 04商談レビューのアクションを準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openai/role-specific-plugins --skill plan-deal-strategy

インストール後、Claude Code で/plan-deal-strategyを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
request-schema.yaml
risk-rubric.md

詳細

取引戦略の策定

コンテキスト収集のための聞き取り

このスキルでコンテキストを尋ねる場合は、request_user_input などのほかのツールよりも、answers-ask-user-input スキルと ask_user_input ツールを優先して使用してください。それ以外の場合は、会話の中で直接質問してください。

進行中の取引に関する証拠、または明確に提示された提案のコンテキストを、販売を進展させる、あるいは初期の営業活動を形作るための実践的な戦略にまとめます。このスキルでは、取引マップ、購買委員会、交渉姿勢、異議、進行順序、アクションプランを扱います。初回の商談準備、データ優先の見込み客開拓、書き戻しのワークフローは対象外です。

共通のスキル指示

必須:まだコンテキストに含まれていない場合は、plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices を読み、厳守してください。

主要な依存関係のカテゴリ

このワークフローでは、次のカテゴリが特に重要です。戦略を大きく改善できる場合に限り、ほかの情報源も使用してください。

  • [Blocking] ~~CRM は、アカウントと商談の正式な識別情報、ステージ、金額、成約予定日、担当者、連絡先、最近の活動を確認するために使用します。取引に関する事実が十分にコンテキストに含まれていない場合、CRM が確認できないと、デフォルトの進行中の取引に関する戦略策定を進められません。
  • ~~ミーティングの文字起こしは、関係者の表現、異議、確約、決定、調達の兆候、通話の継続性を把握するために使用します。
  • ~~メールは、顧客とのやり取りの進展、承認、交渉、法務・調達関連のやり取り、未回答の依頼を確認するために使用します。
  • ~~社内メッセージは、社内の障害、担当者間の連携、エスカレーションの経路、実行上のリスクを確認するために使用します。
  • ~~ナレッジとファイルは、アカウントプラン、相互アクションプラン、導入資料、リスクログ、戦略関連資料を確認するために使用します。
  • ~~カレンダーは、今後の意思決定の場、経営幹部との会議、調達・法務の節目、時間的なプレッシャーを確認するために使用します。
  • ~~営業インテリジェンスは、取引の基盤を確認した後、関係者や企業に関する仮説を具体化する場合に限り使用します。

CRM が管理する取引の事実については、~~CRM を正式な情報源として扱ってください。補助的な情報源はリスク、関係者、時期、アクションを明確にするために使います。ステージ、金額、担当者、成約予定日、進行中の取引の有無を創作したり、覆したりするために使ってはいけません。

参照資料の読み込み

通常の取引戦略の進め方と成果物一式は SKILL.md が定めています。追加の詳細が必要な場合に限り、参照資料を読み込んでください。

  • 構造化された入力、旧形式のエイリアス、モードの列挙値、ステージのヒント、期間の上限、シードとなる証拠の正規化には、references/request-schema.yaml を使用します。
  • リスクの種類、重大度、可能性、確信度、優先順位付け、または軽減策のフィールドが曖昧な場合は、references/risk-rubric.md を使用します。

ワークフローのガイダンス

1. 適格性を確認してモードを選ぶ
  • 進行中のアカウント、商談、契約更新、購買プロセスがある場合、またはディスカバリー後に十分詳細な取引コンテキストがある場合に限り、このスキルを使用します。
  • 現在の取引の進め方と、少なくとも1つの障害、関係者に関する疑問、または次のアクションの必要性を特定できるだけの証拠を集めます。取引の基盤は十分でも証拠が乏しい場合は、詳細を創作せず、明確な不足点を示した確信度の低い成果物一式を作成します。
  • 事前の証拠がほとんどない初回商談の準備を依頼された場合は、商談の基点があるときは prepare-for-meeting に引き継ぎます。それ以外の場合は、基本的なアカウント情報を尋ね、簡易的な手動準備を提供します。
  • デフォルトでは Full Strategy Pack を使用します。ユーザーが成果物を1つだけ求めている場合は、対応する部分モードを使用し、調査範囲をその成果物に限定します。
2. 商談の起点を特定する
  • ユーザーが指定したアカウント、商談、更新、イニシアチブ、リンク、またはメモから始めます。
  • 従来の別名として、sfdc_account_id を crm_account_id として受け付けます。
  • 利用可能な場合は、まず ~~CRM を使ってアカウントと、指定された製品、ソリューション、更新、関係者、時期、最近の活動に最も合致する商談を特定します。
  • ユーザーが商談戦略を求めているものの、アカウント、商談、更新、イニシアチブ、リンク、またはメモを指定していない場合は、まず ~~CRM を使って検索・順位付けし、現在進行中の具体的な商談候補を最大5件、ask_user_input() で提示します。「最も適切な現在進行中の商談について商談戦略を立てて」のように対象を指定しない依頼では、対象を推測しないでください。コネクターから得た候補を提示し、広範な情報収集やドラフト作成に進む前に、ユーザーに選択を求めます。
  • 選択した商談名、製品またはソリューションの用語、活動のタイトル、ユーザーの表現から、小規模な別名セットを作成します。これを使って関連する会議、スレッド、ドキュメントを検証し、同一アカウントでも異なる商談の進め方に関する資料は除外します。
  • 妥当な商談候補が複数残る場合は、ソースの読み取りを最大3回まで行い、具体的な候補を最大5件、ask_user_input() で提示してから、広範な情報収集に進む前にユーザーに選択を求めます。推定候補が1件だけの場合は、広範な情報収集やドラフト作成に進む前に、ask_user_input() でユーザーに確認します。
  • CRM を利用できなくても、ユーザー提供の証拠が十分であれば、CRM の不足を明示したうえで続行します。同一アカウントに関する別の商談の証拠を、選択した商談の進め方を裏付けるものとして扱わないでください。
3. 領域ごとに証拠を収集する
  • 選択したアカウントと商談の進め方に関する別名を使い、~~Meeting Transcripts、~~Email、~~Internal Messaging、~~Knowledge & Files、~~Calendar から関連する最近の証拠を探します。
  • 該当する範囲をできるだけ絞ります。ユーザーが別の期間を指定していない場合は、直近90日間を既定とします。
  • 最初から文字起こし、スレッド、ドキュメントへのリンクを求めないでください。選択したアカウントと商談の進め方に関する別名を使って、関連資料を見つけます。
  • 現在の商談の進め方、関係者の姿勢、調達上のリスク、次のアクションを裏付けられるだけの情報を読み取ります。最初に見つかった同一アカウントの資料が別の商談の進め方に関するものなら、可能であれば次の絞り込んだ検索結果を確認します。そうでなければ、その資料を除外し、不足を明示するか、ユーザーに選択を求めます。
  • 各領域を、利用可能、利用不可、該当なし、古い、矛盾あり、またはユーザー提供のみとして記録します。戦略の中核が裏付けられた時点で終了し、利用できないソースの事実を間接的な代替情報で追いかけないでください。
4. 戦略を立てる
  • 簡潔な商談マップを作成します。イニシアチブ、目標とする成果、商談の進め方/タイムライン、進行中のワークストリーム、証拠がある場合に商談の実行を大きく左右する最近のアカウントまたはサービスの状況、障害、依存関係を含めます。
  • 証拠に基づいて、購買委員会を構成する人物と役割をまとめます。役割は economic_buyer、decision_maker、champion、influencer、blocker、procurement、legal、security、または unknown、姿勢は supportive、neutral、skeptical、blocking、または unknown、影響力は high、medium、low、または unknown を使います。推定した役割、姿勢、または影響力には Inference: と明記します。
  • 重要度、発生可能性、確信度、担当者または推奨担当者、軽減策、時期、情報源を含めて調達リスクをまとめます。分類または優先順位付けが曖昧な場合は、references/risk-rubric.md を読み込みます。
  • 既定では、重要度の高いアクションを5~7件作成します。各アクションには、担当者または推奨担当者、期限または TBD、期待される成果、関連するリスクまたは関係者、情報源を記載します。
5. 証拠と推論を分ける
  • 利用できる場合は、役立つソースへのリンクを本文中に記載します。安定したリンクがない場合に限り、ソース名のみを記載します。
  • 会議への参加 URL、汎用的なルーム URL、または不透明なコネクタ ID を証拠としてリンクしないでください。
  • 証拠が矛盾する場合は、無理に結論を出さず、確信度を下げて証拠の不足を明記します。
  • 正確な日付と、顧客側で担当者として確定している人物は、直接的な証拠がある場合に限って記載します。それ以外の場合は、相対的な時期、「TBD」、または「提案する担当者:」を使います。確信度が低い場合や証拠が乏しい場合は、日付を特定した期限を避けます。
  • 公開情報またはユーザー提供の市場情報は、案件を確認したうえで、企業やステークホルダーに関する仮説を明確にする場合に限って使用します。あくまで補足情報として扱い、アカウントや案件の事実に対する必須条件や上書き情報として扱わないでください。
次のステップの選択肢

最初の出力の後、以下の選択肢から最も関連性の高いフォローアップを提示します。メニュー形式ではなく、明確な次のステップを1つ提示してください。他の選択肢のほうが有用だと非常に確信できる場合を除き、以下のみを提案します。

  • 優先順位を付けたアクションを、相互合意に基づくアクションプランまたは実行トラッカーにまとめる。
  • 最もリスクの高い意思決定を中心に、次の顧客、パートナー、または社内会議を準備する。
  • ステークホルダーごとのメールまたは Slack の文面をレビュー用に作成する。
  • CRM にそのまま使える商談の更新内容をレビュー用に作成する。
  • 証拠がまだ不十分な障害要因、ステークホルダー、または調達リスクを詳しく調べる。

避けるべき次のステップ:

  • 別途明示的な依頼がない限り、メッセージの送信、CRM の更新、または後続成果物の作成を行わないでください。

モード

  • Full Strategy Pack — デフォルト。以下の全セクションを返します。
  • Deal Map Only — Deal Snapshot、Deal Map、Evidence Gaps、Inference Notes を返します。
  • Buying Committee Only — Deal Snapshot、Buying Committee Map、Evidence Gaps、Inference Notes を返します。
  • Procurement Risk Only — Deal Snapshot、Procurement Risk Register、Evidence Gaps、Inference Notes を返します。
  • Next Actions Only — Deal Snapshot、Prioritized Next Actions、Evidence Gaps、Inference Notes を返します。

出力形式

完全な戦略パックでは、以下のセクションを指定された順序で返します。

# Deal Strategy: [Account / Opportunity]

## Deal Snapshot

- **Account:** [Name + source]
- **Opportunity:** [Name or Unknown]
- **Stage:** [CRM-backed value or Unknown]
- **Close Date:** [Evidenced date or Unknown]
- **Time Window:** [Window]
- **Run Mode:** [Mode]
- **Coverage Summary:** [Available, unavailable, empty, stale, or user-provided-only lanes]

## Deal Map

- **Initiative:** [Business initiative]
- **Target Outcome:** [Customer/business outcome]
- **Current Motion:** [Stage, timeline posture, and deal movement]
- **Active Workstreams:** [3-6 grounded bullets]
- **Top Blockers or Dependencies:** [Up to 5 grounded bullets]

## Buying Committee Map

| Stakeholder | Title | Org | Role | Stance | Influence | Last Signal | Confidence | Source |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Name] | [Title] | [Org] | [Role] | [Stance] | [Influence] | [Signal] | [High/Medium/Low] | [Link/label] |

## Procurement Risk Register

| Risk ID | Risk Summary | Risk Type | Severity | Likelihood | Owner or Suggested Owner | Mitigation | Target Date | Confidence | Source |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R1 | [Risk] | [Type] | [High/Medium/Low] | [High/Medium/Low] | [Owner] | [Step] | [Date/TBD] | [High/Medium/Low] | [Link/label] |

## Prioritized Next Actions

1. **Action:** [Concrete action]
   - **Owner or Suggested Owner:** [Owner]
   - **Due:** [Date, relative timing, or TBD]
   - **Linked Risk IDs:** [IDs or None]
   - **Linked Stakeholders:** [Names or None]
   - **Expected Outcome:** [Outcome]
   - **Source:** [Link/label]

## Evidence Gaps

- **Gap:** [Material missing/conflicting evidence]
  - **Impact:** [How confidence or execution is affected]
  - **Smallest Next Collection Step:** [Most efficient way to close it]

## Inference Notes

- Inference: [Claim inferred rather than directly stated, with basis]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

ルール

  • ステークホルダー、承認、障害要因、担当者、確約、金額、ステージ、成約日、または正確な日付を捏造しないでください。
  • 事実と推論は分けます。推論メモが空の場合は、内容を埋めるためだけに記載せず、省略します。
  • 広範なアドバイスより、確度の高いアクションを少数優先し、署名を妨げたり時期を遅らせたりする可能性が最も高いリスクを優先します。
  • 通常の出力では、人が読みやすい Title Case のラベルを使います。ユーザーが JSON または YAML を求めた場合に限り、機械可読キーを使います。
  • このワークフローは読み取り専用です。後の手順でユーザーが明示的に求めない限り、CRM の更新、メッセージの送信、要約の投稿、または後続成果物の作成を行わないでください。
  • 証拠が乏しくても案件の基準となる情報が十分な場合は、処理を中断せず、明示的な不足情報を含む低確信度のパックを作成します。

エラー処理

信頼できる進行中の案件の基準となる情報が存在しない場合は、障害要因を述べ、可能であれば具体的な候補を提示し、必要最小限の不足情報を尋ねます。任意の情報源を利用できない場合は、根拠が最も強い情報を用いて処理を続け、結果の確信度の限界を明示します。

コメント