customer-research

/customer-research

如果你看到不熟悉的占位符，或需要确认已连接哪些工具，请参阅 CONNECTORS.md。

针对客户问题、产品话题或账户相关咨询进行多来源研究。综合所有可用来源的发现，并给出清晰的出处标注和置信度评分。

用法

/customer-research <question or topic>

工作流

1. 解析研究请求

确定所需研究的类型：

• 客户问题：客户提出、需要解答的问题（例如："我们的产品是否支持与 Okta 的 SSO？"）
• 问题排查：已报告问题的背景信息（例如："这个 bug 之前有人报告过吗？已知的变通方案是什么？"）
• 账户背景：与特定客户的历史往来（例如："Acme Corp 上次询问此事时，我们是怎么答复的？"）
• 话题研究：与支持工作相关的一般性话题（例如："webhook 重试逻辑的最佳实践"）

在搜索之前，先明确你真正要查找的内容：

• 这是一个有明确答案的事实性问题吗？
• 这是一个需要多角度视角的情境性问题吗？
• 这是一个范围仍需界定的探索性问题吗？
• 答案的受众是谁（内部团队、客户还是管理层）？

2. 搜索可用来源

按下列来源层级系统性地搜索，并根据已连接的工具灵活调整。不要在第一条结果处就停止——要跨来源交叉验证。

第 1 层——官方内部来源（置信度最高）：

• ~~知识库（若已连接）：产品文档、运行手册、常见问题、政策文件
• ~~云存储：内部文档、规格说明、指南、过往研究
• 产品路线图（面向内部）：功能时间表、优先级

第 2 层——组织背景：

• ~~CRM 备注：账户备注、活动记录、以往答复、商机详情
• ~~支持平台（若已连接）：以往的解决方案、已知问题、变通方案
• 会议记录：以往的讨论、决策和承诺

第 3 层——团队沟通：

• ~~聊天：在相关频道中搜索该话题；查看同事是否讨论过或回答过此问题
• ~~邮件：搜索该话题的以往往来邮件
• 日历备注：会议议程和会后记录

第 4 层——外部来源：

• 网络搜索：官方文档、博客文章、社区论坛
• 公开知识库、帮助中心、发布说明
• 第三方文档：集成合作伙伴、互补工具

第 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]

知识库维护：

• 为所有条目标注日期
• 标记引用了特定产品版本或功能的条目
• 每季度审查并更新条目
• 归档不再相关的条目
• 为条目添加标签，便于检索（按主题、产品领域、客户群体）