顧客・営業見込み客のフォローアップトラッカーを設計する

著者: AILesson8 分でセットアップテスト済み:ChatGPTレビュー日: 2026-08-28

クイック回答

緊急性や約束を作り出さず、同意、担当者、直近のやり取り、合意済みの次の行動、期限、終了を追跡する. 入力するもの: フォローアップのワークフローと境界, フィールド、システム、例, 状態、リマインダー、プライバシーのルール. 期待される結果: 状態ルール、キュー、数式、プライバシー管理を備えたレビュー可能なフォローアップ用ワークブック.

1

コンテキストを追加

テキストはこのブラウザ内に留まります。AILesson Prompts は、そのテキストをモデルやサーバーに送信しません。

2

あなたのプロンプト

未入力のフィールドはプレースホルダーとして表示されたままなので、プロンプトをコピーして編集できます。

記載された顧客または営業のワークフロー向けに、Excel のフォローアップトラッカーを設計してください。

種類、段階、連絡権限、同意、担当者、引き継ぎ、時期、終了、支援する判断:
[workflow]

粒度、ID、顧客データ、情報源、同意、段階、金額、やり取り、次の行動、日付、担当者、結果、更新、サンプル:
[data]

状態、必須フィールド、期限超過、タイムゾーン、陳腐化、抑制、重複、アクセス、保持、レポート:
[rules]

指定された粒度に従い、見込み客/商談/顧客案件ごとに安定したレコードを1件使用します。複数回の接触がある場合は、やり取りの履歴を別の追記専用テーブルに保存してください。観察されたやり取り、顧客の依頼、販売者の提案、合意済みの次の行動、社内タスクを区別します。沈黙、メール開封、段階ラベルから、同意、購入意向、権限、金額、期限、約束を推測してはいけません。承認済みの連絡頻度または明示的な次の行動によって日付が指定されている場合に限り、フォローアップを期限到来として扱えます。抑制、終了状態、担当者不在、プライバシー制限は、通常の期限超過リマインダーより優先しなければなりません。次の内容を返してください:ワークブック構成、データ辞書、状態遷移ルール、必須フィールドマトリクス、NextActionStatus とデータ品質の数式、担当者別キュー、入力規則リスト、条件付き書式、重複と引き継ぎのワークフロー、プライバシー/アクセス/保持の管理、分母付きのダッシュボード件数、サンプル行、`new`、`due`、`overdue`、`waiting`、`suppressed`、`closed`、同意不足、担当者不在、重複、日付矛盾の各テスト。
Playgroundで試す
デフォルトで非公開プロンプトの組み立てはブラウザ内で行われます。組織が許可しない限り、機密情報を AI サービスに入力しないでください。

入力から結果へ

具体例

具体的なコンテキストを加えると、このレシピが実用的な結果になる様子をご覧ください。

実際の入力

フォローアップのワークフローと境界
B2B の受信デモ依頼と既存商談。連絡先ごとではなく、OpportunityID ごとに1行を使います。ConsentStatus が Allowed の場合、または既存取引先に関するルールが文書化されている場合に限り、メールでフォローアップできます。Suppressed は連絡禁止を意味します。段階は New、Discovery、Evaluation、WaitingCustomer、Won、Lost。担当者は引き継ぎを明示的に受け入れます。標準の連絡頻度:New の見込み客には1営業日以内に初回応答し、それ以降は合意済みの次回日付または担当者が設定した社内レビュー日だけを使います。トラッカーは担当者の日次キューとマネージャーによる業務量レビューを支援しますが、メールの自動送信や見込み客スコアリングは行いません。
フィールド、システム、例
Opportunities のフィールド:OpportunityID、AccountName、ContactName、WorkEmail、Source、ConsentStatus、ConsentEvidence、Stage、EstimatedValue、Currency、Owner、OwnerAcceptedAt、LastInteractionAt、LastInteractionType、LastInteractionEvidence、AgreedNextStep、NextActionDate、NextActionType、WaitingOn、SuppressedAt、ClosedAt、OutcomeReason、UpdatedAt。Interactions テーブルのフィールド:InteractionID、OpportunityID、At、Direction、Channel、Summary、EvidenceLocator、RecordedBy。例 O-104:受信フォーム、ConsentStatus は Allowed、フォーム記録 F-88 あり、New、担当者 Mei が8月28日に受け入れ、やり取りなし、上海時間の8月28日15:00に作成。O-107:Evaluation、直近の通話は8月27日。顧客はセキュリティ文書を確認し、社内会議後に返信すると述べたが、日付は示していない。担当者は Leo。O-109:8月26日のオプトアウト後に Suppressed。以前のフォローアップ日8月29日が残っている。
状態、リマインダー、プライバシーのルール
レビュー日は2026-08-31、タイムゾーンは Asia/Shanghai。営業日カレンダーは Holidays テーブルにあります。New の必須項目:同意の証拠、担当者の受け入れ、作成時刻。Evaluation には直近のやり取りの証拠が必要です。NextActionDate は、合意済みまたは明示的な社内用の日付である場合に限り設定できます。WaitingCustomer では日付を創作しません。Suppressed と Won/Lost は期限超過になりません。担当者不在は Data issue。WorkEmail の重複だけでは商談の重複と判断しません。OpportunityID の重複は無効です。ワークブックへのアクセスは営業オペレーションに限定します。保持ポリシーは提示されていないため、pending と表示します。

