平台判赔那个月，真正能动的只有十天

一个链接被判赔的那个月，我把二十六天拆成两段来看：一段是十天，那段里有活可干；另一段是十五天，那段里我们做不了任何事。整件事的难受不在赔了多少钱，在于我们没有办法决定这一个月什么时候结束。

通知下来那天晚上做的三件事

通知是在一个周五的晚上收到的，判定结果下来之前有两周的通知期，所以我们看到的时候已经是既成事实。

那天晚上我做的第一件事是拉群，第二件事是让人去后台把相关的所有数据冻结，第三件事是指定一个人只做一件事——把这四周内所有关于这条链接的工单导出来，一份不改。

这三件事做完是十一点半。做错的地方是我们同时还在讨论要不要先发一批货出去止损，那批货第二天早上发出去了，后来的结果证明发对了。

冻结数据看起来多余，订单数据一般不会丢。但工单是会变的——客服后来会补回复、删记录、合并重复工单。一旦被改动，举证材料和当时的现场就对不上。

那个晚上还有一件我做对的事：让财务先问清判赔金额上限。内部赔付单笔超过某个额度要老板签字，这条当时没人提，等到要签字已经过去八天了。

举证那十天，拿的是六样东西

举证是有明确清单的。工单记录、物流签收、批次出库时间、产品检测报告、同期页面的截图、买家的每一次沟通原文。这六样凑齐，材料就是完整的。

十天举证，十五天等待，两段时间的性质完全不同

六样里最花时间的是页面截图。平台只给了两周通知期，我们如果按常规做法去找当时的页面，那就找不到——页面早就改过。是我们提前有归档，才把这部分补回来。这条后来写进了内部流程第一条：可能进争议的页面，上线当天拍存档。

那十五天里什么都做不了

提交后那十五天我们试过几次动作，都没用。催、加材料、换人联系，得到的回复都一样。这十五天里唯一做的事是每天早上看一次后台。

这十五天把原来那套流程的一个洞暴露出来了：我们习惯把注意力放在自己能做的部分，对不能做的部分没有记账。团队里每个人的感受是「我们已经很努力了」，从外部看这半个月就是空白。

等待也要有台账

从那之后每一次提交之后，我们记三样：提交日、承诺回复窗口、实际回复日。这三个数凑在一起，半年之后能算出一个内部口径的平均等待天数。

这个数后来帮上了忙。第二年同时提了三个类似案子，判断依据就是这个平均等待天数：在平均等待区间内的那两个一起提，明显超时的走另一条路径。判断不再靠感觉。

台账字段后来是这样定的：提交日、承诺窗口、实际回复日、判定结果、损失金额、结案日。六个字段每次必填。其中承诺窗口这一栏经常填不出来，填不出来本身就是信息，说明那次提交没有明确回执。

我后来加的一个判断

台账攒够半年之后，我们多算了一个数：每类案子的平均举证耗时。这一列让下一次报价的时候能算准。

判赔这类事情，流程长短不由你控制，成本高低很大一部分由你能证明什么决定。这两件事我都花了钱才学会。