meddic-call-prep-auto

通話ごとに 15〜20 分かかる手動のデモ準備を不要にします。HubSpot（商談ステージ、プロパティ、ノート）、Apollo（担当者のエンリッチメント、組織データ）、CRM のアクティビティ履歴（ask_agent 経由）、Google カレンダー（会議の詳細と参加者）からコンテキストを取得し、MEDDIC 構造のブリーフィングを自動生成します。トーキングポイント、想定反論への準備、競合情報を盛り込んだ、実行可能な 1 つのブリーフを出力します。

<quick_start> 通話の前: "call prep Baylor University" → すべてのコンテキストを取得 → MEDDIC ブリーフを生成

デモの前: "demo prep for University of Michigan, meeting at 2pm" → デモ固有の流れを追加

カレンダーから: "prep my next call" → 次のカレンダー予定を読み取り → 企業を自動特定 → 完全な準備を実行

トリガーフレーズ:

• "call prep [company]"
• "prep me for [company]"
• "demo prep [company]"
• "discovery prep [company]"
• "meddic brief [company]"
• "prep my next call"
• "get me ready for my [time] meeting" </quick_start>

<success_criteria>

• 完全な MEDDIC ブリーフを 60 秒以内に生成
• 6 つの MEDDIC ディメンションをすべて埋める（一部が「UNKNOWN — ask this」であっても）
• CRM のアクティビティ履歴から以前の会話コンテキストを含める
• 該当する場合は競合からの置き換え角度を特定
• 参加者の役割を MEDDIC の役割（チャンピオン、経済的買い手など）にマッピング
• エンリッチメントデータからパーソナライズされたディスカバリー質問を 3 つ生成
• ブリーフが 1 画面に収まる（通話前に 30 秒で読み取れる） </success_criteria>

パイプライン

TRIGGER              CONTEXT GATHER              SYNTHESIZE              OUTPUT
───────────────────────────────────────────────────────────────────────────────
"call prep X"  →  Calendar: meeting details  →  Map attendees to   →  MEDDIC Brief
               →  HubSpot: deal + contact    →  MEDDIC roles       →  Talking Points
               →  Apollo: enrichment         →  Identify gaps       →  Questions
               →  CRM: activity history    →  Competitive angle   →  Objection Prep
               →  Epiphan CRM: device check  →  Pain hypothesis     →  Next Steps

ステージ 1: コンテキストの収集

以下の MCP 呼び出しを並行して実行します:

1a. カレンダーコンテキスト

ツール	目的
gcal_list_events	会議を検索（企業名または次に予定されているもの）
gcal_get_event	参加者、説明、会議リンクを取得

抽出: 参加者名 + メールアドレス、会議時間、説明内のアジェンダ。

1b. HubSpot コンテキスト

ツール	目的
hubspot_search_companies	企業レコード — ライフサイクル、オーナー、プロパティ
hubspot_search_contacts	各参加者の担当者レコード
hubspot_search_deals	進行中の商談 — ステージ、金額、クローズ日、ノート

抽出: 商談ステージ、商談金額、ライフサイクルステージ、以前のノート、フォーム送信、ページビュー。

1c. Apollo エンリッチメント

ツール	目的
apollo_organizations_enrich	企業のファームグラフィックス、技術スタック、従業員数
apollo_people_match	各参加者 — 役職、シニアリティ、部署
apollo_organizations_job_postings	AV/IT の採用中 = 購買シグナル

1d. Clari 会話履歴

ツール	目的
clari_search_calls	この見込み客との過去の通話を検索（attendeeEmail、過去 90 日間）
clari_get_call_summary	各通話の AI サマリー、アクションアイテム、キーモーメントを取得

各参加者のメールアドレスについて:

1. clari_search_calls(attendeeEmail=attendee_email, daysBack=90)
2. 直近の最大 3 件の通話について: clari_get_call_summary(callId=call_id)
3. 抽出:
   • 以前の会話トピック: 前回は何が話し合われましたか？
   • 未解決のアクションアイテム: 何をフォローアップすると約束しましたか？
   • 競合の言及: Extron、Blackmagic、Crestron、vMix、Teradek が挙がりましたか？
   • 提起された反論: 価格、機能、統合に関する懸念は？
   • 前回の通話での MEDDIC ギャップ: どのディメンションがカバーされませんでしたか？