出力例

ワークブック:現在状態を保持する Opportunities、追記専用履歴の Interactions、ValidationLists、BusinessCalendar、OwnerQueue、DataIssues、Dashboard、ChangeLog。EstimatedValue/Currency は任意とし、Stage から成約確率を推測してはいけません。

状態の優先順位:ID の重複または必須フィールドの矛盾 → Data issue。Suppressed → 古い日付にかかわらず Do not contact。Won/Lost → Closed。Owner が不在または未受け入れ → Handoff required。New でやり取りなし → 承認済みの営業日カレンダー規約に従い、CreatedAt から WORKDAY.INTL で初回応答期限を計算。WaitingCustomer で日付なし → Waiting、期限超過にはしない。根拠のある社内用または合意済みの NextActionDate がレビュー日より前 → Overdue。レビュー日と同じ → Due today。将来 → Scheduled。次の行動に有効な根拠がない → Needs plan、期限超過にはしない。O-109 は Do not contact であり、残っている古い日付は変更を記録した場合にのみ消去します。O-107 は Waiting/Needs internal review。顧客の「社内会議後」という発言は暦日上の約束ではありません。O-104 の正確な期限には、時刻と週末の締切に関する承認済みルールが必要です。タイムスタンプを暗黙に日付だけへ縮めてはいけません。

必須フィールドマトリクス:すべての未終了レコードに、安定 ID、情報源、同意の状態/証拠、担当者/受け入れ、Stage、UpdatedAt が必要です。Evaluation にはやり取りの位置情報が必要です。顧客と合意した NextActionDate には Interactions 内の証拠が必要です。社内用の日付には NextActionType が Internal であることと担当者が必要です。条件付き書式は状態テキストに従い、抑制を最優先とし、色だけで意味を伝えてはいけません。Dashboard には、適格かつ未終了の分母、担当者別の Due/Overdue、Waiting、Handoff required、Data issue、Suppressed、終了件数を表示します。コホートと時間枠の定義がなければ「conversion」を計算してはいけません。アクセスは指定どおり制限します。保持ポリシーは明示的な未解決事項のままなので、担当者と期間が提示されるまで、ワークブックはコンプライアンス準拠を主張できません。テストでは、優先順位の全分岐、境界日の処理、Suppressed/Closed レコードに残る古い日付、同意証拠の欠損、ID の重複、同じメールアドレスを共有する2件の商談を扱います。

これがうまくいく理由

  1. 1

    やり取りと合意済みの次の行動を分けることで、会話を顧客の約束として記録するのを防げます。

  2. 2

    優先順位ルールにより、同意と抑制の管理が期限超過を示す色で上書きされないようにできます。

結果を確認

  • 同意、抑制、情報源、担当者、段階、直近のやり取り、合意済みの次の行動、次回日付には、推測ではなく証拠がありますか?

  • 抑制、終了状態、権限不足、プライバシー、担当者不在は、期限到来/期限超過のリマインダーより優先されますか?

  • ダッシュボードの各件数を、相互排他的なレコード状態と明示された分母に照合できますか?

安心して使うために

よくある質問

このレシピをいつ使うか、何を用意するか、どの場面で人による確認が依然として重要かについての実践的な回答です。

「顧客・営業見込み客のフォローアップトラッカーを設計する」を使用する前に、何を準備すればよいですか?

「顧客・営業見込み客のフォローアップトラッカーを設計する」を使用するには、フォローアップのワークフローと境界、フィールド・システム・例、状態・リマインダー・プライバシーのルールを準備してください。プレースホルダーは、確認可能な情報だけで置き換えます。詳細が不明な場合は、モデルに推測させず、不明であることを明示してください。

「顧客・営業見込み客のフォローアップトラッカーを設計する」の結果は、どのような場合にまだ使用できませんか?

提示された証拠から、記載された成果である「状態ルール、キュー、数式、プライバシー管理を備えたレビュー可能なフォローアップ用ワークブック」をまだ作成できていない場合や、未解決の前提、承認の不足、創作した詳細に依存している場合、その結果は使用できません。チェック項目を公開可否の判断基準として使い、裏付けのない出力を磨くのではなく、元の入力を修正するか、権限を持つ担当者を指名してレビューを依頼してください。

「顧客・営業見込み客のフォローアップトラッカーを設計する」では、どの AI ツールのテスト記録がありますか?

2026-08-28 時点で、「顧客・営業見込み客のフォローアップトラッカーを設計する」の公開テスト記録には ChatGPT が掲載されています。これは実行記録があることを示すだけで、今後の製品バージョンとの互換性や同一の結果を保証するものではありません。別のツールやバージョンでは、すべての制約を明示したまま、使用前に結果のチェック項目をもう一度確認してください。

作業を前に進める