follow-up-after-call

通話後のフォローアップ

コンテキスト収集のインテーク

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

通話で実際に話された内容を根拠として、担当者がすぐに使えるフォローアップ一式を作成します。実際に話されたことを忠実に保ち、担当者が明確にわかるようにし、すぐに使える文面を提供します。このスキルが担当するのは、通話後の情報整理と文案の作成までです。送信、投稿、メールの下書き作成、CRM の更新は行いません。

共通スキルの指示

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

主要な依存カテゴリ

このワークフローでは次のカテゴリが特に重要です。パッケージの改善に実質的に役立つ場合に限り、他の情報源を使用してください。

• [ブロッキング] ~~Meeting Transcripts：主要なトランスクリプト、根拠のあるメモ、参加者の言葉、決定事項、約束、異議、情報源へのリンクに使用します。デフォルトのライブ情報源によるフォローアップの経路では必須です。通話に関する明確な根拠がすでにコンテキストにある場合は、これで要件を満たします。
• ~~Calendar：最近の通話の特定、参加者、日時、関連する今後の会議に使用します
• ~~CRM：アカウント、商談、連絡先、担当者、CRM に登録可能な次のステップのコンテキストに使用します
• ~~Email：通話の根拠や約束したフォローアップが記録されている場合に、顧客とのスレッドのコンテキストに使用します
• ~~Internal Messaging：アカウントに関する社内情報と、チーム向けの要約を共有する適切な送信先の確認に使用します
• ~~Knowledge & Files：エクスポートされたトランスクリプト、通話メモ、アカウントメモ、フォローアップ資料に使用します

通話に関する根拠が必要です。CRM、カレンダー、ファイル、メッセージはパッケージの補足には使えますが、トランスクリプト、根拠のあるメモ、または通話内容を記録した顧客向けのスレッドの代わりにはなりません。根拠が見つからない、古い、または食い違っている場合は、通話を再構成せず、その制約を明記してください。

参照資料の読み込み

通常の根拠優先のワークフロー、チャット優先の文案作成、出力パッケージは SKILL.md が定めています。判断に追加情報が必要な場合に限り、参照資料を読み込んでください。

• 構造化された入力、相対的な通話日付、会議の録画識別子、フォールバックとなる根拠の経路を正規化する場合は、references/request-schema.yaml を使用してください。
• 商談の順位付けや社内の送信先の安全性が不明確な場合は、references/opportunity-and-channel-selection.md を使用してください。

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

1. 通話と証拠を特定する

• ユーザーが文字起こし、メモ、リンク、または明確に特定された通話を提示した場合は、そこから始めます。
• 通話を特定する方法が明確でない場合は、ask_user_input() を使ってユーザーに確認します。「通話後のフォローアップ」のような情報が少ない依頼では、会議があったと決めつけず、次の選択肢を提示します。
  • Use my most appropriate recent grounded call
  • Use a call, account, attendee, or date I specify
  • Use transcript or notes I provide
• 「最新の通話」「今日の通話」「今日の早い時間」「昨日」「先週」「最近の会議のうち最も適切なもの」、または情報源を指定せずにアカウント名が示された場合は、その表現を検索可能な手がかりとして扱います。~~Calendar と ~~Meeting Transcripts で、対象を最も絞った直近の期間を検索し、ask_user_input() を使って具体的な候補を最大5件提示します。ユーザーが選択するまで、さらに詳しいコンテキストを取得したり、フォローアップ一式を作成したりしないでください。
• 通話やアカウントを特定する手がかりが曖昧な場合、具体的な候補を提示するための情報源の読み取りは最大3回までとし、ユーザーが選ぶ前に広範な情報収集を行わないでください。
• 企業名のように見える曖昧な名称、パートナー名、アカウントの略称は、アカウントを特定する手がかりとして扱います。~~CRM が利用可能で、アカウントの特定が検索する通話に影響する場合は、他の不確かなアカウント情報に頼る前に、範囲を限定して ~~CRM を検索し、アカウントを識別します。ただし、これは根拠のある通話情報の代わりにはなりません。
• 根拠のある候補が1件だけの場合は、作成を始める前に ask_user_input() を使ってユーザーに確認します。根拠となる情報が見つからない場合は、周辺のアカウント情報から要約を作成せず、文字起こし、メモ、または具体的な通話の提示を求めます。
• 貼り付けられたメモ、アップロードされた資料、ユーザーがリンクした資料は、有効な作業根拠として扱います。検証できない場合は、ユーザー提供の情報であることを明記します。

2. 有用な補足情報だけを集める

