Shopee多店铺管理怎么发现问题：异常是被什么暴露出来的

单店靠盯、多店靠什么

单店的盯之所以有效，是因为它利用了一个天然的优势：这条线只在一个人脑子里，而这个人每天都在看同一家店，任何偏移都会被这条线拦下来。这种机制不需要任何设计，它的成本是那个人的注意力，代价是这份注意力一旦被摊薄，机制就开始失效。

多店要接上的第一步，是把这条线的一部分从脑子里搬到可以被检查的形态上。做法不是把标准提高，恰恰相反，是把线放低一点，只留那些偏了就一定不对劲的。这类线画起来不难，比如某个动作该发生却没有发生、某个数字从有到无，它们不依赖经验判断，看一眼就能确定。

第二步是给这些线找通道。通道的意思是这件事不靠我想起来去看，而是它自己会到我眼前。通道可以是某个位置每天要过一遍的东西、可以是某个人在做日常动作时顺手会看到的地方。判断一个通道成不成立，看的是它有没有依赖性：需要谁特别记得去看的，都不算通道。

还有一处是判断外部环境的通道，它跟店里的动作不在一处。某个品类的价格带最近整体动了、某个词的热度在退，这些事在店内的数据上只会表现为一些说不清的波动。要看清这一层，需要一处能看站点类目结构与竞品变化的地方。知虾站在看站点行情这一层，给的是多站点数据与站点分析的结果，把它当成外部参照，店内那些说不清的波动才有地方对照。

把线搬出来还有第三个好处，它让判断不再跟着当天的状态起伏。单店靠盯的时候，同一个人今天的判断和上个月可能不一样，累了就松一点，闲了就细一点。搬到可以检查的形态上之后，这条线是固定的，谁在什么状态下看到的都是同一条，这种稳定性在多店的时候比准确性更要紧。

举一个具体的场景。三家店都要在每周固定时间看一次退款记录，其中一家因为负责的人换了，新人不知道有这个动作，连着三周没看。这三周里那家店的退款原因结构发生变化，没人察觉。如果这个动作挂在一处共同的清单上，谁接手都会看到，这次漏看就不会发生。

这类共同的位置最容易被人当成形式，觉得多此一举。判断它有没有用的方式是看它是不是真的把动作串了起来：某个人休假的时候，他手上的动作有没有人接着做。有人接着做，说明这个位置起了作用；没人接着做，说明那个位置只是一份清单，没有真的进入日常。

还有一件事要在建通道的时候想到，就是通道本身也要有人维护。通道坏的方式通常是安静的那种：某个位置的内容长期没人更新，看的人几次之后发现它总是那些内容，就慢慢不看了。所以通道建成之后要有一个动作定期确认它还在起作用，而不是建好之后就当成已经完成。

还有一个现实的困难要说清楚：把判断搬到可以被检查的形态上，这件事本身需要一点前提，就是你知道自己在看什么。很多人说不清自己每次打开后台到底在确认哪几件事，只是习惯性地看一圈。这种情况下要先做一步回溯，记几天自己在看什么，把看的东西列出来，再从中挑出那几条可以固定下来的。

这份清单不需要长。多数人回溯之后会发现，真正每天必看的可能只有五六项，其余都是顺带扫过的。把这五六项固定成动作，剩下的靠它自己露出来就行。一开始就把清单列得很长，结果是每一项都看得不踏实，还不如只留最要紧的那几条，把注意力集中在那里。

还有一个成本问题值得算一遍。把五六项固定动作分给几个人，每人每天多花几分钟，一个月下来是一个可以接受的量。相比之下，某一次漏看带来的返工往往要花掉几个小时，还可能牵动别的安排。这笔账不需要精确，粗粗一比就能看出把动作固定下来是划算的，前提是这个动作真的被固定住。

这件事最后要落到一个地方：当有人不在的时候，他手上的那几项动作有没有人接着做。有人接着做，说明这套东西已经从个人习惯变成了团队的动作；没人接着做，说明它还只是某个人的习惯换了一个形式，本质上和盯没有区别。这是判断有没有真做成的一个很直接的标准。

