编辑导读：用户在使用产品的过程中，少不了会出现操作错误的情况，这时容错机制的重要性就显现出来了。本文从四个方面围绕容错机制进行分析，希望对你有帮助。

子曰：知错能改，善莫大焉。

产品经理说：且慢！容我想想……

可能很多时候，我们在设计产品时，主要精力投在主流程上，想如何完成闭环，如何节省步骤，提高用户体验，对于异常情况，就是给出友好的提示和引导。

但产品上线后，我们会发现客户老是因为自己点错的问题找我们，让我们改数据库。我们当然是理直气壮地拒绝了，但仔细想想，是不是我们的容错机制做得不够好。

说说我碰到的三个出错场景吧。

一、我真的知错了

例1：脉脉错过了好友

其实关于容错我之前没有好好想过，但有个同事对这块很重视，我当时还觉得他小题大做，直到我亲身经历了，那次感受特别深。

偶尔会打开脉脉，就会看到人脉，像下图有待处理请求，直接点击√或者×就可以，当时我拿左手在操作，想点√，结果手指不够长，在移动过程中碰到了×，这条就直接消失了，我就想找回来点√，我以为会有一个列表像微信好友一样，至少历史请求都在，但是当我点开列表时，发现也只有待处理的，没有历史记录。

我当时还发了一条状态说为什么点错了不让我改，客服说现在功能是没有，后面有考虑做。但很久过去了，这个功能还是没有。

或许产品经理认为，反正那么多人加你，大部分还不认识，点错了少加几个有什么关系呢。但我就是执着地想加上呢？

例2：入库单删不掉

在做医疗SaaS时，这个问题真的是隔三差五就有客户提。我们当时的设计是，入库完成后有审核，审核通过入库了就不让改了，如果有错，可以把这笔单子出了，再重新录。

按理说多了审核环节就能避免80%的出错率了，2个人都没看出来？但事实就是，很多人自录自审，然后还点错了，又不想再出后入，因为这样药品流水就会多2条没必要的记录，卫生局会来查，怕说不清。

现在在做wms，去仓库调查时，这个问题也被提出了。这里的入库单都不能仓管手动增，是由采购系统推送过来的，采购员录错了，推送了错误的几百条数据过来。后来发现了，又重新建了个采购单，再推送过来，但之前的单子没有调回，就一直挂在待出库这边，仓管员看了特别难受，想删又删不掉。

例3：昨天的病历改不了

病历规范里面其实是有这样的要求，门诊病历当天归档后就不能修改了，关于出事后篡改病历逃避责任这类的新闻想必大家都有听闻过。

我们当时就按这个标准来的，门诊病历过今天24时就不让改了，体检的可以，因为体检报告一般都要好几天才能写完。

但客户就是还经常要改，有时候是因为同名患者写错了，有时候是因为太忙了，才想起昨天有几份病历没来得及写完。

只要是人就会出错，小学时铅笔写错了字可以拿橡皮擦，高中时中性笔写错了还能用胶带粘掉，为什么电子化的系统反倒改个东西那么难呢？

二、为什么不让改

产品经理绝对是背锅侠，我们也想让客户随便改，但我们不得不全局地考虑系统啊，改了会不会出更大的问题？

数据对不上怎么办？

就像案例2中的入库单，如果采购系统查到有这条入库任务，但是在WMS里面被删掉了，客户会不会觉得是因为系统有bug，数据没有推送过来呢？

还遇到过一个比较大的问题，医生开完处方后药房也发药了，但是患者说不想要了，就把药退了，医生想把处方单里把这个药删掉，很合理。但是删掉后我药品的发药和退药记录要不要保留呢？保留的话后面查时发药依据在哪？

万一删错了怎么办？

用户可以因为手滑，点错了想删除，那如果又手滑，点错了删除，把有用的数据删除了怎么办呢？我们还要给他提供一个像照片一样的垃圾箱，或者word的回到历史版本吗？

肯定不可能啊！虽说删除都有二次确认，其实三次、四次都没用，有的人就是闭着眼睛在点，错了就问能不能复原。

好像关于出错我们是没法去避免的，但也不能不去处理，我总结了下7种常用的容错机制，可以在不同的时候用上，希望可以少背点锅吧。

三、容错可以这样做

1. 直接修改

