/customer-research

不慣れなプレースホルダーを見かけた場合または接続されているツールを確認する必要がある場合は、CONNECTORS.md を参照してください。

顧客の質問、製品トピック、またはアカウント関連の問い合わせに関する複数ソースからのリサーチ。すべての利用可能なソースからの調査結果を明確な出典表記と信頼度スコアで統合します。

使用方法

/customer-research <質問またはトピック>

ワークフロー

1. リサーチリクエストの解析

必要なリサーチのタイプを特定します:

• 顧客からの質問: 顧客が答える必要のある質問 (例: 「弊社の製品は Okta による SSO に対応していますか?」)
• 問題調査: 報告された問題の背景 (例: 「このバグは以前報告されていますか? 既知の回避策はありますか?」)
• アカウント情報: 特定の顧客との履歴 (例: 「Acme Corp がこの質問をした時に何を伝えましたか?」)
• トピックリサーチ: サポート業務に関連する一般的なトピック (例: 「Webhook 再試行ロジックのベストプラクティス」)

検索前に、実際に何を見つけようとしているのかを明確にします:

• これは確定的な答えを持つ事実的な質問ですか?
• これは複数の視点を必要とする状況依存的な質問ですか?
• これはスコープが未だに定義されている調査的な質問ですか?
• 答えの対象者は誰ですか (内部チーム、顧客、経営陣)?

2. 利用可能なソースの検索

以下のソース階層を通じて体系的に検索し、接続されているものに合わせて調整します。最初の結果で止まらず、複数のソースを相互参照してください。

階層 1 — 公式な内部ソース (最も高い信頼性):

• ナレッジベース (接続されている場合): 製品ドキュメント、手順書、FAQ、ポリシー文書
• クラウドストレージ: 内部ドキュメント、仕様、ガイド、過去のリサーチ
• 製品ロードマップ (内部向け): 機能タイムライン、優先順位

階層 2 — 組織的背景:

• CRM ノート: アカウント情報、アクティビティ履歴、以前の回答、商談詳細
• サポートプラットフォーム (接続されている場合): 過去の解決策、既知の問題、回避策
• ミーティングノート: 過去の議論、決定、約束

階層 3 — チーム内通信:

• チャット: 関連するチャンネルでトピックを検索; 同僚がこれまでに議論または答えているかどうかを確認
• メール: このトピックに関する過去の対応を検索
• カレンダーノート: 会議の議題とミーティング後のノート

階層 4 — 外部ソース:

• Web 検索: 公式ドキュメント、ブログ記事、コミュニティフォーラム
• 公開ナレッジベース、ヘルプセンター、リリースノート
• サードパーティドキュメント: 統合パートナー、補完的なツール

階層 5 — 推論または類推 (直接的なソースが答えを提供しない場合に使用):

• 類似の状況: 以前に類似の質問がどのように処理されたか
• 類似の顧客: 同等のアカウントで何が機能したか
• 一般的なベストプラクティス: 業界標準と慣例

3. 調査結果の統合

結果を構造化されたリサーチブリーフにまとめます:

## リサーチ: [質問/トピック]

### 回答
[質問への明確で直接的な回答 — 結論から始める]

**信頼度:** [高 / 中 / 低]
[信頼度レベルを左右する理由を説明]

### 主な調査結果

**[ソース 1] より:**
- [具体的な詳細を含む調査結果]
- [具体的な詳細を含む調査結果]

**[ソース 2] より:**
- [具体的な詳細を含む調査結果]

### 背景情報と微妙な違い
[注釈、エッジケース、または重要な追加情報]

### ソース
1. [ソース名/リンク] — [それが寄与した内容]
2. [ソース名/リンク] — [それが寄与した内容]
3. [ソース名/リンク] — [それが寄与した内容]

### ギャップと不明な点
- [確認できなかった内容]
- [主題の専門家に検証してもらう必要があるかもしれない内容]

### 推奨される次のステップ
- [答えが顧客に伝える必要がある場合のアクション]
- [さらなるリサーチが必要な場合のアクション]
- [検証が必要な場合に相談する人]

4. ソースが不十分な場合の対応

接続されたソースから結果が得られない場合:

• トピックに関する Web リサーチを実施
• ユーザーに内部情報を求めます:
  • 「接続されたソースでこれが見つかりませんでした。内部ドキュメントまたはナレッジベース記事がありますか?」
  • 「チームがこのトピックについて以前議論しましたか? 確認すべきチャットチャンネルはありますか?」
  • 「答えを知っている主題の専門家はいますか?」
• 制限事項について透明性を保ちます:
  • 「この回答は Web リサーチのみに基づいています — 顧客と共有する前に内部ドキュメントに対して検証してください。」
  • 「可能性のある回答は見つかりましたが、信頼できる内部ソースから確認できませんでした。」

5. 顧客向けの考慮事項

リサーチが顧客の質問に答えるためのものの場合:

• 製品ロードマップ、価格設定、法律、またはセキュリティトピックが関わる場合は、レビューが必要になる可能性があることをフラグします
• 答えが以前に伝えられた内容と異なる場合はメモを取ります
• 顧客向けの回答に適切な注釈を提案します
• 顧客向けの回答をドラフト作成することを申し出ます: 「これらの調査結果に基づいて顧客への回答をドラフトしましょうか?」

