customer-research

/customer-research

見慣れないプレースホルダーがある場合や、どのツールが接続されているか確認する必要がある場合は、CONNECTORS.md をご覧ください。

顧客からの質問、製品に関するトピック、またはアカウントに関連する問い合わせについて、複数の情報源を調査します。利用可能なすべての情報源から得た調査結果を、明確な出典表示と信頼度スコアとともにまとめます。

使用方法

/customer-research <question or topic>

ワークフロー

1. 調査依頼を把握する

必要な調査の種類を特定します。

• 顧客からの質問：回答が必要な、顧客からの質問（例：「当社製品は Okta との SSO に対応していますか？」）
• 問題の調査：報告された問題に関する背景情報（例：「このバグは以前にも報告されていますか？既知の回避策はありますか？」）
• アカウントの状況：特定の顧客とのやり取りの履歴（例：「Acme Corp が前回これについて尋ねたとき、何と回答しましたか？」）
• トピックの調査：サポート業務に関連する一般的なトピック（例：「Webhook の再試行ロジックに関するベストプラクティス」）

検索を始める前に、何を調べようとしているのかを明確にします。

• これは明確な答えがある事実に関する質問ですか？
• 複数の視点が必要な、文脈に関する質問ですか？
• まだ範囲が定まっていない、探索的な質問ですか？
• 回答の対象者は誰ですか（社内チーム、顧客、経営陣）？

2. 利用可能な情報源を検索する

接続されている情報源に応じて調整しながら、以下の情報源の階層に沿って体系的に検索します。最初の検索結果だけで終わらせず、複数の情報源を相互参照します。

Tier 1 — 公式の社内情報源（最も信頼度が高い）：

• ~~ナレッジベース（接続されている場合）：製品ドキュメント、運用手順書、FAQ、ポリシー文書
• ~~クラウドストレージ：社内文書、仕様書、ガイド、過去の調査資料
• 製品ロードマップ（社内向け）：機能の予定、優先順位

Tier 2 — 組織内の状況：

• ~~CRM のメモ：アカウントのメモ、活動履歴、過去の回答、商談の詳細
• ~~サポートプラットフォーム（接続されている場合）：過去の解決策、既知の問題、回避策
• 議事録：過去の話し合い、決定事項、合意事項

Tier 3 — チーム内のコミュニケーション：

• ~~チャット：関連するチャンネルでトピックを検索し、チームメイトが以前にこの件について話し合ったり、回答したりしていないか確認します
• ~~メール：このトピックに関する過去のやり取りを検索します
• カレンダーのメモ：会議の議題と会議後のメモ

Tier 4 — 外部情報源：

• ウェブ検索：公式ドキュメント、ブログ記事、コミュニティフォーラム
• 公開ナレッジベース、ヘルプセンター、リリースノート
• サードパーティのドキュメント：連携パートナー、補完ツール

Tier 5 — 推論または類推（直接的な情報源で答えが得られない場合に使用）：

• 類似の状況：過去に同様の質問にどう対応したか
• 類似する顧客：同等のアカウントで何が効果的だったか
• 一般的なベストプラクティス：業界標準と慣行

3. 調査結果をまとめる

調査結果を、構成に沿った調査概要にまとめます。

## Research: [Question/Topic]

### Answer
[Clear, direct answer to the question — lead with the bottom line]

**Confidence:** [High / Medium / Low]
[Explain what drives the confidence level]

### Key Findings

**From [Source 1]:**
- [Finding with specific detail]
- [Finding with specific detail]

**From [Source 2]:**
- [Finding with specific detail]

### Context & Nuance
[Any caveats, edge cases, or additional context that matters]

### Sources
1. [Source name/link] — [what it contributed]
2. [Source name/link] — [what it contributed]
3. [Source name/link] — [what it contributed]