从盯到通道，中间还有一个过渡状态值得认识，就是嘴上说。几个人在一个群里互相提醒，某家店的价格降了、某个款的库存不够了，靠人喊一句。这个状态比单靠盯进了一步，它把注意力从一个人分给了几个人。它的局限也很明显：喊的人得先看到，而看到这件事本身还依赖那个人的注意力，注意力耗尽的时候，通道就断了。

所以嘴上说这个状态不值得停留太久。它的价值在于能立刻降低漏看的概率，成本几乎为零，作为第一步很好。往下走就得把喊的内容变成固定的位置，让看到这件事不再依赖谁当时的注意力。判断有没有往下走的标志很简单：某个人休假的时候，原来靠他喊的那几件事还有没有人看到。

往下走这一步的时机也值得留意。多数团队是在吃过一次亏之后才开始做的，那次吃亏通常表现为一个已经存在几周的异常，直到造成明显后果才被发现。吃过亏之后做这件事的意愿最强，也最容易做成。要避免的是过了那阵子热度又回到原样，所以做的时候最好落成具体的动作，而不是停在共识上。

第二步没接上，事情再大也传不到人眼前

异常分哪几类、各由谁发现

第一类是会自己喊出来的异常，比如数据归零、库存见底、额度过期。这一类不需要任何设计，平台和后台本身就会把提示推出来。在多店场景下，这类异常的麻烦不在于发现，而在于数量：几家店同时推提示，看的人容易对提示本身麻木，看到之后越过去也是常有的事。

第二类要靠固定的动作才能看到，比如价格被同行拉开、评价的措辞开始变化、某个款式的转化在缓慢下滑。这一类不会喊，只有在有人按固定节奏去看的时候才会露出来。它的发现者应该是承担这个动作的人，而不是某一个专门负责发现问题的人，因为看得见的前提是每天真的走到那个位置。

第三类只有在做事的过程里才能感觉到，比如某个买家的语气变了、某个供应商的交货最近不太稳、某个渠道的响应速度慢了。这一类没有数据也没有提示，它落在做过这件事的人身上。别人来代看是看不出来的，因为他没有那份连续的感受。

这三类异常有一个关键的差别，就是它们的发现成本不一样。第一类不需要成本，它自己会到眼前；第二类需要一个人每天走到某个固定位置，成本是那几分钟；第三类需要一个人长期在这件事上，成本是时间本身。三类混在一起看的时候，人往往把注意力都花在第一类上，因为它的提醒最响。

合理的做法是按成本来分配注意力，而不是按声响。第一类交给位置本身去处理，只在真的需要动作的时候才介入；第二类的固定动作要保住，不能因为忙就先停它，因为它停了以后没有别的东西会替它喊；第三类依赖的是人在一段时间的连续在岗，所以排班和分工的时候要把它当资源看待，而不是当成自然而然会发生的事。

三类异常之间还有一层转化关系。第三类里那些反复出现、表现出来也越来越有规律的，通常可以变成第二类，也就是给它定一个固定动作去看。第二类里那些后来发现有明确判断标准的，又可以变成第一类，让位置自己替人看着。异常不是被消灭了，是被一级一级地往下推，推到某个位置自己就能处理的那一层。

在多店场景下，谁发现这件事比发现了什么更值得记录。同一类异常每次都由不同的人发现，说明这条通道时通时不通，靠的是运气；每次都从同一个位置被发现，说明那个位置已经稳定地承担了这件事。判断标准就是稳定两个字，而这恰恰需要通过记录才能看出来。

三类异常在时间上也有一个差别。第一类异常的延迟以小时计，当天就能知道；第二类的延迟以天计，取决于那个固定动作多久做一次；第三类的延迟往往是按周甚至按月来算，因为它本身就是一个慢变量。延迟越长的异常，处理的时候越难判断它是真的出了问题还是一段正常的起伏。

这个延迟差别带来一个实际的结论：第三类异常不要等到看清楚了才处理，而是要在看到苗头的时候就先记下观察的起点。比如某个款式的表现连着两次看都比之前弱一点，虽然还没到结论的程度，但可以把第一次看到的时间记下来。过几周再看这个起点之后的变化，判断就有了依据，而不是从头开始。

三类异常需要的回应方式也不一样。第一类的回应通常是具体动作：补货、续期、把数据接回来。第二类的回应是判断：这个偏离要不要管、管到什么程度。第三类的回应往往是决策：这个款还要不要继续投、这个方向要不要收一收。三种回应的周期不一样，混在一起安排的时候，决策那类容易被天天要处理的动作挤掉。