1e. 以前の会話コンテキスト

ツール	目的
ask_agent	CRM データウェアハウスからアクティビティ履歴、商談ノート、エンゲージメントタイムラインを照会
hubspot_get_deal	関連する商談の商談ノートとアクティビティログを取得

ask_agent へのクエリ: "Show recent activity, notes, and engagement history for [company name] in the last 90 days"

抽出: 話し合われた内容、約束したこと、提起された反論、約束した次のステップ。

1f. 競合インテリジェンスのコンテキスト

bdr-v3-competitive-intel の日次タスクから保存された競合インテリジェンスを確認します：

1. Gmail で最近の競合インテリジェンスレポートを検索します：search_threads(query="subject:competitive-intel from:me newer_than:7d")
2. 直近の Clari 抽出で企業または競合が言及されている場合は、関連するバトルカードのコンテキストを取得します
3. MEDDIC ブリーフに統合します：
   • Clari の通話で競合が言及されている場合：置き換え（ディスプレイスメント）のトーキングポイントを含めます
   • 競合が言及されていない場合：見込み客の業種における上位 2 社の競合に対するプロアクティブな競合ポジショニングを含めます
   • 具体的な反論への再反論：Clari の反論を用意済みの回答に対応付けます

競合クイックリファレンス（業種別）：

業種	主な競合	置き換えの切り口
高等教育	Extron SMP（販売終了）	Extron EOL → Pearl への移行パス
法人向け AV	Crestron	Pearl = よりシンプル、プログラマー不要
礼拝施設	vMix	Pearl = ハードウェアの信頼性、PC クラッシュなし
医療	Blackmagic	Pearl = HIPAA に配慮、Connect によるクラウド管理
裁判所・法務	Teradek	Pearl = オールインワン、別途エンコーダー不要

1g. Epiphan CRM チェック

ツール	目的
crm_search_customers	既存顧客の照合 — デバイス、注文、チャネル関係
analytics_search_by_email	連絡先メールアドレスによるデバイス登録の検索

ゴールデンルールのチェック： 次のいずれかに該当する場合は、STOP してこの準備をスキップします：

• lifecyclestage = 'customer' → AE／アカウントマネージャーにルーティング、Tim の担当ではない
• device_count >= 1 → 既存顧客、アカウントマネージャーにルーティング
• is_channel = true → チャネルパートナー、チャネルマネージャーにルーティング
• hubspot_owner_id IN ('82625923', '423155215', '190030668') → AE 所有の案件（Lex Evans、Ron Epstein、Phillip Sandler）、Tim が準備するものではない

例外： Tim が明示的に「[company] 向けに準備して」と言い、その企業がフラグされている場合は、ブリーフを生成しつつ、先頭に ⚠️ WARNING バナーを追加します：「これは既存顧客／チャネルパートナー／AE 案件です。連絡する前にオーナーと調整してください。」

ステージ 2：MEDDIC の統合

収集したコンテキストを MEDDIC フレームワークに対応付けます：

M — 指標（Metrics）

• 判明している場合： 過去の通話や案件メモで言及された定量化可能な目標
• 仮説： 業種別のベンチマークに基づく（例：「御社と同規模の大学では通常 50〜200 室を管理しています」）
• 不明な場合の質問： 「このプロジェクトの成功をどのように測定していますか？」

E — 経済的購買者

