【sales / negotiation task brief】
利用場面: 初回ヒアリング前の提案準備
目的: 顧客課題を事実、仮説、要確認に分け、提案骨子と反論処理台帳を作る
読み手: 営業担当、提案責任者、プリセールス、プロダクト責任者
相手の想定: 業務部門長、現場リーダー、情報システム担当
意思決定点:
  1. 初回ヒアリングで必ず確認する質問を決める
  2. 提案仮説を「提示可能」「要確認」「提示不可」に分ける
  3. 想定反論に対する回答方針と保留条件を決める
入力禁止情報:
  - 顧客名
  - 見積金額
  - 契約条件
  - 個人名 / 個人評価
  - 未公開の商談情報
  - 競合固有の未確認情報
承認者: 提案責任者。価格、契約、セキュリティ例外は各責任者が別途承認する

【既知情報】
顧客の業務領域:
- 問い合わせ対応を行う業務部門
- 現行運用はメールとスプレッドシート中心

観測されている課題:
A. 回答品質にばらつきがある
B. 新任者の立ち上がりに時間がかかる
C. ナレッジが個人メモや過去メールに分散している
D. セキュリティ要件があり、外部サービス利用可否は未確認

既知の制約:
- 顧客名、契約条件、見積金額はAIへ入力しない
- 導入可否は情報システム部門の確認が必要
- 現場負荷を増やす提案は受け入れられにくい可能性がある
- 効果数値は未測定のため断定しない

不明点:
- 意思決定者と承認フロー
- 成功条件と評価指標
- 対象業務の範囲
- 既存FAQやナレッジの品質
- セキュリティ、契約、データ保持条件
- 予算、期限、導入体制

顧客に提案したいので、ヒアリング項目と提案書を作ってください。

# ヒアリング項目

- 現状の課題は何ですか
- 予算はいくらですか
- いつまでに必要ですか
- どのような機能がほしいですか

# 提案書

当社は最高のソリューションを提供します。
問い合わせ対応を効率化し、業務品質を向上させます。
短期間で導入でき、現場の負担を減らせます。

あなたはB2B営業ヒアリングと提案レビューを支援します。
以下の条件を守り、初回ヒアリング設計、提案骨子、反論処理台帳、承認前チェックを作ってください。

【目的】
顧客課題を事実、仮説、要確認に分け、提案骨子と反論処理台帳を作る。

【読み手】
営業担当、提案責任者、プリセールス、プロダクト責任者。

【相手の想定】
業務部門長、現場リーダー、情報システム担当。

【意思決定点】
1. 初回ヒアリングで必ず確認する質問を決める
2. 提案仮説を「提示可能」「要確認」「提示不可」に分ける
3. 想定反論に対する回答方針と保留条件を決める

【既知情報】
- 問い合わせ対応を行う業務部門
- 現行運用はメールとスプレッドシート中心
- 回答品質にばらつきがある
- 新任者の立ち上がりに時間がかかる
- ナレッジが個人メモや過去メールに分散している
- セキュリティ要件があり、外部サービス利用可否は未確認

【不明点】
- 意思決定者と承認フロー
- 成功条件と評価指標
- 対象業務の範囲
- 既存FAQやナレッジの品質
- セキュリティ、契約、データ保持条件
- 予算、期限、導入体制

【制約】
- 顧客名、見積金額、契約条件、個人情報、未公開商談情報、競合固有情報は扱わない
- 効果数値は未測定のため断定しない
- 法務、契約、セキュリティ例外、価格は営業担当だけで回答しない
- 事実、仮説、要確認、推奨を分ける
- 回答してよい範囲と保留条件を明示する

【出力仕様】
A. sales / negotiation task brief
B. discovery question map
C. proposal strategy canvas
D. objection / concern register
E. evidence-to-document traceability matrix
F. approval log / next action
G. 人間が確認すべき点

# A. sales / negotiation task brief

目的:
顧客課題を事実、仮説、要確認に分け、提案可否を判断する。

提案前に確認すること:
- 意思決定者と承認フロー
- 成功条件と評価指標
- 対象業務と除外範囲
- 情報分類と外部サービス利用可否
- 導入体制、期限、予算の有無

# B. discovery question map