所以第三类异常最好单独留出时间，而不是夹在日常处理里顺便想一想。它的思考需要一段不被中断的时间，而日常处理的时候人是随时会被打断的。一周里留出一段相对完整的时间专门看这类慢变量，比每天顺手扫一眼要有效得多，因为慢变量只有在连续看的时候才会显出形状。

发现者的选取还有一个容易踩的坑，就是把这些事都交给一个人。让一个专门的人去发现问题，短期看是一种分工，长期看会失效，因为他不在做事的过程里，看不到第三类异常；而第二类要看的那些位置，他一个人也盯不过来。发现这件事天然是分散在做事的人身上的，硬要集中到一个人身上，反而谁都发现不了。

合理的分工是把发现这件事挂回到每个动作的承担者身上：做日常动作的人顺手就能看到库存和额度，看数据的人固定看一次订单，负责定价的人定期比对价格带。每个人多做的部分都不大，加起来的覆盖面却比一个专职的人更宽。这也解释了为什么多店场景下需要先把职责分清楚，职责不清的地方，正好就是没人看的地方。

分工之外还要有一个汇总的位置。分散发现的问题如果没有一处汇到一起，就会出现两个人都看到了却各自以为对方在处理的情况。汇总的位置不必复杂，一处大家都能写的地方就够，写清是什么事、什么时候看到的、谁在处理。多店场景下这个位置的价值随店数增长，因为店越多，同类的重复发现越多，汇总之后才能合并处理。

会断崖的异常最先被看到，会慢慢走的异常几乎不发声

哪几类异常最容易被漏掉

最容易被漏掉的第一类是那些进展很慢的异常。它们每天的变化小到看不出来，只有把两个相隔较远的时间点摆在一起才有感觉。这类异常不会触发任何提示，也不适合靠盯来发现，唯一可行的方法是定期拿一段时间之前的记录来做对比，而这个动作不做也不会有人喊。

第二类是那些被解释掉了的异常。数据掉了一点，第一反应是最近流量有波动，这个解释在多数时候是对的，于是没有人再往下追。问题在于，如果同一个解释连续出现几次，它就从解释变成了掩盖。识别它的办法是看同一个现象是不是被同一个理由解释过一次以上。

第三类是跨店之间的相对异常。单个店的指标都还在正常范围里，但相对关系变了，比如原来表现靠前的那家变成了中游。这类异常在任何单店的数据里都看不出来，因为每一家看自己都是正常的。它只能靠在同一个位置上同时看几家店才会显出来。

漏掉这三类还有一个共同的机制，就是它们都不会产生一次明确的失败。库存为零会挡住一单生意，数据归零会让页面上什么都没有，这些都会立刻带来可感知的后果。慢慢下滑的款式只是少卖了一点，被解释掉的波动只是这个月数据低了些，都没有人会觉得不对劲，因此也就没有人去追。

针对这个机制，一个实用的做法是给这几类异常留出人不忙的时间去看。日常的动作都在忙的时候做，忙的时候人的注意力天然会被那些有明显后果的事占满。挑一个相对空闲的时间段专门做一次慢速的比对，这类异常才有机会冒出来。时间不用长，一个小时往往够，关键是它得是固定的。

还有一个做法是换一个参照系来看。单看自己的店，数据在正常范围内就没什么可说的；把几家店摆在一起横向看，或者把自己的店和同类卖家的公开信息摆在一起看，相对意义上的异常才会显出来。横向看这件事本身不产生结论，它只是把异常从看不出来变成看得出来。

跨店之间的相对异常值得再多说一句它的发现方式。它的前提是几家店的数据能被摆在一起看，而这件事在很多团队里并不自然发生，因为每家店的负责人只看自己那一摊。让这件事发生需要一个理由，比如例会上固定看一次几家的对照，或者在一处地方把几家的关键数放成一张表。没有这个动作，这类异常几乎不可能被自己冒出来。

摆在一起看的时候，重点不是比高低，而是看相对关系有没有变。哪家原来靠前、哪家原来靠后，这个次序在一段时间内是相对稳定的。次序变了才值得看一眼，而变化的原因有时并不在那家店身上，可能是在别的地方调整了资源，也可能是有人的动作改了。把原因找对，比急着去处理那家店的数字更重要。