对于列表页，我们最常见的按钮就是新增、查看、编辑、删除。这里的修改不止是随着时间场景的推移，事务发生变化，比如提成规则发生了变化，需要及时修改。还包括简单的就是因为输错了，想改，比如员工的姓名。

如果说修改的字段没有和业务流程挂钩，也没有被其他功能引用，那么事情就很简单了，随便改。但B端产品中，字段往往没那么单纯，大部分字段都是有深意的，特别是一些基础数据，那可以试试下面的办法。

2. 只可停用，不可删除

员工信息是系统中很基础的数据，很多地方都有用到，特别是统计报表中。

比如医务统计中会按医生统计看诊量，门诊金额，处方金额等，如果把医生删除了，有可能统计的数据就不对了，医务统计处的总金额就比收费统计那边的金额少了。

这时候可以让员工只能停用，不能删除。但这会引发另一个问题，员工太多了，看着碍眼，那可以在进入页面时用状态过滤下，当然还有强迫症的客户就是想删。

很多时候就算能删，我们也为了保险起见，让开发只做逻辑删除，不做物理删除，但只能针对重要数据，所有的都做逻辑删除对数据库的压力也是很大的。

3. 调错与红冲

调错与红冲这个概念在会计里面是用的最成熟的，记账凭证会计科目错误时，用红字填写一张与原始凭证完全相同的记账凭证，以示注销原记账凭证，然后用蓝字填写一张正确的记账凭证，并据以记账。

我们在WMS里面也经常会听到这些名词：红领料，红验收，就是说领料有问题，退回仓库；采购来的货有问题，退回供应商。

同样系统中有过的痕迹不能直接删、改，涉及流程有关的，可以用调错和红冲，把下游环节的流程给撤回来。

遇到财务系统中结转时也是如此，如果发现结转的账有错误，可以反结转，把账调回，修正后再重新结转。

4. 限时修改

这个用的最好的是微信了，我们都发生过这样的情况，一不小心把一条八卦或吐槽发给了领导或者客户群。微信可以让我们在短时内撤回消息，如果能不显示“xx撤回了一条消息”会更好，毕竟还有99%的人好奇撤回的是啥。

案例3中病历的情况就可以这样处理，限时还是必须的，但可以不一刀切，可以给医生缓一缓的时间，比如24小时，72小时内可修改，毕竟过了72小时，大部分人想不起之前的事了吧。

5. 加强审核

案例2中入库和出库，我们都有增加审核环节，对于管理严格的诊所来说，还是有会有效果的。但审核最好还是能搭配调错与红冲一起，这样容错率能更高一点。

另一种常见的场景就是我们的OA，我们在批假时，如果小于1天，上级领导批就可以了，2-5天需要总监再审核，5天以上可能又要增加HR，CEO之类的审批了。

当然OA的这么多审批本质不是为了容错，但这个例子能说明审核人越多，流程越长，错误率就越低。有时候我们也可以适当增加些环节。

6. 角色控制

系统角色来看肯定有超级管理员，超管拥有一切的权限，如果一些数据很重要，我们可以把修改和删除的权限只开给他。

除了系统里面的权限控制，还可以有专门的容错平台。我们之前为了方便修改病历，特地做了一个只能客服使用的病历修改小系统。如果客户有问题，客服输入具体的患者名称、时间等后可以改该条数据，不提供模糊搜索，以防恶意操作。

7. 日志留档

最后的最后，也是最重要的，所有的重要修改都要留档，不然有口说不清。

我们就经常碰到客户投诉，说病历没了，客户档案没了，系统有bug。那肯定是不可能的，我们说肯定是你的员工动了。他会说：我把员工都问了一遍了，都说没动。这不废话吗，如果我是员工，我也不想承认。

我们就可以把操作日志甩他们脸上，xx时间xx人改了xx，把xx改成了xx，然后你们自己去处理吧。

四、总结

犯错很容易，容错很难，但不让人家改又不行，做产品经理好难啊。

但有时候我们想想，其实没必要那么执着在系统数据的完整性上，保留好罪证，让他们愿意改就改去吧。如果有个回收站和历史版本最好，这样万一想回来也容易。

所以说了7种容错机制，最顶级的还是回收站和历史版本回退，下面让我们想想，这2个功能该怎么做呢？

#专栏作家#

司马特小队，公众号：司马特小分队，人人都是产品经理专栏作家。8年+互联网资深产品经验，多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验；主要教授产业互联网产品相关的硬核知识点。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议。