AI客服软件：让回答保持最新

你的配送政策发生了变化。网站现在会给出正确答案，但旧的常见问题条目和上个月的支持回复仍在描述之前的流程。在让 AI 客户服务软件回答下一个问题之前，你需要知道哪些来源已经变更，以及哪些答案仍需审核。

本指南介绍上线后的知识维护：如何处理政策变更、协调相互冲突的答案，并为团队提供明确的发布决策。这是一份运营检查清单，而不是产品对比。如果你仍在选择软件，请先阅读实用评估指南。

从变更记录开始，而不是从重写答案开始

当政策负责人宣布变更时，应先记录变更内容，再编辑支持内容。如果没有人确认新政策何时生效，一份措辞精美的答案也还没准备好向客户发布。将这份记录保存在现有的共享文档或任务跟踪工具中即可；不需要引入新工具。

记录政策负责人、生效日期、受影响的客户或产品、之前的规则以及替代规则。补充所有例外情况，以及能够解决这些例外问题的人员。将记录链接到权威政策文档，以便审核人员核查决策，而不是依赖转发的消息。

例如，假设你的企业将基于电子邮件的退货申请改为退货表单。明确待处理的申请是否仍通过电子邮件处理，以及该表单是否适用于所有产品。这些只是用于说明的问题，并非 Deskhero 的政策。如果缺少这些细节，两种不同的回复可能听起来都合理，却会把同一位客户引导到不同的地方。

跨来源追踪发生变化的答案

搜索旧措辞、旧目的地以及常见的改写说法。不要只查看宣布变更的页面。客户可能会询问如何开始退货、应将退货申请发送到哪里，或者之前提交的申请是否仍然有效。将这些问题视为一次知识更新，只是拥有多个入口。

建立一份简短的来源清单。针对每个项目，记录其位置、目标受众、负责人和所需操作。实用的操作包括更新说明、删除重复内容、标记历史参考，或请政策负责人解决冲突。

• 公开常见问题答案：检查主要答案，以及提到同一流程的相关问题。
• 内部知识：除了标准回复，还要更新有关例外情况和升级处理的说明。
• 网站页面：检查帮助内容以及其他重复旧说明的页面。
• 回复模板：替换团队可能仍会手动发送的已保存措辞。
• 历史对话：如果旧示例会影响新草稿，请找出需要额外仔细审查的示例。

不要为了让历史客户对话看起来像当前内容而重写它们。保留事情实际发生过的记录。相反，应清楚记录当前规则，并让审核人员留意新回复中的过时说明。在 Deskhero 中，拒绝或移除公开常见问题答案会使其不再用于自动回复，但之前的工单仍会影响回复草稿，因此审核人员应留意草稿中的过时措辞。

区分公开答案和内部处理说明

围绕客户可以采取的行动来撰写面向客户的答案。将仅供员工查看的例外情况、审批步骤和调查记录放在内部说明中。不要因为一段内部对话包含有用答案，就把整段对话变成公开常见问题。

这一点在 Deskhero 中很重要，因为可用于审核草稿的知识不同于用于自动回复的知识。Deskhero 的回复草稿会参考工作区知识，包括常见问题内容、内部知识、抓取的网站页面以及之前的工单。用户会审核并发送这些草稿。其聊天机器人和选择启用的电子邮件自动回复仅依据已批准的公开常见问题进行回答，并且你可以在批准 100 个常见问题答案后开启它们。超出这些知识范围的问题会转交给人工。

利用这一差异来确定审核范围：检查广泛的知识来源，以确保草稿质量；检查已批准的公开答案，以确保面向客户的自动化效果。如果你需要将维护流程映射到产品上，Deskhero 客户服务 AI 软件概览会说明这些工作流程如何协同运作。

重写答案，但不要隐藏例外情况

对于每一条受影响的常见问题，起草一份完整的替代内容，而不是在相互矛盾的文字下方添加更正。先说明当前流程。然后解释该流程何时适用、客户接下来应该做什么，以及何时需要人工协助。

在退货表单这一示例中，答案应说明新申请从哪里开始，以及已经在处理中的申请将如何处理。如果政策负责人还没有决定待处理申请的处理方式，不要让撰写人员自行编造过渡规则。在作出决定之前，这部分应由人工处理。

请一名没有撰写该修订内容的审核人员将其与变更记录进行比较。让他们检查目的地、资格条件、生效日期、例外情况和下一步操作。只关注语气无法发现缺失的条件。

发布前检查一小组问题

在变更记录旁边保存一组可重复使用的问题。针对这次更新，在审核任何生成的回复之前，先写下每个问题的预期答案或预期转交方式。这样，你就有了比“措辞看起来不错吗”更可靠的判断依据。

• 直接问题：客户如何使用新的流程？
• 过时问题：当有人点名询问旧流程时，会发生什么？
• 过渡问题：已经提交申请的人应该做什么？
• 缺少细节的问题：当资格条件不明确时，应该如何处理？
• 例外问题：哪种情况需要人工决策？
• 无关问题：变更范围之外的答案是否仍能按预期发挥作用？

使用测试环境或其他受支持的审核方式，不要将实验性答案发送给客户。检查你实际使用的每一条答案路径。一个正确的、经过审核的草稿，并不能证明单独的自动回复路径使用了相同的来源。

记录问题、预期结果、观察到的答案（如已知）来源问题以及审核人员的决定。如果答案仍包含旧说明，请重新打开来源清单。如果底层规则仍然含糊不清，应将其退回政策负责人，而不是试图通过反复修改措辞来弥补这种含糊。

明确作出发布决策

在发布修订后的内容之前，要求一名指定的审核人员确认政策已经确定、所有受影响的来源都已检查，并且问题集能够产生可接受的结果。使用软件实际支持的控制措施，让未解决的主题继续接受人工审核。在 Deskhero 中，自动回复按群组开启，聊天机器人则按组件开启，因此暂缓某个主题最简单的方法，就是在相关决策作出之前不批准其常见问题答案。

记录更新获批的时间，以及已检查的答案路径。不要以为发布某个来源就能证明每条答案路径都已经采用了该来源。变更后检查实际表现；如果旧内容仍然出现，请查阅该工具记录的更新流程。

向用户提供一份简短的运营说明：发生了什么变化、应停止使用哪些措辞、哪些例外情况仍未解决，以及这些例外情况由谁负责。这份说明应帮助某人回答下一张工单，而不必阅读完整的修订历史。

通过复盘真实对话来完成更新

发布后，抽查一批涉及该变更主题的对话。留意旧的目的地、相互矛盾的资格规则、缺失的下一步操作，以及不得不再次提问的客户。同时纳入看似成功的答案和最终转交人工处理的对话。

按原因跟踪更正。过时的来源需要进行来源维护。不明确的政策需要作出政策决策。正确但容易被客户误解的答案需要更清晰的措辞。将这些类别分开，有助于避免为了修复负责人问题而重写常见问题。

当负责人审核完观察结果并分配好所有剩余工作后，关闭变更记录。保留这组问题，供下一次修订使用。目标是形成可重复的维护习惯：一名负责到底的负责人、一项可追溯的政策决策、一致的来源材料，以及一条经过检查的路径，从客户的问题一直通向当前答案。