还有一类容易被漏掉的异常是那些发生在别人环节里的事。物流慢了、供应商到货少了、平台的某个入口改了，这些不出在自己手上的环节，从自己的位置往往看不出来。弥补的方式不是去盯别人的活，而是把几个关键节点的状态放到一个共同能看到的位置，每个环节自己更新，别人顺带就能看到。

被漏掉的异常有一个共同的补救思路，就是让它们的变化有一个固定的呈现位置。不放在那个位置上，它就只能在某个人的脑子里，而脑子里的东西没法被其他人看见，也没法在换人的时候被留下来。找位置这件事比想办法提高警觉性要有效，因为警觉性消耗的是人的状态，位置消耗的只是一次搭建的工夫。

有一类异常很容易被误认为已经处理过，就是那些在群里提过一句的事。提过之后大家的印象里这件事已经有人知道了，于是没有人再往下走；提的人以为会有人处理，看的人以为提的人在处理。这类事在一段时间之后几乎原封不动地还在那里，而它的存在感已经被那句提及消耗掉了。

破解的方式是给口头提到的异常一个落点。提到之后顺手在汇总的位置写一行，写清这件事由谁往下看。写这一行的动作只要几秒钟，它把一件事从谁都可以管的状态变成有人管的状态。多数团队缺的不是发现能力，正是这个几秒钟的落点。

还有一类被漏掉的是那些反复出现但每次都自己好了的问题。因为它自己好了，就没有人把它当成一件需要处理的事；因为是同一个问题，它其实早已不是偶然。看这类问题的方法是看它的间隔，如果某种偏离在几个月里出现多次并且每次都会自己恢复，它更可能是一个周期性的规律，值得提前安排好相应的动作。

发现之后的第一动作是什么

发现之后的第一动作不是处理，是先确认这件事是不是真的。多数异常第一次出现时都不足以说明问题，它可能是当天的波动、可能是一次活动的余波、可能是统计口径的临时变化。直接上手处理的后果是把一个正常波动当成问题来治，而治疗本身带来的扰动可能比波动更大。

确认的方式是看两样东西：一是这件事有没有伴随其他异常一起出现，二是它是不是第一次出现。单独出现且第一次出现的，先记下来看着；伴有其他异常或者第二次出现的，值得往下查一层。这个判断不需要复杂的数据，几分钟就能有结论。

第二件事是把这件事记下来。记录的价值不在于存档，而在于它让同类的事以后能被认出来。第一次遇到的时候它只是一个孤立的现象，第二次遇到的时候两份记录摆在一起，才看得出这是一类问题还是一件事重复发生。不记的话，第二次遇到时它还是第一次。

第三件事是判断归谁处理。多店场景下这个判断经常被跳过，因为谁先看见谁就顺手处理了，处理完也不一定说。短期看效率很高，长期看会让异常的归属变得模糊：同一个位置反复出现的问题每次由不同的人随手处理，没有人把它当成本位置该管的事。

确认这件事是不是真的，最省事的方式是找一个已经存在的对照。同一件事在另一家店的表现如何、同一件事在上一个周期的表现如何，这两个对照花几分钟就能调出来，而它们提供的信息往往足以让判断从模糊变成清楚。没有对照就去判断，靠的只是当下的印象。

确认之后还要判一个程度。同样是订单下滑，掉了一个档和掉了一大截，处理的方式完全不同。分程度不需要精确的数字，给它一个粗的档位就够：还在正常波动范围内的往下看、明显偏离但还没有到影响安排的程度、已经影响到下一步动作了。档位分清楚之后，讨论的重点就从要不要处理变成怎么处理。

记录这一步有一个容易忽略的细节，就是记的是结论还是过程。只记结论会出现两种麻烦，一种是过一段时间自己也说不清当时是怎么判断的，另一种是别人看到这条记录不知道该在什么条件下参考。记一句当时看到了什么、为什么判断是这样，比记一句结果要有用得多。

归属这一步要在记录里落到具体的名字上，不要落到岗位上。多店场景下岗位的名称往往比较宽，落上去之后容易出现在几个人的理解里都不包括自己。落到名字上，下次同类的事出现时，直接找到那个人就行，找错了也容易发现，因为一个人只有一个名字。