### Gaps & Unknowns
- [What couldn't be confirmed]
- [What might need verification from a subject matter expert]

### Recommended Next Steps
- [Action if the answer needs to go to a customer]
- [Action if further research is needed]
- [Who to consult for verification if needed]

4. 情報源が不十分な場合の対応

接続されている情報源から結果が得られない場合：

• トピックについてウェブ調査を行います
• ユーザーに社内の状況を尋ねます：
  • 「接続されている情報源では見つかりませんでした。この件に関する社内文書やナレッジベースの記事はありますか？」
  • 「チームでこのトピックについて話し合ったことはありますか？確認すべき ~~チャットチャンネルはありますか？」
  • 「答えを知っていそうな専門家はいますか？」
• 制約を明確に伝えます：
  • 「この回答はウェブ調査のみに基づいています。顧客に共有する前に、社内文書と照らし合わせて確認してください。」
  • 「回答の候補は見つかりましたが、信頼できる社内情報源では確認できませんでした。」

5. 顧客向けの回答に関する考慮事項

調査が顧客からの質問への回答を目的とする場合：

• 製品ロードマップ、価格、法務、セキュリティに関する内容があり、確認が必要な場合はその旨を示します
• 過去に伝えた可能性のある内容と回答が異なる場合は、その旨を記します
• 顧客向けの回答に適切な但し書きを提案します
• 顧客への回答の草案作成を提案します：「この調査結果に基づいて、顧客への回答案を作成しましょうか？」

6. ナレッジの蓄積

調査が完了したら、ナレッジの蓄積を提案します。

• 「今後の参考のために、これらの調査結果をナレッジベースに保存しましょうか？」
• 「この調査に基づいて、FAQ の項目を作成しましょうか？」
• 「これは文書化する価値がありそうです。手順書の項目を作成しましょうか？」

これにより、組織のナレッジを蓄積し、チーム内で重複した調査にかかる労力を減らせます。

---

情報源の優先順位と確信度

情報源の階層ごとの確信度

階層	情報源の種類	確信度	備考
1	公式の社内文書、ナレッジベース、ポリシー	高	明らかに古くなっていない限り信頼します。日付を確認してください
2	CRM、サポートチケット、会議メモ	中〜高	主観的または不完全な場合があります
3	チャット、メール、カレンダーのメモ	中	非公式であり、文脈を欠いていたり、推測を含んでいたりする場合があります
4	ウェブ、フォーラム、サードパーティの文書	低〜中	お客様固有の状況を反映していない場合があります
5	推論、類推、ベストプラクティス	低	事実ではなく推論であることを明確に示します

確信度のレベル

常に確信度を割り当て、伝えてください。

確信度：高

• 公式ドキュメントまたは信頼できる情報源で回答を確認できる
• 複数の情報源が同じ回答を裏付けている
• 情報が最新である（妥当な期間内に検証済み）
• 「[情報源] に基づき、これは正確だと確信しています。」

確信度：中

• 公式ドキュメントではなく、チャットやメールなどの非公式な情報源で回答が見つかった
• 裏付けのない単一の情報源
• 情報がやや古い可能性はありますが、現在も有効である可能性が高い
• 「[情報源] に基づくと、これが該当するようですが、[チーム／担当者] に確認することをおすすめします。」

確信度：低

• 関連情報から回答を推論している
• 情報源が古い、または信頼性に欠ける可能性がある
• 情報源間で矛盾する情報が見つかった
• 「確定的な回答は見つかりませんでした。[文脈] に基づく最善の判断は [回答] ですが、お客様に共有する前に確認する必要があります。」

判断不能

• いずれの情報源にも関連情報が見つからない
• 質問への回答に、情報源から得られない専門知識が必要
• 「これに関する情報は見つかりませんでした。確定的な回答を得るには、[推奨する専門家／チーム] に問い合わせることをおすすめします。」

矛盾への対処

情報源間で見解が異なる場合：

1. 矛盾があることを明確に記載する
2. どの情報源がより信頼できるか、または新しいかを特定する
3. 文脈を添えて、両方の見解を提示する
4. 相違を解消する方法を提案する
5. お客様に回答する場合：解決するまでは、最も慎重な回答を使用する

エスカレーションするか、直接回答するか

直接回答する場合：

• 公式ドキュメントに質問への明確な回答が記載されている
• 複数の信頼できる情報源が回答を裏付けている
• 質問が事実に関するもので、機密性がない
• 回答に約束、スケジュール、価格が含まれない
• 同様の質問に以前回答し、その正確性が確認されている

エスカレーションまたは確認が必要な場合：

• 回答に製品ロードマップの確約やスケジュールが含まれる
• 価格、法的条件、契約固有の質問
• セキュリティ、コンプライアンス、データの取り扱いに関する質問
• 回答が前例となったり、期待を生み出したりする可能性がある
• 情報源間で矛盾する情報が見つかった
• 特定のお客様のカスタム構成に関する質問
• 自分にない専門知識が回答に必要
• お客様がリスクにさらされており、誤った回答によって状況が悪化する可能性がある

エスカレーション先：

1. 分野の専門家：技術的または特定の分野に関する質問
2. 製品チーム：ロードマップ、機能、または性能に関する質問
3. 法務／コンプライアンス：条件、プライバシー、セキュリティ、または規制に関する質問
4. 請求／財務：価格、請求書、または支払いに関する質問
5. エンジニアリング：カスタム構成、バグ、または技術的な根本原因
6. リーダーシップ：戦略的な判断、例外、または重大な状況

チームナレッジベース用の調査ドキュメント

調査が完了したら、今後活用できるように知見を記録します。

ドキュメント化するタイミング：

• 同じ質問が以前にも出たことがある、または今後も出る可能性が高い
• 調査にかなりの労力を要した
• 複数の情報源を統合して回答をまとめた
• よくある誤解を正す回答だった
• 誤解しやすいニュアンスを含む回答だった

ドキュメントの形式：

## [Question/Topic]

**Last Verified:** [date]
**Confidence:** [level]

### Answer
[Clear, direct answer]

### Details
[Supporting detail, context, and nuance]

### Sources
[Where this information came from]

### Related Questions
[Other questions this might help answer]

### Review Notes
[When to re-verify, what might change this answer]

ナレッジベースの管理：

• すべての項目に日付を記載します
• 特定の製品バージョンや機能に言及している項目にはフラグを付けます
• 四半期ごとに項目を見直し、更新します
• 関連性がなくなった項目はアーカイブします
• 検索しやすいように、トピック、製品分野、顧客セグメント別にタグを付けます