Colay / 指南
将复杂的请求转化为可供团队学习的参考答案
回复经过审核、推理过程清晰可见之后，一个复杂工单可以成为有用的教学案例。Colay 帮助比较可能的回答，找出遗漏的问题。最终交付物应包括客户回复、解释选句理由的注释，以及复用条件。流畅的草稿通过审核才能成为参考答案，而不是靠快捷键或模型投票。
在起草答案之前重构案例
写一份简短案例记录，列出客户目标、已确认症状、已完成检查、先前承诺和剩余不确定性。区分客户报告的情况与团队已核实的事实。如果把这些类别混成一个自信的原因判断，复杂工单往往会更难处理。
使用您有权共享的去识别化版本。包括相关的批准程序和升级规则，而不是完整的私人对话。在 macOS 上，⌘⇧K 默认打开 Colay 的悬浮窗口，并且可以在“设置”中更改。它会调出起草工作区；您仍然提供上下文并查看结果。
虚构的未解决工单以及有用的响应
想象一个虚构的报告服务。一次大导出失败，一次小导出成功，客户已经重复了两次大导出。原因尚未确定。指定的专家已接受该案例，团队已明确承诺在 UTC 时间 16:00 进行更新。这些都是发明的输入，包括时间；它们不是 Colay 的服务承诺。
适当的回复示例是：感谢您确认较小的导出可以正常工作。据我所知，两次重试后，较大的报告仍然被阻止。我们的专家正在调查此案。即使原因尚未确认，我们也会在 UTC 时间 16:00 向您通报我们发现的情况。当我们审核已提供的信息时，您无需重复相同的导出。
| 句子选择 | 原因 | 重复使用的条件 |
|---|---|---|
| 确认较小的导出 | 显示所提供的证据已被阅读 | 该观察结果存在于实际工单中 |
| 说明尚未解决的阻碍 | 避免宣布事件已解决 | 大型导出仍然失败 |
| 承诺更新，而不是修复 | 保留已批准的承诺 | 所有者已实际同意更新时间 |
| 避免再次进行相同的重试 | 尊重检查已完成 | 已批准的调查不需要重新尝试 |
索要对比草稿和带注释的样本
使用Ask separately从选定的可用智能体处获取初步答案。比较他们如何处理不确定性、重复的问题和下一步行动。 Consensus综合可能有助于组织替代方案，但要保留源事实，以便可以逐句检查最终文本。
根据这份已去标识化的客服案例，起草一个待审核的参考答案：[目标、已确认事实、客户报告的情况、已完成检查、先前承诺、未知事项]。已批准流程与升级规则：[来源]。先列出可能改变回复的缺失事实。再给出简洁版和解释较详细版，不要编造原因或解决结果。为每个重要句子说明支持它的案例事实。返回建议的客户回复、内部审核备注，以及其他客服人员可复用的明确条件。内部备注不得进入客户可见正文；标记所有需要负责人确认的承诺。
批准事实和服务行为样本
Zendesk 关于从现有工单创建宏的说明建议调整注释以供重复使用。将这个想法明确地应用到参考答案中：显示哪些细节属于原始案例以及哪些推理可以转移。未解决的案例可以教导有用的临时响应，而无需将其作为已解决的问题呈现。
- 让负责的支持审核员根据案例和政策核实每项事实陈述和承诺。
- 检查答案是否符合客户的实际目标。冗长的技术解释仍然无法说明接下来会发生什么。
- 确认内部假设、个人数据和不受支持的诊断未输入面向客户的文本。
- 将批准的响应与匿名案例、注释、所有者、版本和条件一起存储，以便在现有团队库中重复使用。
教授改编而不是复制完美的段落
要求团队成员将样本调整到附近的案例：专家尚未接受、之前的检查不同或未批准更新时间。他们应该确定哪些句子必须改变。如果不能，参考文献需要更清晰的条件，而不是更优美的散文。
保持示例的状态诚实。这可能是已批准的临时响应，而基础工单仍处于开放状态。当调查改变事实时，更新样本及其注释。可重用的价值在于转移到另一个案例的推理，而不是让每个客户都得到同样自信的答案。
问题及解答
在问题解决之前参考答案是否有用？
是的。它可以展示如何确认证据、传达不确定性并设定批准的下一步。将其标记为临时响应而不是解决方案。
模型意见一致，就代表答案获得批准了吗？
不代表。负责审核的人需要检查实际案例、政策和承诺。比较模型有助于起草和检查文字，但不会授予批准权限。
这与普通的支持宏有何不同？
宏是为重复应用而设计的。带注释的参考示例教导特定响应的推理和限制；单独的审查决定其一部分是否应该成为宏。
来源和方法
- Zendesk: creating macros from existing tickets
有关调整现有工单评论以供重复使用的主要指南。此处带注释的教学示例是原创的，并不暗示 Colay 集成。
将您的下一个问题提交给 Colay
选择一个模型、使用 Auto，或通过 Consensus 汇集多种观点。