错误的处理方式比错误本身更影响信任
别名: 错误处理 · 处理重于错误 · how the miss is handled
概念解释
两个日历产品都发错过一场会。一个把错误吞掉，事后才在角落写「已更新」；一个立刻标明发错了、给撤回、说清会发给了谁。同样的错，后者往往还能留在工作流里，前者被卸掉。错误怎么被处理，比错误本身更左右信任会不会断（error handling over the error）。
处理是关系里的第二件事。第一件事已经发生；第二件事决定这是一次事故还是一次背叛。
机制
人评价的不只是结果，还有对方在结果之后像不像还站在同一边。隐瞒、淡化、把错推给用户，被读成故意；承认、标明范围、给出补救，被读成仍可合作。信任崩塌常常在第二步才落地——不是因为会发错了（谁都会），而是因为发错之后系统表现得好像没事。
处理还改写归因。承认「是我们发错了」把事件留在能力问题；「请检查你的输入」把事件变成对用户的指责。能力问题可以慢慢修；指责会把关系从工具变成对手。所以同等严重的错，处理可以把崩塌打开或合上。这里说的是主导因素在处理，不是「处理能部分抵消一次失败的伤害」那种加减法。
怎么研究
同一错误，随机分配处理脚本：隐瞒 / 淡化 / 承认并给撤回 / 承认但不给补救。看随后的卸载、投诉、是否继续把高后果任务交出去。自变量：处理类型、补救是否真正可执行、是否把错归于用户。因变量：崩塌与否（撤离）、对「还会不会再隐瞒」的判断。
补救必须真能执行。口头承认配上点不了的撤回按钮，测到的是又一次处理失败。
边界
错的后果若已经不可逆且无法补救（医疗剂量已经打下去），处理仍然影响事后关系，但不能把后果本身抹掉；不要承诺处理能赎回已发生的伤害。处理极其漂亮，也不能把「严重错误可以一次抽空信任」取消——它改变的是断不断，不是严重性定律。用户若从未发现错误，处理无从发生；被第三方先发现，处理的窗口已经变窄。
怎么落地
- 高后果错误一旦确认，先标明发生了什么、影响了谁，再给此时还能做的补救。不要先解释模型原理。
- 禁止默认把错误写成用户不会用。归因要有证据；没有证据就归系统。
- 补救控件必须当场能用：撤回、通知被误发的人、导出记录给用户去善后。
- 验证：用同一错误做两种处理的演练，问「你还会把自动发送打开吗」。若隐瞒组与承认组的答案差一截，产品现在的默认文案属于哪一组，比错误率本身更决定下一次崩不崩。