确认这一环还有一个容易被绕过的原因：确认本身不产生动作，看起来像是在浪费时间。处理就不一样，处理了至少有一件事被做了，心里踏实。这种偏好在大促期间尤其明显，那时候人人都想动手做点什么。可恰恰是这种时候，一次误判带来的扰动被放大得更多，因为整条链路都在满负荷运转。

确认的方式可以固化成两三步，不必每次重新想。第一步看它是不是伴随别的指标一起动，单独动和一起动说明的问题不一样；第二步看它在时间上是不是集中的，突然出现和逐渐出现对应的原因不同；第三步看有没有明显的解释，比如最近做了改价、做了活动、换了图片。三步走完，多数情况下判断已经清楚了。

记录这一步也有一个格式上的建议，写清三样东西：什么时候看到的、当时看到了什么、打算怎么处理。第三样可以写暂时不动，这也是一个处理决定。有了这三样，过一段时间回头看这份记录时，能立刻接上当时的上下文，而不用去猜当时为什么没管它。

归属这件事在多店场景下还有一个附带的好处：定下归属之后，同类的事第二次出现时可以直接找那个人，不用每次都重新商量一遍谁来做。这个好处在事多的时候特别明显，因为重新商量的成本不在于商量本身，在于它打断了正在做的别的事。

在确认这一步里，有一个信息源经常被忽略，就是做这件事的人当时的现场感受。数据上看不出来的东西，做的人可能已经感觉到了，只是他也没有把它当成一件需要说的事。发现异常之后问一句最近有没有觉得哪里不太顺，往往能得到数据之外的一条线索，而这条线索经常正好指向原因。

确认之后不管是处理还是先放着，都要考虑这件事会不会影响别人的动作。比如某个款要停，别人可能正在为它准备素材；某个价格要调，别人可能正在按原价做计划。多店场景下这一层尤其重要，因为动作的连锁反应更长。判断的方式是问一句这件事有没有人在等它，答案是有，就得先通知一声。

处理完之后的收尾也是一步，容易被当成顺手的事跳过。收尾的内容很简单：这件事最后是怎么处理的、有没有留下什么需要下次注意的地方。这一步做完，下次有人翻到这条记录时能拿到完整的结论；不做的话，记录里只留了一个悬着的问题，还不如不记。

哪些异常不用马上处理

第一类是不影响当下交易的那些。页面的措辞不够准确、描述里少提了一条属性、某张图的顺序不理想，这些如果修正起来要花时间，可以排到后面去。它们的共同特点是不挡住买家下单，只是让体验差一点。把它当成急事处理，占用的正是处理真急事的时间。

第二类是原因还不清楚的那些。看到某个款的表现不对，先动手调价或者换图，很多时候调完之后也不知道是调对了还是它自己恢复的。更稳的做法是先记下观察的窗口，几天之后再看它有没有自己回到原处。真正需要处理的问题不会因为多等几天而失控。

第三类是同一类的重复项。几家店同时出现了同一类异常，处理的时候容易一家一家挨过去，把同一套动作做了几遍。更省力的做法是先把这一类异常整体看一遍，找到共同的那一段，改一次覆盖全部。挨个处理的成本是乘法，整体处理的成本是加法。

判断一类异常要不要马上处理，可以问一个问题：如果这周不管它，一周之后情况会更糟吗。答案是不会，那就可以排到后面去。这个问法比按照严重程度排更实用，因为它把时间和后果联系起来，而排优先级的时候人容易被事情本身的大小牵着走。

还有一类不用马上处理的异常，就是那些看起来严重但影响面很窄的。某个冷门款式出了问题，看起来是个事故，实际它一周只出几单，处理的收益有限。反过来，某个销量最高的款问题很小，但它的影响面大，反而应该优先。严重程度和影响面是两个不同的维度，排的时候要看后者。

把不用马上处理的异常堆在一个地方，攒到一定量再一起过一遍，这个做法比每发现一件就处理一件要省力得多。一起过的时候能看出它们之间的共同点，有些可以合并成一个动作解决，有些会发现其实根本不需要处理。分开处理的时候，每一件都要重新建立一次上下文，成本要高不少。

