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