customer-intel

調査フレームワーク

フェーズ 1 — 問いを定義する

情報源に触れる前に、何を見つける必要があるのかを明確にします。

• 確定的な事実：正解が一つだけ存在します（例：「API はバッチリクエストに対応していますか？」）。
• 背景を踏まえた全体像：複数の観点をまとめる必要があります（例：「このアカウントは前四半期にどのような経験をしましたか？」）。
• 自由な探索：問いの範囲がまだ定まっていません（例：「エンタープライズ顧客がオンボーディングに苦労しているのはなぜですか？」）。
• 対象者への配慮：回答を読むのが誰なのかを判断します。顧客本人、社内チームのメンバー、経営幹部のいずれかによって、適切なトーン、詳しさ、含める内容が変わります。

フェーズ 2 — 問いの種類に応じて情報源を割り当てる

問いのカテゴリ	主な情報源
製品の機能	公式ドキュメント、API リファレンス、ナレッジベース、製品仕様
アカウントの履歴と背景	CRM の記録、メールのスレッド、会議メモ、チャットログ
社内のプロセスやポリシー	Wiki、運用手順書、ポリシー文書
技術的なトラブルシューティング	ドキュメント、エンジニアリング関連の情報、過去のサポートチケット
市場や競合の状況	ウェブ検索、アナリストレポート、競合情報

フェーズ 3 — 段階ごとに証拠を集める

信頼性が最も高い情報源から順に確認します。一つの検索結果だけに頼らず、複数の経路で裏付けを取ってください。

ティア 1：正式な社内記録（信頼性：高） 公式ドキュメント、公開済みのナレッジベース記事、API リファレンス、ポリシーおよび SLA 文書、社内の製品ロードマップ。日付が古い場合を除き、これらの情報を信頼してください。

ティア 2：組織内の記録（信頼性：中〜高） CRM のアカウントメモや活動ログ、解決済みのサポートチケットや既知の問題データベース、共有ドキュメントや仕様書、会議メモに記録された決定事項。

ティア 3：非公式なチーム内のチャネル（信頼性：中） Slack やチャットでのやり取り、メールのやり取り、カレンダーや議題のメモ。これらには最新の情報が含まれていることがよくありますが、背景情報が不足していたり、推測が含まれていたりする可能性があります。

ティア 4：公開情報および外部情報源（信頼性：さまざま） 企業や競合他社のウェブサイト、コミュニティフォーラムやユーザー間の議論、パートナーのドキュメント、業界ニュースやアナリストの見解。

ティア 5：類推による推論（信頼性：低） 過去の類似した状況から得られる先例、類似するアカウントのパターン、業界全般の慣例。これらは必ず推論であることを明記してください。

フェーズ 4 — 回答をまとめる

調査結果をまとめ、情報源間の矛盾を明示し、全体的な信頼度を付けます。

フェーズ 5 — すべてに出典を付ける

回答内のすべての主張について、名前を明記した情報源をたどれるようにしてください。出典のない主張は認められません。

信頼度の評価基準

提示するすべての回答に、次の評価のいずれかを付けてください。

高い信頼度

• 正式なドキュメントまたは権威ある社内記録による裏付けがある
• 独立した情報源が少なくとも二つあり、内容が一致している
• 情報が最新であることを確認済み
• 表現例：「これは［情報源］によって十分に裏付けられています。」

中程度の信頼度

• チャットやメールなどの非公式なチャネルで見つかったが、公式ドキュメントによる裏付けがない
• 裏付けのない単一の情報源に基づいている
• 日付が古い可能性はあるが、現在も正確である可能性が高い
• 表現例：「［情報源］によると、これは正しいようです。［チーム／担当者］に確認することをおすすめします。」

低い信頼度

• 間接的な推論または類推に基づいている
• 情報源が古い、または信頼性が不明である
• 複数の情報源の内容が互いに矛盾している
• 表現例：「決定的な情報源は見つかりませんでした。［背景情報］に基づく現時点での評価は［回答］です。顧客に伝える前に確認することをおすすめします。」

