服务补救流程图（从恢复服务到重建客户信任）
用于服务恢复后的客户补救：验证稳定性、识别受影响客户、计算SLA额度、按损失制定方案、取得客户验收并把反馈用于预防。
什么是服务补救流程图（从恢复服务到重建客户信任）流程
系统恢复结束了事故响应，却不会自动修复客户关系。客户可能丢失工作、错过截止时间，或花费数小时证明故障，一封通用恢复通知无法弥补这些影响。此图从技术恢复后开始，先验证服务能否承受真实流量，再从证据生成受影响客户清单，评估持续时间和业务损失，并检查合同是否要求自动SLA额度。之后按实际伤害而不是投诉音量选择主动补救，起草事实说明和匹配方案，只有超出权限的方案才进入审批。
流程刻意限定在故障之后。事故管理负责发现、技术指挥和恢复；投诉流程负责仍需正式调查的主张；流失挽留负责客户提出的紧急离开风险。服务补救使用这些流程的输出，但回答服务恢复后还要为客户修复什么。客户收到解释和补救，接受或让未解决案例进入受控修订循环；团队再确认没有承诺或服务缺口遗留。最终，根因和客户反应同时进入预防与支持手册，避免把额度当成纠正措施，或把技术修复当成信任恢复。
本流程图涵盖的内容
本模板包含
- 六个角色泳道贯穿稳定、识别影响、规划补救、修复关系以及验证与学习，并且只在技术恢复后开始
- 用真实流量验证稳定性；服务未通过观察窗口时重新打开事故
- 根据证据识别受影响客户并评估损失，在设计自愿补救前单独判断合同SLA额度
- 按伤害和关系风险选择高接触或标准补救，并为例外方案设置审批边界
- 客户验收、未解决补救的修订循环、逐项核对承诺，并将根因和客户反应反馈给预防工作
何时使用本模板
- 中断或严重服务故障已经恢复，但支持与客户成功团队没有一致方法找出并联系所有受影响客户
- SLA额度发放不一致或只给主动投诉的客户，自愿善意补偿也与合同义务混为一谈
- 团队在监控转绿时关闭事故，但客户承诺、丢失工作或关系损失仍未解决
- 事后复盘改善了基础设施，却没有把客户反应和沟通失败反馈到支持手册
运作方式
定义补救交接
规定事故指挥在恢复时必须提供的证据：观察窗口、受影响组件和客户、起止时间、已知数据损失及技术负责人。不要让客户补救从一句含糊的恢复通知开始。
用证据评估伤害
建立简短等级，覆盖持续时间、丢失工作、被阻断的业务事件、安全或合规影响和战略承诺。使用遥测和工单证据，不按投诉数量排序。
区分合同额度与补救
按协议自动计算SLA额度，再为损失时间、重复故障和关系伤害定义自愿补救、权限上限及审批人。合同要求的额度不是道歉，善意措施也不能替代它。
编写客户沟通
要求如实说明故障、已验证影响、已经改变的事项、补救以及每个负责人和日期。根因调查结束前不要作出虚假承诺，但也不能用技术不确定性掩盖已知影响。
关闭每个未完成承诺
把客户验收和后续承诺与事故行动分开记录。将根因和客户反应反馈到预防工作，只有服务与关系承诺完成或明确分配后才关闭。
常见问题
服务补救流程有哪些步骤？
验证稳定性，不稳定时重开事故，从证据识别受影响客户，评估损失，确定SLA额度，选择高接触或标准补救，必要时指定高级负责人，起草事实说明和方案，审批例外，联系客户，修订未解决方案，核对所有承诺，并在关闭前把根因和客户反应反馈到预防工作。
服务补救与事故管理有何不同？
事故管理负责发现、控制、诊断和恢复服务。服务补救从恢复后开始，处理客户后果，包括受影响证据、SLA额度、沟通、自愿补救、验收和跟进。事故已经解决并不代表客户补救已经完成。
哪些客户应该获得服务补救？
依据证据和书面伤害等级，而不是只看收到的投诉。所有合同规定可获得SLA额度的客户都应按协议收到额度。主动或高接触补救再考虑丢失工作、业务阻断、重复故障、战略承诺和关系风险。
服务补救何时完成？
稳定性已经证明，合同额度和获批补救已经交付，客户已经验收或未解决路径已有明确负责人，并且每项承诺均已完成或排期时才算完成。根因和客户反馈还必须进入预防及支持工作。