6. ナレッジキャプチャ

リサーチが完了した後、ナレッジを保存することを提案します:

• 「これらの調査結果をナレッジベースに保存して将来の参考にしておきましょうか?」
• 「このリサーチに基づいて FAQ エントリを作成しましょうか?」
• 「これはドキュメント化する価値があるかもしれません — 手順書エントリをドラフト作成しましょうか?」

これにより、組織的な知識を構築し、チーム全体の重複リサーチの労力を削減できます。

---

ソース優先順位と信頼度

ソース階層別の信頼度

階層	ソースタイプ	信頼度	メモ
1	公式内部ドキュメント、KB、ポリシー	高	明らかに古くない限り信頼 — 日付を確認
2	CRM、サポートチケット、ミーティングノート	中～高	主観的または不完全な場合がある
3	チャット、メール、カレンダーノート	中	非公式で、文脈を外れている、または推測的な場合がある
4	Web、フォーラム、サードパーティドキュメント	低～中	特定の状況を反映しないかもしれない
5	推論、類推、ベストプラクティス	低	推論として明確にフラグ、事実ではない

信頼度レベル

常に信頼度を割り当てて伝えます:

高信頼度:

• 公式ドキュメントまたは信頼できるソースで確認された回答
• 複数のソースが同じ回答を裏付けている
• 情報は現在のもの (合理的な期間内に検証済み)
• 「[ソース] に基づいて、これは正確だと確信しています。」

中信頼度:

• 非公式なソース (チャット、メール) で見つかった回答だが、公式ドキュメントにはない
• 裏付けのない単一のソース
• 情報は若干古い可能性があるが、おそらくまだ有効
• 「[ソース] に基づいて、これが当てはまるようですが、[チーム/人] に確認することをお勧めします。」

低信頼度:

• 関連情報から推論された回答
• ソースが古いまたは信頼できない可能性がある
• ソース間で矛盾する情報が見つかった
• 「決定的な回答が見つかりませんでした。[背景] に基づいて、私の最良の評価は [回答] ですが、これは顧客と共有する前に検証すべきです。」

判断不可:

• どのソースにも関連情報が見つからない
• 質問がソースで利用できない専門知識が必要
• 「この件について情報が見つかりませんでした。[提案する専門家/チーム] に連絡することをお勧めします。」

矛盾への対応

ソースが一致しない場合:

1. 矛盾を明示的に注記
2. どのソースがより信頼できるか、またはより最新かを特定
3. 両方の視点を文脈付きで提示
4. 矛盾を解決する方法を推奨
5. 顧客に伝える場合: 解決されるまで最も慎重な/注意深い回答を使用

エスカレーション vs. 直接回答のタイミング

直接回答する場合:

• 公式ドキュメントが質問に明確に対処している
• 複数の信頼できるソースが回答を裏付けている
• 質問が事実的で機微でない
• 回答にコミットメント、タイムライン、または価格設定が関与していない
• 確認された精度で以前に同様の質問に回答した経験がある

エスカレーションまたは検証する場合:

• 回答が製品ロードマップのコミットメントまたはタイムラインに関わる
• 価格設定、法的条件、または契約固有の質問
• セキュリティ、コンプライアンス、またはデータ処理の質問
• 回答が前例を設定したり、期待を生じさせたりする可能性がある
• ソースで矛盾する情報が見つかった
• 質問が特定の顧客のカスタム構成に関わる
• 回答に自分が持っていない専門知識が必要
• 顧客が危険にさらされており、誤った回答が状況を悪化させる可能性がある

エスカレーション経路:

1. 主題の専門家: 技術的またはドメイン固有の質問用
2. 製品チーム: ロードマップ、機能、または機能性の質問用
3. 法務/コンプライアンス: 条件、プライバシー、セキュリティ、または規制上の質問用
4. 請求/財務: 価格設定、請求書、または支払い関連の質問用
5. エンジニアリング: カスタム構成、バグ、または技術的な根本原因用
6. 経営陣: 戦略的決定、例外、または高リスクの状況用

チームナレッジベース用のリサーチドキュメント化

リサーチを完了した後、将来の使用のためにナレッジをキャプチャします。

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

• 質問が以前出たことがある、または今後出る可能性がある
• リサーチに相当な労力がかかった
• 回答が複数のソースを統合する必要があった
• 回答が一般的な誤解を訂正する
• 回答に誤りやすい微妙な違いが含まれる

ドキュメント形式:

## [質問/トピック]

**最終確認:** [日付]
**信頼度:** [レベル]

### 回答
[明確で直接的な回答]

### 詳細
[裏付けとなる詳細、背景情報、微妙な違い]

### ソース
[この情報の出所]

### 関連する質問
[これが答えるのを助けるかもしれない他の質問]

### レビューノート
[いつ再検証するか、この回答を変える可能性のあるもの]

ナレッジベースの保守:

• すべてのエントリに日付を付ける
• 特定の製品バージョンまたは機能を参照するエントリをフラグ
• エントリを四半期ごとにレビューして更新
• 関連性がなくなったエントリをアーカイブ
• 検索可能性のためにエントリにタグを付ける (トピック、製品領域、顧客セグメント別)