| 質問 | 意図 | 得たい判断材料 | 回答後の使い道 |
| --- | --- | --- | --- |
| 今回の検討で何を決める必要がありますか | 意思決定点の確認 | 決裁者、承認フロー | 提案範囲と次アクション |
| 回答品質のばらつきは、どの業務で問題になっていますか | 対象範囲の確認 | 対象業務、頻度、影響 | 提案対象の絞り込み |
| 成功条件は何ですか | 評価軸の確認 | KPI、品質基準 | 検証計画 |
| 扱う情報の区分は何ですか | 情報分類の確認 | 入力可能情報、禁止情報 | セキュリティ確認 |

# C. proposal strategy canvas

推奨方針:
まず対応手順とナレッジの標準化を行い、その後に自動化範囲を検討する。

根拠:
現時点の既知情報では、属人化と知識分散が主要課題である可能性が高い。ただし、対象業務、成功条件、情報分類は要確認。

# D. objection / concern register

| 懸念 | 背景 | 回答方針 | 保留条件 |
| --- | --- | --- | --- |
| 効果が分からない | 投資判断 | 小さく検証し、評価指標を定義する | 効果数値保証を求められた場合 |
| 情報漏洩が怖い | セキュリティ | 情報分類と入力禁止情報を先に決める | 例外利用を求められた場合 |

# E. evidence-to-document traceability matrix

| 主張 | 根拠 | 確認状態 | 本文での扱い |
| --- | --- | --- | --- |
| 標準化から始める | ナレッジ分散が課題という既知情報 | 要確認 | 仮説として記載 |

# F. approval log / next action

| Action | 担当 | 状態 | 承認 / 確認 |
| --- | --- | --- | --- |
| 情報分類を確認する | 情報システム担当 | 要確認 | セキュリティ担当確認 |

# G. 人間が確認すべき点

- 顧客発言を事実、仮説、要確認に分けているか
- 価格、契約、法務、セキュリティの回答範囲を越えていないか
- 効果数値や納期を未確認のまま断定していないか

# 初回ヒアリング設計メモ

## 目的
顧客の問い合わせ対応業務について、課題、制約、成功条件、承認フローを確認し、提案骨子を作れる状態にする。

## 確認対象
- 業務部門長: 業務課題、成功条件、優先度
- 現場リーダー: 現行運用、負荷、例外対応
- 情報システム担当: 情報分類、利用可能なツール、セキュリティ制約

## 入力禁止情報
- 顧客名
- 見積金額
- 契約条件
- 個人名 / 個人評価
- 未公開の商談情報
- 競合固有の未確認情報

## 本日確認する意思決定材料
1. 提案対象にする業務範囲
2. 成功条件と評価指標
3. 情報分類と外部AI利用可否
4. 導入体制、期限、予算の有無
5. 提案前に社内承認が必要な事項

# 提案骨子: 問い合わせ対応標準化の段階導入

## 結論
問い合わせ対応の品質ばらつきに対して、最初から全面自動化を目指すのではなく、対応手順とナレッジの標準化から始めることを提案します。そのうえで、情報分類と成功条件が確認できた範囲から、AI支援の適用可能性を検証します。

## 背景課題（仮説）
- 回答品質にばらつきがある
- 新任者の立ち上がりに時間がかかる
- ナレッジが個人メモや過去メールに分散している
- セキュリティ要件により、利用できるデータとツールに制約がある可能性がある

## 提案範囲
1. 対象問い合わせカテゴリを選ぶ
2. 標準回答手順とレビュー観点を整理する
3. ナレッジ更新責任者と更新頻度を決める
4. 情報分類を確認し、AI支援に使える入力範囲を決める
5. 小規模検証で品質、運用負荷、再利用性を確認する

## 提案しないこと
- 効果数値の保証
- 未確認の契約条件への回答
- 顧客固有データを外部AIへ入力する運用
- セキュリティ例外の営業判断

## 要確認事項
- 意思決定者と承認フロー
- 対象業務の範囲
- 成功条件と評価指標
- 情報分類と外部サービス利用可否
- 運用責任者、レビュー頻度、更新体制

【sales / negotiation task brief】
利用場面:
目的:
読み手:
相手の想定:
意思決定点:
既知情報:
不明点:
入力禁止情報:
提案してよい範囲:
提案してはいけない範囲:
想定反論:
承認者:
次アクション: