报告还没拿到，交付时间已经快到了。页面一直转圈，客服只回了一句“请耐心等待”。
如果身在这样的场景里，着急的未必只是系统坏了。更让人难受的是，自己不知道还要等多久，也不知道此时换一种办法，会不会让事情更乱。
所以，故障发生以后，沟通本身就是服务的一部分。技术人员在后台忙着排查，不能替代客户对眼前工作的安排。
Atlassian 的事故沟通指南强调，初次通知要说明已经知道的影响，并交代下次更新。这是一种很朴素的确定感：问题没有被忽略，接下来还会有消息。资料：Atlassian
假设一个 AI 文件生成工具漏掉了部分结果。比较有用的通知，可以说清哪些批次可能受影响、现在是否还适合重复提交、已有文件能不能继续使用。根因没查清，就只能说正在核对。用“数据绝对没问题”安慰人，万一判断错了，客户可能继续把错误带进工作。
这里还有两个不同的“恢复”。
一个是系统又能生成文件了；另一个是之前受影响的客户，终于拿到了完整结果。前者完成后，后者未必自动发生。有的任务需要补跑，有的文件要重新核对，有的费用需要按约定处理。网页上的绿色状态，不能替客户补齐遗漏。
补救也不必总是一张优惠券。客户因为故障多花了半天整理资料，真正有用的帮助，可能是把缺失部分补全，并明确标出哪里还要复核。让他再消费一次才能得到补偿，未必符合他的需要。
真诚当然重要，但它不等于一口气许下更大的保证。“以后绝不再发生”很响亮，却可能无法兑现。具体说清这次为何漏掉结果、已经加了什么检查，比笼统承诺更容易判断。
我不赞成把“危机一定能转化成信任”当作公式。有人经历一次严重故障，就决定离开，这完全可以理解。道歉和补救的意义，是把该承担的工作做完，给客户足够事实，而不是要求对方原谅。
服务恢复到什么程度，最终要回到那份没交出去的报告上。客户还有没有东西可用，能不能继续自己的工作，比道歉信写得多动人更实在。