• 既知: 役職ごとに参加者をマッピング → VP/ディレクター/学部長 = EB の可能性が高い
• ATL/BTL 検証（必須 — CLAUDE.md § ATL/BTL Classification v1.0 を参照）:
  • 確認済み EB（ATL 層）: 役職が Chief（CIO、CTO、CFO、COO）、VP（AVP、SVP、EVP）、President、Provost、Vice Provost、Superintendent、Director（IT、Technology、Facilities、Academic Technology、Procurement、Materials Mgmt、Medical Education、Court Administration）、Dean、Court Administrator、Clerk of Court（連邦）、City Manager、County Manager、Senior Pastor、Executive Pastor に一致 → EB を ✅ IDENTIFIED とマーク
  • グレーゾーン — 予算権限を確認: Manager（AV/Facilities/IT） — Director 以上に報告しており、かつ委任された予算が $25K 超の場合のみ ATL。質問する: 「[name] はこの購入の予算を管理していますか、それとも上長の承認が必要ですか？」
  • EB ではない（BTL 層）: Technician、Specialist、Coordinator、Support、Administrator（Systems/Network/Database）、Engineer（AV/Network/Systems）、Operator、Instructor/Professor/Faculty、Designer（Learning/Instructional/Graphic）、Assistant、Clerk（Court Admin 以外）、Volunteer、Intern、Student、Resident、Help Desk → EB を ⚠️ NOT IDENTIFIED とマーク — PO に署名する人を見つける必要がある
  • 絶対に EB ではない: Warehouse Manager、Network Manager、Systems Administrator、AV Technician、Graphic Design Instructor、Program Administrator、Web Designer、Classroom Support、Lab Coordinator、Maintenance、Building Engineer、Multimedia Services Manager、Video Production Specialist、Streaming Crew → これらの役割は予算を承認できません。潜在的な EB として記載しないでください。
• 不明な参加者: ディスカバリーのためにフラグを立てる（「この予算を管理しているのは誰ですか？」）
• シグナル: 通話に BTL/技術スタッフしかいない場合、EB はまだ関与していません — ⚠️ としてフラグを立て、ディスカバリー質問を追加します: 「この購入を承認するのは誰ですか？」

D — 意思決定基準

• 既知: 以前の通話メモ、フォーム送信、またはディールプロパティから
• 仮説: 業種に基づく（高等教育機関は CMS 統合 + 部屋規模を重視、裁判所はコンプライアンス + 信頼性を重視）
• 標準的な基準: 価格、機能、CMS 統合、サポート、使いやすさ

D — 意思決定プロセス

• 既知: ディールプロパティ、調達メモからのタイムライン
• 不明な場合の質問: 「評価のタイムラインはどのくらいですか？他に誰が関与する必要がありますか？」
• レッドフラグ: 明確なプロセスがない = ディールが停滞する可能性が高い

I — 課題の特定

• 既知: 以前の通話で表明された課題、フォーム送信のコンテキスト
• 仮説: トリガーシグナルに基づく（採用 = スケーリングの課題、Extron 離脱 = リプレースの課題）
• 不明な場合の質問: 「現在のセットアップのどこが問題ですか？」

C — チャンピオン

• 既知: 誰が連絡を開始しましたか？誰が最も関与していますか？
• テスト: 「これが理にかなっていれば、社内で推進してくれますか？」
• レッドフラグ: 2 回目の通話後もチャンピオンが特定されていない

ステージ 3: 出力フォーマット

╔══════════════════════════════════════════════════════════════╗
║  CALL PREP: [Company Name]                                   ║
║  [Date] [Time] | [Meeting Type: Discovery/Demo/Follow-up]    ║
╠══════════════════════════════════════════════════════════════╣

ATTENDEES & ROLES:
┌─────────────────────────────────────────────────────────────┐
│ [Name] — [Title] → MEDDIC Role: [EB/Champion/User/Coach]   │
│   LinkedIn: [url] | Email: [email]                          │
│   Context: [personalization note from enrichment]           │
├─────────────────────────────────────────────────────────────┤
│ [Name 2] — [Title] → MEDDIC Role: [...]                    │
└─────────────────────────────────────────────────────────────┘

DEAL STATUS:
- Stage: [stage] | Amount: [$XX,XXX] | Close: [date]
- Days in stage: [X] | Last activity: [date]

MEDDIC SCORECARD:
┌───────────────────────┬──────────┬──────────────────────────┐
│ Dimension             │ Status   │ Key Intel / Gap          │
├───────────────────────┼──────────┼──────────────────────────┤
│ M — Metrics           │ ✅/⚠️/❌ │ [what we know or need]  │
│ E — Economic Buyer    │ ✅/⚠️/❌ │ [identified or not]     │
│ D — Decision Criteria │ ✅/⚠️/❌ │ [known criteria]        │
│ D — Decision Process  │ ✅/⚠️/❌ │ [timeline/blockers]     │
│ I — Identify Pain     │ ✅/⚠️/❌ │ [stated pain or hypo]   │
│ C — Champion          │ ✅/⚠️/❌ │ [who + engagement]      │
└───────────────────────┴──────────┴──────────────────────────┘