要留意的是，先放着和不管了是两件事。先放着的意思是记下来、定了什么时候回头看，到时候真的会回过头去处理。没有记下来的放着，过一段时间就变成真正的遗忘，下次再看到同一个问题时还是第一次遇到。两者的区别只在于有没有记，但结果差得很远。

先放着的异常需要有一个容器，不能只是嘴上说先放着。这个容器可以是一张清单或者一处便签，写清是什么事、什么时候看到的、打算什么时候回头看。有容器和没容器的区别在于，有容器的会在约定的时间被重新想起来，没容器的会安静地消失在别的事情里，直到它以更大的形式再出现一次。

回头看的时候，会有一部分异常已经自己消失了。这部分不需要处理，但值得记一句它自己恢复了，因为这个信息对你理解这家店的正常波动范围有帮助。攒上几十条这样的记录之后，你会大致知道哪些波动属于常态，看到类似的再次出现时就不必再花时间去确认一遍。

还有一部分回头看时会发现变得更明显了，那才是该处理的。这时候处理比最开始就动手要好，因为缘由清楚了，处理的方向也就清楚了。最开始就处理，往往是在原因不明的情况下做动作，做完也不知道有没有效，反而多了一个变量，让后面的判断更困难。

这里的分寸在于时间。先放着不等于一直放着，回头看的时间点要事先定下来。定的时候不用精确到天，给一个粗的范围就够，比如几天之后、下周一之前。有了这个范围，事情就不会无限期地挂着，也不至于因为天天想着它而占掉本该放在别处的注意力。

还有一类可以明确放在后面，就是那些只在特定条件下出现、而那个条件眼下并不存在的情况。比如某个词在大促期间会带来大量无效流量，现在不在大促，这件事就没有处理的必要。把它记在对应的条件下面，到那个条件快要出现之前再看一眼，既不会忘，也不必现在花时间。

把不用马上处理的事按条件归档，比按时间归档更符合实际的使用方式。条件归档的意思是这件事挂在某个触发点上，比如下一次大促之前、下一次补货之前、下一个换季之前。这样一来，回头看这件事不需要靠日历提醒，而是被那个触发点自然带出来，忘掉的概率更低。

这个做法还有一个附带好处，就是能让待办清单保持在一个可读的长度上。所有事都堆在一张清单上，清单会迅速长到没人愿意看；把条件性的那部分挪到对应的触发点下面，清单上剩下的都是当下真的要动的。清单短了之后，人才会真的每天去看它，而这正是清单存在的意义。

最后要提醒的是，先放着这件事需要有人在中间做一次筛选，不能发现一件就放一件。筛选的动作很简单，看一眼这件事如果不管会怎样，会怎样就留在清单上，不会怎样就挪到对应的条件下面。少了这一步筛选，先放着就会变成堆放，堆放久了清单同样会失去作用。

越靠下表的异常，越依赖人的主动动作才会浮现

异常记录攒下来有什么用

记录攒起来第一个用处是能分辨这是一件事还是一类事。同一种异常在半年里出现了四次，其中三次都发生在同一个环节，这就不是四件事，而是那个环节本身有问题。没有记录的时候，每次都是独立处理，处理完就忘，半年之后也总结不出这个规律。

第二个用处是能反过来检查通道有没有效。某类异常在记录里出现的间隔很长，有两种可能，一种是它真的很少发生，另一种是它发生了但没被看到。区分这两种情况的办法是看这一类异常第一次被看到是在什么位置：如果总是被别人顺口提到才发现，说明这条通道还没建起来。

第三个用处是给判断提供一个参照。遇到一个现象拿不准它算不算异常，翻记录看过去有没有类似的，以及当时是怎么处理的。这份参照不需要精确，几行字就够，它的作用是把判断从凭印象拉回到有先例的基础上，尤其是在换人之后，这份记录就是接手的人手里仅有的一份先例来源。

记录还有第四个用处，就是能看出这套通道本身还剩多少没盖住的地方。把记录按发现途径分类，看有多少是别人顺口提到才知道的，有多少是自己按节奏看出来的，有多少是出事之后才回头发现的。第三类的数量是最值得盯的，因为它说明这一类异常在出现的时候完全没有被接住。

这个数值得定期看一次，不必频繁，隔一段时间看一次就行。看到第三类占比在下降，说明前面补的通道真的起了作用；占比没有变化，说明补的那些通道落点偏了，可能补在了容易看的地方，而不是真正漏得最多的地方。这种调整靠感觉做不了，只能靠这个比例来说话。

