这是 Zendesk 事务管理概览的第 4 部分。本指南包含以下部分：
- 第 1 部分：Zendesk 服务问题如何转为服务事务
- 第 2 部分：Zendesk 如何管理服务事务
- 第 3 部分：监测公开 Zendesk 服务事务
- 第 4 部分：解决后事务分析和报告（本文章）
在本文章第 4 部分中，您将了解事务响应团队如何进行回顾，包括根本原因分析和服务事务修复，然后将修复项目分配给负责的工程团队。
通过进行这些活动，Zendesk 客户Support可与受影响的客户共享事务详情和后续步骤。
本文章包含以下组别：
进行服务事务回顾
Zendesk 对所有涉及事务的团队成员进行了回顾性练习，以检查并记录事务的原因、事务对客户的影响，以及为缓解或解决事务所采取的操作。 团队会审阅已识别的根本原因，以及防止事务再次发生的跟进操作。这称为服务事件内部回顾。事务回顾仅公开共享严重性高的事务。
为了确保对所有 Zendesk 团队的透明度和包容性，Zendesk 内部回顾日历可用，以便他们参加内部回顾会议，并获取更多关于服务事务和根本原因的信息。 事务结果将与所有工程团队共享，重大事务结果将在 Zendesk 每周工程会议上突出显示和审查。
服务事务回顾主要执行四项活动：
- 审阅事务文档中的事务详情，使参与者了解事务
- 审阅并验证事务文档中包含的根本原因分析结果
- 识别 Zendesk 工程团队所需的任何修复工作并将其分类，以充分解决导致服务事件的根本原因。所有修复项目都已得到回顾与会者的一致同意
- 将修复工作分配给适当的工程团队，并定义清晰、适当的 SLA。
高严重性事务分析
解决高严重性事务后，事务管理者会安排回顾会议，内容包括：
- 参与事务响应的所有团队成员
- 产品或服务受到事务影响的团队的工程师
-
负责人或对此感兴趣的团队，例如：
- Zendesk 客户支持
- 产品团队
- 负责受影响产品、服务和支持领域的主管
我们将尽力在事务解决后 72 小时内召开事务回顾会议，并理解会议时间将取决于根本原因的复杂程度以及各地区团队成员的空闲状态。
计划事务回顾后，工程负责人记录根本原因分析，并根据以下类别创建事务文档：
- 事务概览
- 客户影响
- 技术描述
- 根本原因和服务信息
- 事务详情和计时
- 修复
事务文档可指导事务回顾，记录已识别的任何修复工作，以完全解决导致事务的根本问题。
对于严重程度为 0-3 的事务，还需进行一个额外的分析阶段，即根本原因分析。此分析使工程团队有机会了解并记录事务，并定义完全解决问题所需的工作。此信息记录在事务文档中。
Zendesk 事务根本原因分析流程
低严重性事务分析
低严重性事务比高严重性事务要经历更精简的根本原因和报告阶段。对于低严重性的事务，虽然未完成正式事务回顾会议（除非产品工程负责人请求），但产品工程负责人会创建事务文档。
识别、分类并共享根本原因，并使用 SLA 将修复项目添加到产品工程团队待办工单中。 与处理高严重性事务一样，Zendesk 致力于通过深入调查低严重性事务来了解和改进我们的工程流程。
由于严重程度为 3 的事务对客户影响较小，因此问题状态和已确定的修复方法将与受影响的客户共享，这些客户可以通过 Zendesk 工单就事务与 Zendesk 客户Support联系。
根据定义，4 级事件不会直接对客户产生影响。事务后分析不会传达给客户，但可使用上述流程和程序在内部识别根本原因并解决修复问题。
分配修正项目
为了确保修复项目完成，产品工程团队会在回顾中审阅已验证的修复项目，并执行以下操作：
-
将修复分类为预防性或一般：
- 预防性项目 是指能够主动防止事务再次发生的项目
- 一般项目 本身不仅具有预防作用，还可以解决事务情况的核心部分
- 排列修复的优先级，以设置响应 SLA。此练习包括以下活动：
- 确定负责处理修复项目的工程团队
- 将修复项目链接到其解决的已识别根本原因
- 将修复项目添加到负责工程团队的待办工单中
- 将修复项目添加到工程SLA报告以跟踪SLA 的实现情况
以下图表可供产品工程团队用来确定何时排列修复的优先级，以及何时计划修复工作。
Zendesk 修复项目优先级SLA
参加回顾会的 Zendesk 客户Support团队创建面向客户的事务描述、根本原因，以及已识别的任何修复方法。这已过帐到 我们帮助中心的服务通知部分。
服务可用性事务示例（续）
以下是针对此事务的事务回顾。
事务发生 4 个工作日后，事务响应团队和工程师齐聚一堂，审阅事务，就根本原因进行协作，并创建或更新修复项目。所有修复项目都已获得与会者的一致同意。
每个涉及事务的人员在事务回顾中都发挥了作用：
会议中审阅和讨论的详情包括：
| 分区图 | 例如 |
| 时间线 |
|
| 根本原因 |
|
| 影响因素 |
|
| 修复 |
|
为了进行全面的分析，以便工程团队采取具体行动，所有团队成员都提供了意见，重新盘点了事务，并制定了修复任务。当事务响应团队解决了所有疑问或问题后，事务回顾即告完成。
在内部回顾会议结束时，有人询问负责面向公众的事件回顾的 Zendesk 客户Support主管是否有任何问题，或是否需要团队提供任何其他信息来创建公开文档。她没有其它问题了，并将以下回顾性信息添加到 我们帮助中心 的 服务通知部分。
服务可用性虚拟机事件的公开回顾信息
此次事件回顾提高了 Zendesk 产品和服务的三个重要成果：
- 已确定此事件的根本原因，所有 Zendesk 产品团队将在未来的开发中予以考虑
- 修复已确定，并已分配给具有 SLA 的工程团队
- 公开回顾由 Zendesk 客户Support发布到帮助中心，并已提交工单的受影响的客户
关闭服务事务
作为最佳实践，Zendesk 会关闭所有与客户已开启的工单，确保事件的所有内容都得到正确记录和沟通。
所有已完成的服务事务都汇总在每周服务事务摘要报告中，该报告在整个 Zendesk 中广泛共享。此报告中包含事务描述、客户影响和重要的修复措施，以及与 Zendesk 执行团队共享的每两周一次的运营审查报告。
当回顾信息发布到帮助中心，且已开启的工单随回顾结果更新后，表示服务事务的分析和报告阶段已完成。Zendesk 客户Support会将这些工单链接到服务事务，并将其标为已关闭。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。