ケーススタディ3：営業ヒアリング→提案骨子→反論処理
1. 目的 / 読み手 / 制約 / 機密区分
- 目的: 顧客課題を誤解なく把握し、提案の骨子と反論対応までを準備する
- 読み手: 営業担当＋提案書の作成・レビューに関わるメンバー
- 制約: 顧客固有情報は抽象化する。契約/法務判断が必要な事項は断定しない
- 機密区分: 顧客名、見積金額、契約条件、個人情報は入力しない（伏せ字・抽象化）
標準手順は AI活用の標準業務フロー（1枚） を参照してください。
2. 初期プロンプト（例）
顧客に提案したいので、ヒアリング項目と提案書を作ってください。
3. 初回出力（抜粋）と課題（例）
ヒアリング項目:
- 現状の課題は何ですか
- 予算はいくらですか
- いつまでに必要ですか
提案書:
- 最高のソリューションを提供します
主な課題:
- 質問が抽象的で、意思決定条件（評価軸・制約・体制）が取れない
- 提案骨子が根拠不足で、読み手が判断できない
- 想定反論（価格/リスク/体制/スケジュール）への準備がない
4. CARE評価（問題点と改善方針）
- 正確性: 顧客状況が未入力 → 既知情報と不明点を分けて入力し、質問を絞る
- 適切性: 営業の実務に必要な観点が不足 → 「誰が決めるか/評価軸/制約/現行運用」を必須にする
- 関連性: 提案に繋がる情報が取れない → 質問を「意思決定に必要な情報」に寄せる
- 効果性: 反論対応まで到達しない → 反論パターンと回答方針を出力に含める
5. 改善プロンプト（例）
【背景】B2B提案の事前準備です。顧客の課題を正確に把握し、提案の骨子と反論対応を準備したいです。
【既知情報（サンプル）】顧客は「問い合わせ対応の属人化」と「回答品質のばらつき」に悩んでいる。現行はメール中心。
【不明点】意思決定者、評価軸、予算レンジ、セキュリティ要件、導入期限、運用体制。
【制約】顧客名や契約条件などの機密は扱わない。法務・契約判断が必要な点は断定しない。
【成果物】次の3つを出力:
A) ヒアリング項目（質問＋質問の意図＋得たい判断材料）
B) 提案骨子（結論→根拠→具体案→リスクと対策→次アクション）
C) 想定反論5つと回答方針（根拠/要確認/代替案）
6. 改善後出力（抜粋）
A) ヒアリング項目（例）
- Q: この提案で「何を決める必要がありますか」（意図: 意思決定点を確定）/ 判断材料: 決裁者・承認フロー
- Q: 成功条件は何ですか（意図: 評価軸の明確化）/ 判断材料: KPI・品質基準
- Q: 扱う情報の区分は何ですか（意図: 情報分類）/ 判断材料: 外部サービス利用可否
B) 提案骨子（例）
- 結論: 問い合わせ対応の標準化とナレッジ化を先に整備し、段階的に自動化を検討する
- 根拠: 属人化の原因は「手順不統一」と「知見の再利用不足」にある可能性（要確認）
7. 最終成果物（反論処理までの準備メモのサンプル）
# 提案準備メモ（サンプル）
## 結論（提案の方向性）
- まず「対応手順の標準化」と「ナレッジの整備」を実施し、次に自動化範囲を段階導入する
## 期待効果（仮説）
- 回答品質のばらつき低減（標準手順＋レビュー）
- 立ち上がりの短縮（ナレッジ再利用）
## リスクと対策（例）
- リスク: 現場運用が回らず形骸化 → 対策: 最小の入力項目に絞り、週次でレビュー
- リスク: セキュリティ要件に抵触 → 対策: 情報分類を先に確定（要確認）
## 想定反論と回答方針（例）
- 反論: 「費用対効果が不明」→ 回答: 成功条件（KPI）を定義し、Small Startで検証する（要確認: KPI）
- 反論: 「情報漏洩が怖い」→ 回答: 機密区分を確定し、入力範囲を制御する（要確認: 社内ルール）
- 反論: 「運用が回らない」→ 回答: 既存手順に組み込み、担当と時間を固定する
8. 承認ゲート / 責任者 / ログ（最低限）
- 責任者（最終）: 提案オーナー（例: 営業責任者/プロダクト責任者）
- 承認ゲート（例）: 提案骨子レビュー → 見積/条件の確定（要法務）→ 顧客提示
- ログ（最低限）:
- ヒアリング結果（事実/推測を区別）
- 提案骨子（版管理）
- 想定反論と回答方針（要確認事項の一覧）