• 根拠として使う情報は、次の順で優先します。~~Meeting Transcripts の文字起こし、取得可能な会議録画の文字起こし、その他のエクスポートされた文字起こし、貼り付けられた文字起こしまたは根拠のあるメモ、~~Knowledge & Files の会議メモ、最後に補完手段として ~~Email のスレッドまたはメッセージ。
• ユーザーが通話または文字起こしのハンドルを提示した場合は、それを直接取得します。それ以外の場合は、アカウント名と日付または期間、さらに会議のトピックを表す語句を最大2つ使って検索し、最も適切な結果を取得します。
• 補助的な一次情報、通話メモ、文字起こしへのリンクは置き換えず、主要な根拠と併せて保持します。
• 外部アカウントとの通話では、~~CRM が利用可能な場合、関連するアカウントまたは商談を特定し、氏名や商業的な背景を明確にするとともに、CRM に記録する次のアクションを1文にまとめます。
• 時期によって次のアクションが変わる場合は、~~Calendar で関連する今後の会議を確認します。~~Email、~~Internal Messaging、~~Knowledge & Files は、約束したアクション、阻害要因、担当者、リンク、または共有先に関する情報が得られる場合にのみ使用します。
• 文字起こしに、フォローアップに影響する可能性のある会議名またはファイル名が明記されている場合は、利用可能であれば正確なタイトルと日付を使って、~~Calendar または ~~Knowledge & Files を1回だけ対象を絞って検索します。見つかった場合はリンクを含めます。見つからない場合は、その会議やファイルが存在しないと断定せず、確認した情報源または期間では見つからなかったと伝えます。
• 根拠が整い、アカウントや時期に関する最も重要な情報を確認できた時点で終了します。不足している補足情報を明示し、広範な検索を続けないでください。

3. 通話を分類し、コミットメントを抽出する

• 通話が外部の顧客・パートナー向けか、社内向けかを判断します。外部メール文面と CRM テキストは、外部向け通話にのみ適用されます。
• 決定事項、コミットメント、依頼、異議、障害、担当者、日付を抽出します。根拠から判断できない場合は、Unknown または TBD を使用します。
• CRM の商談候補が複数ある場合は、通話のトピック、参加者、製品、時期、最近のアクティビティに合致するものを選びます。確かな候補がない場合は、CRM の文を汎用的なものにし、(paste into the relevant opp) を追記します。
• 商談の意図、候補の優先順位、安全性の高い社内チャネルが明らかでない場合は、references/opportunity-and-channel-selection.md を使用します。

4. チャットで下書きを作成する

• メールや社内チャネルが利用可能な場合でも、既定ではチャットで一式を返します。
• このワークフローでは、メールの下書きの作成、アウトリーチの送信、社内メッセージの投稿、CRM への記入は行いません。
• 営業担当者が確認してコピーできるよう、メール文面と社内メッセージの全文は Markdown の引用ブロックに記載します。

次のステップの選択肢

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

• ユーザーの指示に基づいて、外部向けメール、社内向け要約、CRM の文、またはアクションリストを修正する。
• ユーザーから明示的に依頼された場合、確認済みのメール下書きを作成するか、確認済みの社内向け要約を投稿する。
• 確認済みの要約とアクション項目を既存のミーティングノートに追加するか、新しいフォローアップノートを作成する。
• 確認用に CRM への記入に適した更新内容を準備する。
• 該当するオートメーションを確認し、同じオートメーションがすでに存在する場合を除き、作成を提案する。すでに存在する場合は、確認または調整を提案する。

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

• ユーザーが確認し、明示的に依頼する前に、送信、投稿、または CRM の更新を行うこと。

オートメーションの提案に関するガード

同じオートメーションがすでに存在する場合を除き、出力の最後に必ずフォローアップオートメーションを提案します。出力から次回のミーティング、フォローアップ日、顧客の決定日、合意済みの確認日など、自然なタイミングの基準が特定できる場合は、そのタイミングを提案に使用します。それ以外の場合は、トリガーまたは実行頻度の選択を支援すると提案します。オートメーションはカスタムのダイジェストではなく、このスキルをスケジュールに従って再実行するものとして説明します。可能な場合は同じ通話またはアカウントを基準にして、要約、アクション項目、外部向け文面、CRM 記入用テキスト、社内向け要約を含む標準のフォローアップ一式を返すものとします。

オートメーションの作成を提案する前に、$CODEX_HOME/automations/*/automation.toml、または CODEX_HOME が設定されていない場合は ~/.codex/automations/*/automation.toml に、該当するローカルオートメーションがすでに存在するか確認します。プロンプト、スキル名、アカウント、ミーティングのタイトル、参加者、商談、トリガーの時刻、その他の安定した範囲の詳細に基づいて照合します。有効なものも一時停止中のものも、すでに設定済みとして扱います。

• 該当するオートメーションが存在する場合は、別のものを作成するのではなく、確認または調整を提案します。
• 該当するオートメーションが存在しない場合は、次回の通話後または合意済みのフォローアップ時刻に営業担当者向けのフォローアップ一式を作成するものとして、オートメーションの作成を明確に 1 つ提案して終えます。ユーザーが明示的に同意するまで、オートメーションを作成または更新してはいけません。
• オートメーションを利用できない場合は、ツールの詳細には触れず、オートメーションが利用可能になった際に、定期的またはスケジュールされたフォローアップ確認の設定を支援すると簡潔に提案します。