PRIOR CONVERSATION CONTEXT:
[CRM activity summary or "No prior activity found"]
- Key commitments: [...]
- Objections raised: [...]
- Follow-ups promised: [...]

COMPETITIVE INTEL:
🆚 COMPETITOR STATUS
[Detection result from Clari calls or CRM]

If competitor detected:

競合他社を検出: [name]（[date] の Clari 通話より） リプレースの切り口: [具体的なトーキングポイント] 異議への準備: [提起された異議に対する具体的な反論] 主要な差別化要因: [最も関連性の高い Pearl の優位性]

If no competitor detected:

競合他社は特定されず — [業種別の価値提案] でリードする

DISCOVERY QUESTIONS (ask these):
1. [Personalized question based on trigger/enrichment]
2. [MEDDIC gap-filling question]
3. [Competitive displacement question]

OBJECTION PREP:
| Likely Objection | Response |
|------------------|----------|
| "We're happy with current setup" | [response] |
| "Budget is tight" | [response] |
| "Need to evaluate others" | [response] |

CALL AGENDA (suggested):
1. [2 min] Rapport + confirm agenda
2. [5 min] Discovery: pain + metrics
3. [10 min] Demo / value prop aligned to pain
4. [3 min] Decision process + next steps

╚══════════════════════════════════════════════════════════════╝

<demo_prep_addon> トリガーが「call prep」ではなく「demo prep」の場合、以下を追加します:

デモの流れ（RECAP → AGENDA → SHOW VALUE → SUMMARIZE → NEXT STEPS）

1. RECAP（2 分）：「前回は[前回の活動の要約]についてお話ししました。お客様は[課題]に触れていました。そのように理解して間違いないでしょうか？」
2. AGENDA（1 分）：「本日は[課題に沿った機能]をご紹介し、その後[意思決定の基準]についてお話しします。」
3. SHOW VALUE（10 分）：お客様の業種に合わせたデモの流れ：
   • 高等教育：マルチルーム収録 → CMS への自動公開 → 部屋のスケジューリング
   • 裁判所：自動録画 → コンプライアンスに基づくアーカイブ → フェイルオーバー
   • 企業：会議室の収録 → NDI/SRT ストリーミング → クラウド管理
4. SUMMARIZE（2 分）：「お客様は[指標]に触れていました。Pearl が[定量化された価値]をどのように実現するかをご説明します。」
5. NEXT STEPS（2 分）：「パイロットはどのような形になるでしょうか？ほかにどなたにご覧いただくべきでしょうか？」 </demo_prep_addon>

## 必要な MCP ツール - **Google Calendar MCP:** gcal_list_events、gcal_get_event - **Epiphan CRM MCP:** hubspot_search_companies、hubspot_search_contacts、hubspot_search_deals、hubspot_get_deal、crm_search_customers、analytics_search_by_email、ask_agent（アクティビティ履歴のクエリ） - **Apollo MCP:** apollo_organizations_enrich、apollo_people_match、apollo_organizations_job_postings - **Clari MCP（新規）:** clari_search_calls、clari_get_call_summary - **Gmail MCP:** search_threads（競合情報レポート用）

参照される関連スキル

• sales-revenue-skill — MEDDIC フレームワーク、反論処理（LAER）、デモの流れ
• prospect-research-to-cadence-skill — エンリッチメントのロジック、ゴールデンルールフィルターを共有
• hubspot-revops-skill — HubSpot クエリパターン、ディールステージの定義

結果サイドカーを出力する

最後のステップとして、~/.claude/skill-analytics/last-outcome-meddic-call-prep-auto.json に書き込みます：

{"ts":"[UTC ISO8601]","skill":"meddic-call-prep-auto","version":"1.0.0","variant":"default",
 "status":"[success|partial|error]","runtime_ms":[estimated ms from start],
 "metrics":{"calls_prepped":[n],"meddic_fields_filled":[n],"contacts_enriched":[n],"economic_buyers_identified":[n]},
 "error":null,"session_id":"[YYYY-MM-DD]"}

一部のステージが失敗しても結果が生成された場合は、ステータスに「partial」を使用します。出力がまったく生成されなかった場合にのみ「error」を使用します。