/customer-research
如果您看到不熟悉的占位符或需要检查已连接的工具,请参阅 CONNECTORS.md。
对客户问题、产品主题或与账户相关的询问进行多来源研究。综合所有可用来源的发现,并附有清晰的来源归属和置信度评分。
用法
/customer-research <问题或主题>
工作流
1. 解析研究请求
确定需要哪种类型的研究:
- 客户问题:客户提出的需要答案的问题(例如,"我们的产品是否支持通过
Okta 进行 SSO?")
- 问题调查:已报告问题的背景信息(例如,"这个 bug
以前被报告过吗?已知的变通方案是什么?")
- 账户背景:特定客户的历史记录(例如,"我们上次告诉
Acme Corp 关于这件事是什么?")
- 主题研究:与支持工作相关的一般主题(例如,"webhook
重试逻辑的最佳实践")
在搜索之前,明确您实际想要查找什么:
- 这是一个有确定答案的事实性问题吗?
- 这是一个需要多角度思考的背景性问题吗?
- 这是一个范围仍在定义中的探索性问题吗?
- 答案的受众是谁(内部团队、客户、管理层)?
2. 搜索可用来源
系统地搜索下面的来源层级,并根据实际连接情况做调整。不要止步于第一个结果——在多个来源之间交叉验证。
第一层——官方内部来源(最高置信度):
- ~~knowledge
base(如已连接):产品文档、操作手册、常见问题解答、政策文件
- ~~cloud storage:内部文档、规格说明、指南、以往的研究
- 产品路线图(对内):功能时间线、优先级
第二层——组织上下文:
- ~~CRM 笔记:账户笔记、活动历史、之前的答案、机会详情
- ~~support
platform(如已连接):之前的解决方案、已知问题、变通方案
- 会议记录:之前的讨论、决策、承诺
第三层——团队沟通:
- ~~chat:在相关频道中搜索该主题;检查团队成员是否讨论过或回答过这个问题
- ~~email:搜索该主题的历史通信
- 日历笔记:会议议程和会后笔记
第四层——外部来源:
- 网络搜索:官方文档、博客文章、社区论坛
- 公开知识库、帮助中心、发布说明
- 第三方文档:集成合作伙伴、互补工具
第五层——推断或类比(当直接来源无法提供答案时使用):
- 类似情况:类似问题以前是如何处理的
- 类比客户:对类似账户有效的方法
- 一般最佳实践:行业标准和规范
3. 综合发现
将结果整理成结构化的研究简报:
## 研究:[问题/主题]
### 答案
[对问题的清晰、直接回答——开门见山]
**置信度:** [高 / 中 / 低]
[解释置信度水平的原因]
### 关键发现
**来自 [来源 1]:**
- [带有具体细节的发现]
- [带有具体细节的发现]
**来自 [来源 2]:**
- [带有具体细节的发现]
### 背景与细微差别
[任何需要注意的警告、边界情况或其他上下文]
### 来源
1. [来源名称/链接]——[它提供了什么]
2. [来源名称/链接]——[它提供了什么]
3. [来源名称/链接]——[它提供了什么]
### 差距与未知
- [无法确认的内容]
- [可能需要主题专家验证的内容]
### 建议的后续步骤
- [如果需要将答案告知客户,采取的行动]
- [如果需要进一步研究,采取的行动]
- [如果需要验证,咨询谁]
4. 处理来源不足的情况
如果已连接来源没有结果:
- 对该主题进行网络研究
- 询问用户获取内部上下文:
- "我无法在已连接来源中找到相关信息。您有关于此问题的内部文档或知识库文章吗?"
- "您的团队以前讨论过这个主题吗?有没有我应该查看的 ~~chat
频道?"
- "有没有了解答案的主题专家?"
- 对局限性保持透明:
- "此答案仅基于网络研究——在分享给客户之前,请对照您的内部文档进行核实。"
- "我找到了一个可能的答案,但无法从权威的内部来源确认。"
5. 面向客户的注意事项
如果研究是为了回答客户问题:
- 标注答案是否涉及产品路线图、定价、法律或安全主题,这些可能需要审核
- 注意答案是否与之前传达的内容不一致
- 为面向客户的回复建议适当的免责声明
- 主动提出起草客户回复:"想要我根据这些发现起草给客户的回复吗?"
6. 知识沉淀
研究完成后,建议沉淀知识:
- "我应该把这些发现保存到您的知识库以备将来参考吗?"
- "想要我根据这项研究创建一个常见问题解答条目吗?"
- "这或许值得记录——我应该起草一个操作手册条目吗?"
这有助于建立组织知识,减少整个团队的重复研究工作量。
来源优先级与置信度
按来源层级的置信度
| 层级 |
来源类型 |
置信度 |
说明 |
| 1 |
官方内部文档、知识库、政策 |
高 |
可信,除非明显过时——请检查日期 |
| 2 |
CRM、支持工单、会议记录 |
中高 |
可能主观或不完整 |
| 3 |
聊天、邮件、日历笔记 |
中 |
非正式,可能缺乏上下文或属推测性 |
| 4 |
网络、论坛、第三方文档 |
低中 |
可能不反映您的具体情况 |
| 5 |
推断、类比、最佳实践 |
低 |
明确标注为推断,而非事实 |
置信度水平
始终赋予并传达置信度水平:
高置信度:
- 答案已由官方文档或权威来源确认
- 多个来源证实了相同的答案
- 信息是最新的(在合理时间范围内已验证)
- "基于 [来源],我有信心这是准确的。"
中置信度:
- 答案来自非正式来源(聊天、邮件)但非官方文档
- 单一来源,无佐证
- 信息可能稍有过时,但很可能仍然有效
- "基于 [来源],这似乎是事实,但我建议与 [团队/人员] 确认。"
低置信度:
- 答案是从相关信息推断得出的
- 来源已过时或可能不可靠
- 各来源间发现矛盾信息
- "我未能找到确定的答案。基于 [背景],我的最佳评估是
[答案],但在分享给客户之前应当核实。"
无法确定:
- 在任何来源中均未找到相关信息
- 问题需要来源中未提供的专业知识
- "我找不到关于此问题的信息。我建议联系 [建议的专家/团队]
以获取确定的答案。"
处理矛盾信息
当来源之间存在分歧时:
- 明确标注矛盾之处
- 确定哪个来源更权威或更新
- 呈现双方观点并附上背景信息
- 建议如何解决差异
- 如果涉及客户:使用最保守/谨慎的答案,直到问题解决
何时升级 vs. 直接回答
直接回答的情况:
- 官方文档清楚地解答了问题
- 多个可靠来源佐证了答案
- 问题属于事实性且不敏感
- 答案不涉及承诺、时间线或定价
- 您之前回答过类似问题且确认准确
需要升级或核实的情况:
- 答案涉及产品路线图承诺或时间线
- 定价、法律条款或合同相关问题
- 安全、合规或数据处理问题
- 答案可能开创先例或制造期望
- 您在来源中发现了矛盾信息
- 问题涉及特定客户的自定义配置
- 答案需要您不具备的专业知识
- 客户有风险,错误的答案可能使情况恶化
升级路径:
- 主题专家:针对技术或领域特定问题
- 产品团队:针对路线图、功能或能力问题
- 法律/合规:针对条款、隐私、安全或监管问题
- 财务/计费:针对定价、发票或支付相关问题
- 工程:针对自定义配置、错误或技术根本原因
- 管理层:针对战略决策、例外情况或高风险情境
团队知识库的研究文档化
完成研究后,沉淀知识以备将来使用。
何时记录:
- 问题以前出现过或很可能再次出现
- 研究花费了大量精力来整理
- 答案需要综合多个来源
- 答案纠正了一个常见误解
- 答案涉及容易出错的细微差别
记录格式:
## [问题/主题]
**最后验证时间:** [日期]
**置信度:** [级别]
### 答案
[清晰、直接的答案]
### 详情
[支持的细节、背景和细微差别]
### 来源
[这些信息的来源]
### 相关问题
[此答案可能有助于回答的其他问题]
### 审核说明
[何时重新验证、什么可能改变这个答案]
知识库维护:
- 为所有条目标注日期戳
- 标记引用特定产品版本或功能的条目
- 每季度审查和更新条目
- 归档不再相关的条目
- 为条目添加标签以便搜索(按主题、产品领域、客户群体)