モード

1. フォローアップ一式

通話後のフォローアップをユーザーが依頼した場合の既定のモードです。以下のすべてのセクションを、記載順に返します。

2. 対象を絞った下書き

メール、社内向け要約、CRM メモ、または次のステップの抽出のみをユーザーが依頼した場合に使用します。それでも通話の根拠に基づいて作成し、依頼されたセクションに加えて、簡潔な Call Summary、重要な不足情報、ステータス行を返します。

出力形式

通常の一式では、最上位見出しではなく、太字のセクションラベルを使用します。

**Call Summary**

- **Primary evidence:** [Clickable transcript/notes link or source label]
- **TL;DR:** [2-4 grounded bullets]
- **Context / Goal:** [Why the call happened]
- **Key Points:** [Important customer/internal signals]
- **Decisions / Commitments:** [What was agreed]
- **Risks / Blockers:** [What could slow follow-through]

**Next Steps**

**Customer**
- [ ] [Action] — [Owner or Unknown] — [Due date or TBD] — [Notes]

**Seller**
- [ ] [Action] — [Owner or Unknown] — [Due date or TBD] — [Notes]

**External Comms**

Subject options (recommended first):
1. [Subject]
2. [Subject]
3. [Subject]

Recommended subject: [Subject]

> Hi <FirstName>,
>
> [150-220 word grounded follow-up email]
>
> Best,
> [Seller]

Draft link: Not created; copy drafted in chat only.

**CRM Next Steps**

[Exactly one sentence with call date, seller action, customer action, and outcome/success criterion.]

**Internal Follow-Up**

Suggested destination: [Safe internal channel/link, or “No verified internal channel found”]

> **[Meeting title]**
>
> [One concise summary paragraph]
>
> **Attendees:** [Names or Unknown]
>
> **Key Notes**
> - [Grounded note]
>
> **Decisions**
> - [Decision or None confirmed]
>
> **Action Items**
> - [Action] — [Owner or TBD] — [Due date or TBD]
>
> **Open Questions / Risks**
> - [Question or risk]
>
> **Source**
> - [Clickable call-notes/transcript link, or no useful link available]

No email draft, Slack post, or CRM update was created.

---

{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)}

出力ルール

• 意思決定、リスク、次のステップ、購入プロセス、調達、技術的な阻害要因、関係者の動きを重視してください。
• 社内通話の場合は、External Comms と CRM Next Steps の両方に、正確に Not applicable: this was an internal call. と記載してください。社外向けの文面は作成しないでください。
• 社外向けメールは簡潔にし、顧客に共有できる内容とし、機密性の高い社内向けの表現は避けてください。宛先、約束、価格、日付、メールの下書きリンクを決して捏造しないでください。
• CRM のテキストは正確に1文にしてください。未解決の商談の場合は、末尾に (paste into the relevant opp) を追加してください。
• 社内の共有先を提案するのは、社内向けで関連性があると確認できる場合に限ってください。チャンネルの安全性が不明な場合は、投稿前に確認するよう伝えてください。チャンネルの URL を捏造しないでください。
• 確認済みの社内共有先がないと述べる前に、利用可能な場合は ~~Internal Messaging を1回検索し、アカウント名、会議タイトル、または業務テーマを確認してください。
• 利用可能な場合は、役立つクリック可能なソースリンクを含めてください。信頼性を大きく下げる情報源の不足も明記してください。
• 社内向けの要約は、原則として1つにまとめてください。ユーザーから依頼された場合、または確認済みのチャンネル慣習で必要な場合に限り、トップレベルのメッセージとスレッドに分けてください。
• 選択したアプリが対応している場合は、出席者や担当者にネイティブのメンションを使用してください。それ以外の場合は、読みやすい名前を使用してください。
• 社内向けの下書きに ## 見出しを含めないでください。冒頭の要約では、TL;DR を繰り返さず、立ち上げの道筋、事業への影響、意思決定事項、または主なフォローアップのテーマを示してください。
• 社内向けの要約は簡潔にし、重複を避け、チーム向けの内容にしてください。担当者または TBD を記載し、担当が決まっているかのように示さないでください。
• ユーザーが別のステータス形式を明示的に求めた場合を除き、Internal Follow-Up の後には必ず、上記のプレーンテキストのステータス行を記載してください。

エラー時の対応

通話内容の根拠を確認できない場合は、阻害要因を1行で示し、必要な証拠を伝え、候補となる通話や空欄の記入用テンプレートなど、安全な部分情報のみを返してください。任意の情報補完が利用できない場合でも、根拠に基づく内容を作成し、不足している項目を明記してください。