情報不足

• 関連する資料がどこにも見つからない
• 問いに答えるには、利用可能な情報源の範囲を超える専門知識が必要である
• 表現例：「関連情報を見つけられませんでした。［推奨する専門家またはチーム］への相談をおすすめします。」

情報源の食い違いへの対処

異なる情報源の内容が食い違う場合：

1. 食い違いを明確に示します。一方の見解を黙って選ぶことは決してありません
2. 食い違う情報源の新しさと信頼性を評価します
3. 読み手が状況を理解できるよう、双方の見解を背景情報とともに提示します
4. 解決に向けた方法を提案します（例：プロダクトチームに確認する）
5. 顧客向けの回答では、食い違いが解消されるまで、最も慎重な見解を採用します

構造化された回答形式

**Answer:** [Lead with the bottom line]

**Confidence:** [Strong / Moderate / Weak]

**Evidence:**
- [Source A]: [What it states]
- [Source B]: [Corroborating or contrasting detail]

**Limitations:**
- [Conditions or edge cases that could change the answer]
- [Context-specific factors to be aware of]

**Next Steps:**
- [Whether this is safe to relay to the customer as-is]
- [Any recommended verification actions]

エスカレーションするタイミングの判断

そのまま回答しても問題ない場合

• 公式ドキュメントで質問に明確に答えられる
• 複数の信頼できる情報源の内容が一致している
• 話題が事実に関するもので、機密性がない
• 納期、価格、法的条件に関する確約が含まれない

専門家に引き継ぐ場合

• ロードマップに関する確約や提供時期が関係する
• 質問が価格、契約、法的条件に関わる
• セキュリティ、コンプライアンス、データの取り扱いに関する話題
• 回答が拘束力のある前例となったり、期待を生じさせたりする可能性がある
• 食い違う情報が見つかり、未解決のままである
• 顧客固有の設定が関係する
• アカウントが危機に瀕しており、誤った回答によって状況が悪化する可能性がある

エスカレーション先

1. 分野の専門家 — 技術的または専門的な知識の不足
2. プロダクトチーム — 機能、ロードマップ、機能に関する質問
3. 法務／コンプライアンス — 規制、プライバシー、契約上の問題
4. 財務／請求 — 価格、請求書、支払いに関する問題
5. エンジニアリング — バグ、カスタム設定、根本原因の分析
6. リーダーシップ — 戦略的な意思決定、ポリシーの例外、重大な状況

調査結果を再利用できる形で記録する

記録する価値がある場合：

• 同じ質問が以前にも寄せられた、または今後も寄せられる可能性が高い
• 調査にかなりの労力を要した
• 回答によって広く見られる誤解が正される
• 間違えやすい細かな点がある

再利用可能な記録の形式

## [Topic or Question]

**Verified On:** [date]
**Confidence:** [rating]

### Finding
[Concise, direct answer]

### Context and Nuance
[Background, conditions, and subtleties]

### Source Trail
[Where this information originated]

### Adjacent Topics
[Related questions this entry may also answer]

### Freshness Notes
[When to re-check, what developments could invalidate this]

ナレッジストアの管理

• 各記録にタイムスタンプを付けます
• 特定の製品バージョンや機能の状態に関連する記録には、その旨を明記します
• 古くなったコンテンツを削除するため、定期的な見直しを予定します
• 見つけやすいよう、分野、製品領域、顧客セグメントごとに記録にタグを付けます

運用原則

1. 検索を始める前に、何を探しているのかを正確に定めます
2. 情報源の優先順位に従って段階的に確認します。根拠のない推測で段階を飛ばしてはいけません
3. 可能な限り、複数のチャネルで裏付けを取ります
4. 不確かな調査結果を確定した事実として提示してはいけません。確信度を必ず明示します
5. 回答を外部に共有してよいか判断に迷った場合は、まず確認します
6. 次の担当者が同じ作業を繰り返さずに済むよう、調査結果を記録します
7. 調査でナレッジの不足が判明した場合は、ドキュメント化が必要であることを報告します