一次失败，一次成功

客户本不该成为警报

结账失败有一种格外让人难受的地方。对方已经完成了找到你的产品、理解它的用途、并决定它值得付费的全部过程。然后你却在他们面前放了一堵墙。

这个人完全有理由直接关掉标签页，转身离开。他们并不欠我一份错误报告、一张截图，或者一个为什么我没能做成这笔生意的解释。他们是来买东西的，不是来当质量保证志愿者的。

但他们却花时间提交了反馈。我非常感激，并送了他们五折优惠作为感谢。他们给了我一个机会，去修复一个我本来可能永远不会知道的问题。

这也正是让人不安的部分。我知道那个告诉我的人。但我不知道是否还有其他人遇到了同样的问题，然后一声不响地离开了。除非你真的捕捉到了失败，否则一次失败的结账看起来和一个只是决定不买的人几乎没有区别。

而我的失败并没有被捕捉到。无论我对自己的测试和监控有多少信心，这都相当明确地证明了它们漏掉了一件重要的事。

我需要注意到的那封邮件

我的反馈表单会给我发一封简短的邮件通知，告诉我有反馈需要查看。它只是一小段提示，而不是完整的反馈内容。要知道对方说了什么，我需要注意到那封邮件，然后去查看。

我把它忽略了。但那条通知出现在了我的 Premail 早间简报 里，我立刻看到有一条需要处理的反馈。我去读了它，了解到结账的问题，然后开始动手修复。

这里有一个值得说明的区别：Premail 并没有检测到那个 404。它没有检查我的结账流程，没有诊断错误，也没有以某种方式取代本该发现问题的监控。是客户发现了问题。Premail 做的是把那条通知呈现出来，促使我去阅读他们报告的内容。

这正是我希望简报做到的事情，而它发生在我自己都还在适应使用它们的时候。

使用我刚刚做出来的东西

我几天前才给 Premail 添加了简报功能。我正在训练自己不再默认打开邮件客户端，而是把简报当作需要我关注的事项的摘要。对我来说，这是一次习惯的改变，而不只是一次功能发布。

打开收件箱和弄清楚什么才重要，是两件不同的事。我可以看邮件，却注意不到那条本该改变我下一步行动的特定消息。在这个案例中，一条关于反馈的小通知需要变成一项真正的任务：去读它，然后回应。

早间简报替我建立了这个连接。我看到了一件被自己忽略的事，明白了我需要行动，并立即行动了。它是否有用，几乎没有什么可含糊的。

因为相信一项功能能帮到别人而去构建它，是一回事。让它从你自己的邮件里挖出一件重要的事，并改变你这一上午的走向，是另一回事。我本来更希望有一个不那么难堪的例子，但这个例子相当有说服力。

修复的不只是结账

结账问题现在已经修好了。我也修复了那些未能发现它的告警、基础设施报警和测试。让页面恢复正常是必要的，但如果止步于此，我就还得依赖下一位热心的客户来告诉我什么时候出了问题。

我不打算宣称这样的事再也不会发生。第一次我就已经努力去防止它，它还是发生了。这些改动的目标是防止重演，而且如果真的再次发生，让我在客户不得不报告之前，或者在潜在客户悄悄放弃之前，就察觉到它。

这次的教训绝不是说早间简报可以充当测试和监控的替代品。"等有人抱怨，再把通知总结一下"会是一种糟糕透顶的可靠性策略。我需要修复的，是那些一开始就让问题触达客户的系统。

但我也看到了 Premail 在那些系统失效之后做了一件真正有用的事。它把一条被忽略的消息带到了我面前，而那条消息直接促成了一次修复。

结账故障并不会因为我自己的应用帮我发现了它而变得不那么难堪。两件事同时成立：我让一位客户撞上了坏掉的结账页面，而我刚刚构建的一项功能帮我做出了回应。我感谢这位客户愿意花功夫告诉我，也庆幸我的早间简报确保了我注意到它。