记录攒起来之后会成为一份很好用的交接材料。接手的人最想知道的就是这家店过去出过哪些问题、现在还有哪些在观察中。翻一遍异常记录，这两个问题都能有答案，而且是他自己看出来的答案，比听别人讲一遍留下的印象要深。这份材料不需要额外整理，它本来就是日常动作的副产物。

最后一点是关于记录的写法。记录不是写给别人看的正式文档，它的读者首先是自己和接手的人。所以不必讲究结构，几行字、一个时间、一句结论就够。写得越轻，越容易被坚持下来；而这件事的全部价值都建立在坚持上，写一次就停的记录和没有记录差不多。

记录用到后来会发现，它最大的价值是让这家店具备了一种能力：把过去发生过的事当成证据来用。没有记录的时候，讨论一件事只能靠各自的印象，而印象往往取决于谁记得更清楚、谁说得更有底气；有了记录，讨论的起点就是一份大家都能看到的东西，讨论的内容也因此从谁的印象对变成了这件事本身该怎么处理。

这份记录在跨店的时候作用更明显。同一类异常在甲店出现过并处理过，乙店再遇到同样的情形时，不需要重新摸索一遍。做法是把记录按异常类型整理，而不是按时间堆在一起。按时间堆的记录只能顺着翻，按类型整理的能被直接找到，后者才真正能用起来，尤其是在事多的日子。

记录还有一面是自己的收益。同一个人处理过的事越多，越容易误以为自己什么都记得，而实际情况是记得的是最近那几件。翻一翻更早的记录，往往会发现自己当初已经得出过某个结论，只是后来忘了。这种提醒不需要别的成本，只需要记录本身存在并且能被翻到。

最后，记录这件事要考虑它能不能被坚持。写得太正式、格式太复杂的记录，在忙起来的时候第一个被放弃；随手记的、只要几行字的记录，反而能被长期执行。判断一份记录方式好不好，不看它看起来专业不专业，看的是连续三个月之后还有没有人在写。

记录用到一定量之后，会自然出现一个新的用法，就是拿它来给自己排事情的优先级。看看最近这段时间记录里出现最多的是哪一类异常，那一类就是当前最值得投入注意力的方向。这个判断的依据来自真实发生的事，比凭感觉估计哪里问题多要准，而且它不需要额外的统计工作。

这个用法在人多的时候要小心一个偏差：记录得好的人，看起来问题就多。如果按记录数量来排优先级，容易把注意力压到那些认真记录的人身上。避免的办法是看相对变化，也就是同一个人或同一家店在一段时间里的异常数量有没有下降，而不是看总数量谁多谁少。

记录还有一个不太被提起的用处，就是给判断留一条退路。一段时间之后回头看某次决定，如果当时的理由和依据都还在记录里，就能判断那次错在哪里，是判断错了还是当时的信息不够。没有记录的时候，复盘只能得出一个模糊的印象，而这种印象往往倾向于把责任归到某个人的判断力上，而那个结论通常不准确。

关于记录的载体，越简单越容易被坚持。纸上的本子、一个公共的便签位置、一份简单的表，哪一种都行，关键是所有人知道它在哪里、知道怎么写进去。工具本身的先进程度对这个动作几乎没有帮助，因为这件事的全部难点在于持续写，而不在于写得多工整。

登记之后重复出现的那一类，下降得比发现速度更快

怎么减少异常的发生

减少异常的第一个方向是减少那些由动作不规范引起的。多店场景下这类异常占比通常不低，因为同样的动作在几家店由不同的人做，做法稍有差别就可能引出问题。把这类动作的做法固定下来，异常自然会少，而且这一类的减少是立竿见影的。

第二个方向是给那些只在特定条件下出现的异常留一个提前量。比如活动期、换季期、补货周期，这些时点本来就是异常高发的时候，事先知道它们会来，就能提前安排好人的注意力。这个做法不减少异常的发生，减少的是异常发生时无人照看的窗口。

第三个方向是承认有一部分异常是消不掉的。市场在变、买家在换、同行在动，这些都会持续产生新的偏离。要做的不是让它们消失，而是让它们出现的速度慢于你处理的速度。这个比例一旦反过来，管理就会进入一种永远在追赶的状态，那时候真正的问题不是某一类异常，是节奏本身。

除了上面的三个方向，还有一个容易被忽略的方向是把已经处理完的异常做成一个动作。某个问题处理过之后，问一句这件事能不能变成一步日常动作，如果能，就把它挂进去。这样处理一次的价值就不只是解决了当下的问题，而是让这一类问题的下一次出现在更早的位置被接住。

这个方向的价值在积累上。一件事处理完就结束，一年之后这类问题还是靠应急处理；一件事处理完顺手挂一个动作，一年之后同类的问题大部分在冒头的时候就被拦住了。差别不在处理能力，在于有没有把已经付出的那份努力留下来，而留下的方式往往只是一句话。

同时也要承认，减少异常这件事有一个上限。多店经营里的变量很多，市场、同行、平台的规则都在动，新的异常会持续产生。把目标定在让异常消失，追求的过程会让人不断加动作，最后加到没有人能坚持的程度，反而连原有的那几条也保不住。合理的状态是留几条最要紧的线，其余的靠记录和节奏去接。

判断当前状态是不是健康的，可以看两个比例：一是新出现的异常里，有多少是被提前定好的动作接住的；二是处理一件事平均要花几个人参与。前者在上升、后者在下降，说明这套东西在往好的方向走。这两个数不需要精确，凭记录粗粗估一下就能看出方向，而方向比数值更要紧。

有一个更根本的减少办法，是把异常的来源分类看清楚。多数异常可以归到两个来源：一类是动作上的偏差，也就是这一步没按该有的做法做；另一类是条件上的变化，市场、同行、平台的规则动了。前一类可以通过把做法固定下来减少，后一类减少不了，只能提前准备。分清楚之后，力气就不会用错地方。

前一类里最值得关注的是那些由交接或者换人引起的动作偏差。这类异常有明显的特征：在人员变动的那个时间点前后开始出现，并且集中在某几个环节上。看到这个特征，处理的重点就落在了记录和说明上，而不是在结果上做补救，因为补救只能解决这一次，做法不清楚下一次还会出。

后一类的准备方式是在变化发生之前把可能的几种情况想一遍。不必想得很全，把最可能的两种想清楚就够，想清楚之后要准备的动作往往只有一两个。这种准备的价值不是因为预测准确，而是因为变化真的发生的时候，人不用从零开始反应，那段时间差往往就是事情可控与失控的分界。

两个来源的减少方式不同，评估方式也不同。前一类可以看同一类异常重复出现的次数有没有下降；后一类只能看每次发生之后的处理时间有没有缩短。用前一个标准去衡量后一类，会得出没用的结论；用后一个标准去衡量前一类，会觉得自己做得挺好，实际上同一个问题一直在重复。

在减少异常这件事上，还有一个值得单独提的方向，就是把那些已经反复出现的异常往上追一层，去找它为什么会反复出现。多数反复出现的异常背后都有一个没被决定的事，比如某件事归谁、某个口径按哪一套、某个动作要不要做。这些没被决定的事会持续地产生偏离，而每一次偏离看起来都像是一个独立的意外。

追这一层的做法是问一句这件事本来应该是什么样子。如果连应该是什么样子都说不清，那说明它需要一个明确的规则；如果说得清但实际不是这样，那说明规则和执行之间有断层。两种情况要做的动作完全不同，前一种是定规则，后一种是查执行，混在一起处理就会两头都做不好。

顺带说一件跟行情判断有关的参照。有些异常看起来是执行问题，实际是外部条件变了，比如某个品类的价格带整体下移、某个词的热度在退。判断这类异常的时候，需要一处能看站点的类目结构、价格分布和竞品信号的地方。知虾站在看站点行情这一层，给的是多站点数据、站点分析、关键词分析与竞品监控的结果，拿它对照，能分出一件事是自己做变了还是外面变了。

最后一个提醒是关于力气的分配。减少异常这件事做到后面，边际收益是递减的，从二十件减到十件容易，从十件减到五件难得多，从五件减到两件往往要付出不成比例的代价。判断停下来的时候很简单：看继续投入的那个动作，是不是已经开始影响日常该做的事，是的话就说明该收了。

常见问题（FAQ）