Shopee多店铺管理怎么把经验写成手册

手册该从哪一件事开始写

最常见的启动方式，是坐下来把流程从头到尾过一遍，按先后顺序写下来。写的人往往写到第三步就发现写不动了，因为每一步后面都连着七八种情况，展开哪一种都缺资料。于是这份手册停在一半，存在文件夹里，之后每次想起来都觉得是个没做完的活。

更省力的起点是最近一次真的出过问题的那件事。这件事有时间点、有当事人、有损失，素材是现成的，不需要回想也不需要设计。一条事故往往能带出三到五条规则，而且这几条规则自带说明，因为它们的存在理由就是拦住那次的事，不用额外解释。

举一个具体的场景。某家店上一次把入仓的截止日记错了一天，货晚到三天，那一批的曝光节奏跟着乱了。往下拆这件事，能拆出四条：这个日期由谁记、记在哪个地方、由谁在什么时候复核、提前几天开始提醒。四条规则一次就出现了，而且每一条都指着一个具体的动作。

从事故开始写还有一个看不见的好处，就是写出来的东西别人认。因为这事情在团队里发生过，几个人都记得当时的麻烦，你把它写成一条规则，别人一看就知道这条是为什么立的。从流程里推出来的规则没有这层来历，读的人只能凭信任接受它，接受的程度自然也低一些。

有一个更细的判据，用来决定先写哪一条：看这件事在过去两三个月里重复出现过几次。出现过两次以上、每次的处理方式还不一样的，优先写。这类事已经证明它会反复发生，而且团队内部对它没有统一答案，写下来的收益最直接。只出现过一次的，先在旁边记一笔放着。

举一个具体的分歧。两家店对缺货商品的处理做法不同，一家发现缺货直接下架，另一家留着页面等补货。两种做法各有理由，下架省得买家白跑，留架保住累积的浏览和评价。这个分歧本身就是很好的写作素材，因为它已经不是假设，是真实存在的两套做法。

还有一种起点是新人问得最多的那几个问题。把最近新人入职头一个月问过的问题按次数排一遍，排在前面的几个通常就是手册最该补的地方。这些位置之所以被反复问，正是因为它们没有落在纸上，每个人进来都要重新问一遍，问完也只留在问的人和答的人的脑子里。

一次只处理一件事，这是维持质量的做法。写完一件，隔一天回过头看一遍，确认读得懂、能执行，再写下一件。一次坐下来写十件事，往往写的时候很顺，写完却说不清哪一条被用过、哪一条其实还没想明白，隔一个月自己都不想重看第二遍。

写之前先做一件事：把这件事的经过按时间顺序摆一遍，只写事实，不写判断。哪一天发生了什么、谁做了什么、结果如何，一列就是几行。摆出来之后往下看，出问题的那个点往往自己就露出来了，不需要额外分析。省掉这一步直接写规则，写出来的规则容易落在症状上，而不是落在真正漏掉的那个动作上。

找到那个点之后，要往前多问一句：为什么当时没有做这一步。答案通常有三种，不知道有这一步、知道但当时来不及、知道但是别人以为有人会做。三种原因对应三种不同的写法，第一种要写进必读的位置，第二种要给出提前量，第三种要把责任落到一个具体的人头上。写混了，规则就落不下去。

同一件事里如果牵出了好几条规则，把它们放在同一条下面，标上同一个来源。这么做不是为了排版好看，是为了后来的人能看出这几条是一起立起来的。过一段时间如果有人质疑其中一条，回到同一个来源去讨论，不至于只挑一条出来改，把当初的搭配关系拆散。

写第一条的时候不要想着覆盖全部。第一条只要做到一件事：下次同样的情况再发生，有人能照着它避开。做到这一点，这一条就成立了。剩下的场景会在以后的事故里自己冒出来，冒出来一条补一条，补的过程中你会发现哪些位置反复需要补，那些位置才是真正值得写细的地方。

还有一种很值得优先写的情形：这件事在两家店里的做法不一样，而两边的做法都能跑通。这种分歧不会自己暴露，因为没有一边出过错，谁都觉得自己那套是对的。它导致的后果是同一个动作在两家店花的时间差出一截，或者同一批货的呈现方式不一致。这种分歧本身就是最值得写下来的一类素材。

写的时候把两边的做法并列摆出来，写清各自适用的条件，然后定一个当前采用的做法。并列这一步不能省，它记录的不只是结论，还有当初为什么有两种答案。过一段时间条件变了要换回另一种做法，这份记录就是回头的依据。只写结论的话，换了做法之后没人说得清当初否掉的那条为什么被否掉。

顺带说一句顺序上的事：先写各家店共用的那几条，再写只在某一家适用的。共用的条目数量通常不多，可能十几条就够，但它覆盖了大部分日常动作。这几条写完，新人在任何一家店都能先动起来，剩下那些特殊的部分可以边做边补，不至于一上手就被一堆分店特有的规则挡住。

第一步跳过，后面写出来的多半是流程而不是规则

写手册最容易犯的一个错

最容易犯的错是从流程开始写，不从事故开始写。这么写出来的手册读起来很顺，从头到尾一条线索，看起来很像一份规范。麻烦在于它用的是写的人脑子里的顺序，而用的人需要的是遇到情况时的判断，两个方向正好相反，用的人翻到需要的那一页往往要绕一大圈。

从流程开始写，写出来的东西容易是一堆正确的原则。处理要及时、数据要核对清楚、价格要合理，这几句放在任何一家店都成立，放在任何一次具体操作上又都用不上。读的人看完没有疑问，也没有得到任何一条可以当天就照做的指引，翻完就放下了。

有一个很简单的判据能分出手册里哪些条目真正有用：这条规则是因为有人违反过它才写的吗。没有人违反过的规则，多数不需要写进手册，它属于职业习惯那一层。同样，一条规则如果举不出一件具体的场景，那它大概还没想清楚，写进去也只会让读的人多停一秒。

从流程开始写还有一个连带后果，就是这份手册和其他人没有关系。流程是一个人整理出来的顺序，读的人如果本来就不按这个顺序做事，他会觉得这份东西是别人的工作，不是自己的。从事故开始的写法天然避开了这一点，因为那件事本身就是大家一起经历的。

从流程开始写之所以有吸引力，是因为流程看得见。一个完整的链路能从头到尾摊在纸上，写出来有结构感，也容易显得完整。从事故开始写不是这样，一条一条互不挨着，中间还隔着空档，写的人写到一半会怀疑这样零散地记下去，最后能不能拼成一份像样的东西。

把两种写法摆在一起看最清楚。按流程写出来的这一条是：上架前要检查商品图片。按事故写出来的这一条是：上一次有一批商品的主图上带了别家的标识，整批被退回重做，所以图片在上传之前要确认画面里没有非本店的标识。前一条谁看了都点头，后一条拿起来就能执行。

从流程开始写还有一个连环的副作用。写的人为了把链路写完整，会把每个环节都照顾一遍，包括那些从来没有出过问题的环节。这些环节占掉了手册一大半的篇幅，而真正容易出问题的几个环节，因为分给它们的篇幅和别人一样，反而被淹在中间，翻起来不容易找到。

如果手册已经按流程写成了一版，不用推倒重来。把那份流程当成一份目录，在出过问题的那几步下面挂上从事故转出来的条目。这么一改，原来那份文件还能当骨架用，规则的落脚点从流程节点换成了具体的位置，读的人顺着流程走的时候，正好在需要的地方看到那一条。

还有一个更隐蔽的表现形式：按岗位分工写。以岗位为线索，把这个位置该做什么列一遍，写出来也很有结构。问题在于多店场景下，同一个人往往在几家店之间轮着做事，岗位的边界本来就模糊。按岗位写出来的手册，遇到一个人同时管两家店的时候就用不上了，因为那几条规则挂在两个不同的岗位下面。

一个实用的改法是，把已经写好的每一条拿出来，问一句这条规则在两家店都会用到吗。会的，就把它提到公共那一层；只会用到一家的，标明是哪一家。这么分一遍之后，手册自然分成了公共部分和分店部分，新人读公共部分就能上手大部分事，分店部分按需看，篇幅和阅读负担都比原来小。

从流程写还有一个连带问题，就是它会把手册变成一份静态的东西。流程是固定的，你按流程写，写完了就成了一份定稿的文档，剩下的动作是等下次再改版。从事故写出来的是活的，每出一件事就长出一条，长出来的时间点本身就是它的价值，别人能看到这条是因为上个月那件事才有的。

有一种情况确实适合从流程开始写，就是团队正在把一件事从头做一遍，之前完全没有做过。这种时候没有事故可依，流程本身就是第一批经验。但只要跑过两三轮，就要把写法换过来，从事故里长规则。一直按最初的流程维护，手册会慢慢和实际做法脱开，因为实际做法总是先变，流程文档总是后改。

按流程写还有一个具体的后果，就是很难看出哪一条在实践里没被执行。规则如果挂在流程节点下面，检查的时候只能顺着整条流程走一遍，走完才知道哪一步被漏了。规则如果挂在具体的事故下面，检查就变成问一句这件类似的事最近有没有再发生，回答起来快得多，也更容易被例行地做起来。

有人会问，从事故写会不会让手册变成一份只会补漏洞的东西，永远只防着过去出过的错。这个担心有道理但不完全对。写得多了会发现，从事故里长出来的规则有不少是通用的，比如每个动作后面都要有人确认一次，这一条能从好几类不同的事故里长出来。这类反复出现的规则，才是手册里最结实的部分。

判断自己有没有犯这个错，有一个很快的自查方式：把手册里的每一条拿出来，问它对应的那件事具体是什么。答得出来的条目是有效条目，答不上来的多半是从流程里推出来的一般性原则。数一下两类的比例，如果答不上来的超过三成，说明这份手册的写法偏了，需要把那些条目要么补上来历，要么清出去。

越接近具体动作的条目被翻得越勤，越接近道理的条目落灰越多

哪些内容必须写进去

第一类是时间点，也就是什么时间要做什么、由谁做、晚了会怎样。这类内容最硬，也最不容易写含糊。写的时候要求是具体到可以核对，比如某个动作在每周几之前完成，而不是笼统地写成及时跟进。含糊的时间点等于没有时间点，因为每个人对及时的理解不一样。

第二类是判断的边界条件，也就是什么情况下必须停下来问人。这一类常被低估，因为写的人觉得什么事都该自己拿主意。实际上一家店最容易出大错的地方，恰恰是某个新人遇到一个自己拿不准的情况，硬着头皮按自己的理解处理了，处理完也没有告诉任何人。

第三类是只在出事时才会被想起的信息：账号在谁手上、遇到这类问题先找谁、上一次类似的事最后是怎么收尾的。这些信息平时用不到，一用就是急的。它们写进手册的成本很低，往往就是几个名字和位置，不写的时候的代价却是一次次的现场打听。

时间点这一类要写到能对着日历核对的程度。比如每周一上班第一件事是看上一周的退款记录，这一句第二天就能检查有没有做。换成定期看退款记录，就没有人能说清做到没有，因为定期是什么时候、多久算一次，各人的理解本来就不一样，检查的时候也无从对照。

边界条件最好写成一句短话，形式是遇到什么情况就停下来问谁。这句短话的作用是把一段判断权交出去，避免一个刚接手的人遇到没见过的情形时硬扛过去。写的时候要避开重大情况要上报这类说法，重大这两个字每个人心里那条线划在不同地方，等于没有写。

兜底信息要写全到另一个人照着能找到的程度。账号现在在谁手上、用什么方式保管、上一次遇到这类问题最后是找谁解决的，这几件事平时没人会翻，出事的当天能不能少花半天工夫全看它。把这些信息写下来，只需要几个名字和几个位置，几乎不占篇幅。

判断依据这一栏值得单独留出来。写清这条规则是因为哪一件事立的、当时的结论是从哪儿来的。有依据的规则被质疑的时候能回到原点重新讨论，把当时的条件和现在的条件摆在一起比。没有依据的规则只能靠谁的声音大来定，而这种定法在几次之后就会让人对整本手册失去耐心。

除了这三类，还有一类值得写但容易被忽略，就是交接时最常被漏掉的那几件事。做法很直接，回想上一次有人接手或者休假的时候，接手的人在头一周问过什么。那些问题里反复出现的，基本就是手册缺的部分，而且这一类内容的特点是平时看不出来，一到换人的时候就全部暴露。

时间点还要区分两种情况，一种是固定周期的事，一种是跟着某件事发生的事。前者写清楚哪一天做，后者要写清楚在哪件事之后立刻做，比如货到之后当天内盘一遍。第二种最容易漏，因为它没有一个固定的日子提醒你，全靠当时那件事被记住，而那件事在忙的时候恰好最容易被忘。

边界条件写的时候，最好再补一句停下来问人之后会发生什么。这句话的作用是让照着做的人心里有底，知道自己停下这一步不会耽误事。很多新人不敢问，是因为怕麻烦别人或者怕显得不行。手册里写明这类情况本来就是该问的，等于把问这件事变成了标准动作的一部分。

兜底信息这一类要定期刷新，因为它最容易过期而看不出来。账号位置会变，联系人会换人，上次的处理结论在新的情况下可能不成立。可行的办法是给这几条标上复核日期，每次手册过一遍的时候顺手确认一下。这一类内容一旦过期，出事的时候照着翻反而会绕远路。

这四类内容之间有一个优先级。时间点和兜底信息是最先要有的，因为它们最容易被检查，也最不容易写错。边界条件排在第二，它需要你想清楚哪些情况自己不该拍板。判断依据排在第三，它的价值要在规则被质疑的时候才体现出来，所以可以边用边补，不必一次写完。

还有一个容易被忘掉的必备项：这条规则是谁定的。写出定规则的人，不是为了追责，是为了让读的人知道遇到拿不准的情况去找谁问，以及这条规则将来要不要改可以找谁商量。在多店场景下这一点尤其重要，因为几家店的经营状态不一样，同一条规则是不是适用，往往要看它当初是为哪家店的哪种情况定的。

时间点写完之后，建议顺手在手册旁边配一张日历，把固定周期的那几个节点标上去。这张日历上可能只有五六件事，但它能让手册里那几条时间类规则真正落到日子上。没有这张日历，那几条规则还是躺在文字里，等谁来翻。有了它，谁到了那一天都会想起来去看一眼。

哪些内容不要写进去

不要写一查就知道的常识，比如后台的入口在哪里、平台某条通用规则的原话。这类内容的共同特点是更新快，写进手册等于给整本手册留了一个会过期的部分。更实际的做法是在手册里留一句指向，说明这类信息去哪个官方位置看，而不是把原文抄进来再自己维护。

不要写人的评价和情绪。某个人做事不认真、某个环节的人不好沟通，这种句子写进去没有任何指导作用，读的人也无法照做。如果一件事确实反复出问题，该写的是这件事卡在哪一步、由谁在什么时间点确认，把问题落到动作上，而不是落到人的性格上。

不要写只有一两个人看得懂的内部叫法和缩写。手册的使用者本来就不在同一个脑子里，缩写第一次出现的时候必须展开。这条看起来是文字习惯问题，实际会直接影响手册能不能被新人用起来，因为新人卡在第一个看不懂的词上，往往就合上不看了，也不会来问。

不要写操作路径。后台的菜单叫什么、某个按钮在哪一栏，这类信息平台一改版就作废，而改版的频率往往比手册更新的频率高。更稳的写法是写清这类信息去哪里找，比如某个动作在商品管理的哪一层，把找的方法留下来，而不是把当时的那条路径抄一遍。

不要写同一个结论的多个版本。同一件事在手册里出现两遍，第二遍的说法还稍微不同，读的人就会停下来猜哪一条是最新的。这种情况在实际使用里很常见，因为手册由几个人在不同时间各补过一段。发现两处冲突就合并到一处，只留一个说法，另一处删掉或者改成指向。

不要写尽量、尽可能这类词。这类词听起来柔和，实际是把判断又推回给了读的人：到底做到什么程度算尽量，没有人知道。手册的作用本来就是替人收口一部分判断，用上这类词等于没有收口，读的人还是要停下来跟别人确认一遍才能动手。

不要在一个条目里塞进三种情况。看上去这样省了篇幅，读的人却要先在一段话里挑出跟自己相关的那一句，再判断剩下的部分要不要读。宁可拆成三条，每条只管一种情况，一条一行。拆开之后条目数量变多，但每一条翻到就能用，总的时间反而少。

不要写只在一家店成立的特殊做法，除非标明了它只适用于那一家。多店场景下，同一件事在几家店本来就可能做法不同，如果不标明适用范围，读的人会默认它适用于全部。这个默认一旦形成，公共的部分和分店的部分就混在了一起，新人读完整本还是不知道该在哪家店按哪一套做。

不要写刚落地的、还没跑过一个完整周期的做法。新做法在头一个月往往还没暴露出它的副作用，这时候写进手册，等于把一份未经检验的东西当成了规则。做法是先在一个地方试，跑够一段时间，确认它没有带来新的麻烦，再写进手册并标上生效时间。

不要用表格装那些本身就不是并列关系的内容。表格适合装同一类东西的几种取值，不适合装一条规则的前因后果。把一段有来龙去脉的说明塞进表格的一格里，读的人只能看到被压缩过的半句话，剩下的信息要靠猜。该用一段话讲清楚的，就用一段话讲。

不要写呼吁式的句子，比如大家要重视、务必认真核对。这类句子表达的是态度，不是做法，读的人看完不知道具体多做什么。遇到想写这类句子的地方，往下追一句到底是哪一步没有做到才需要这句话，把追出来的那个动作写进去，这一条才算真的有用。

不要写会随行情变动的具体数字。某个类目当下的价格落在哪一段、某个词最近的搜索量级是多少，这类数字写进手册，过两个月就成了一份误导。可行的写法是把手册里这一条写成看哪一层：定价与价格区间这一类判断，知虾站在成本与区间的算法这一层，给的是定价计算与站点分析的结果，手册里只留一句依据取自这一层，具体取值每次去看。

不要写那种需要读过前一条才能读懂后一条的条目。手册的使用方式是翻到哪读到哪，不是从头读到尾，条目之间互相依赖会让跳读的人读不懂。遇到必须依赖前文的，就在这一条里重复一小句前提，多写几个字比让读的人回头翻要划算，何况他也不一定知道该往回翻到哪一条。

不要写平台政策的分析过程。某条规则的来龙去脉、为什么这样定、以后可能会怎么变，这些内容本身有价值，但它的更新频率比手册里其他内容都快，放进来会拖着一整本手册一起过期。这类内容适合放在另一个位置单独维护，手册里只留一句结论和最简的适用条件，再留一个指向。

不要写没人负责的条目。一条规则如果找不到谁盯它，写进手册只是一个愿望，执行起来没人检查、出错也没人认领。遇到这种情况，要么给它指定一个人，要么先不写。多店场景下这一点比单店更要紧，因为人多了以后默认别人会管这种情况发生的频率明显更高。

手册怎么更新才不会被弃用

手册被搁置的原因通常不是内容写错了，是没有一个更新的入口。改一条要走一道手续，要先找谁批，批完还要重新发一遍，人就先在脑子里记着，等攒够了几条再一起改。攒的过程里，手册和实际做法开始分叉，分叉到一定程度就没人再信它了。

更可行的做法是把更新的入口挂在一个已经存在的动作上。每次某件事出问题、处理完之后，顺手往手册里补一条，补的内容不必讲究文采。每次例会上过一遍这个月新增的条目，确认它们确实成立。这样一来更新不需要额外的时机，它变成了既有动作的一部分，被落下的概率小很多。

第二件事是让手册有一处明确的当前版本。放在共享位置的同一份文件，改动留时间和改动人，不要各人手上存一份自己改。这一点在多店场景下更要紧，因为读手册的人分散在几家店，如果每个人手上是不同时间的版本，同一件事会按几种不同的做法执行，出了问题还查不到源头。

还有一条实用的做法，给每条规则标一个上次确认的时间。三个月以上没被确认过的条目，要么是真的稳定，要么是已经没人用它了，两种情况都值得在例会上挑出来看一眼。这个动作成本很低，一次例会十几分钟能过掉一批，效果是手册不会长期挂着一堆已经过时的条目。

把更新的动作挂到已有的节点上，比安排定期回顾管用得多。定期回顾的问题在于它没有一个自然的触发点，忙起来第一个被推掉的就是它，推掉几次之后这件事就从安排里消失了。挂在出事处理之后和例会上，它就有了固定的位置，不需要额外的记性去记。

改动的记录不用写长，写清改的是哪一条、从什么改成什么、因为什么事改，这三样就够了。最容易被人省掉的是第三样，而它恰恰是最不该省的。半年后有人问起这条为什么这么定，答案只在这句话里，没有它就只能凭印象解释，解释出来的版本和当时可能已经差得很远。

手册只有一份这个要求，在执行上经常被悄悄打破。人在处理一件紧急的事时，往往是顺手在自己手边那份文件里改了一笔，改完继续处理别的事，就忘了同步回去。可行的办法是给改动设一个入口，改了就要在那个入口登记一次，没有登记过的那一份在实际执行里不算数。

有一个很省事的检查办法：随机挑三条规则，分别问三个实际在做这件事的人，这条现在的要求是什么。三个人的回答一致，说明手册在这一层上真的在起作用。如果出现了两种以上说法，说明更新这一环有遗漏，从谁说的版本最旧往回追，一般能追到是哪一次改动没有同步出去。

手册一旦被搁置，重新用起来比第一次建还要费劲。因为这个阶段手册里的内容已经和实际做法拉开了距离，读的人翻两页就会发现跟自己做的不一样，然后判断这份文件不可靠，从此不再打开。重做的第一步不是补内容，是先找出哪几条和现在不一样，把这几条改过来，让手册重新跟上现状。

把手册的版本变动记在一处，这件事在多店场景下还有一个额外作用：能看出哪天起事情开始变得不一样了。某家店的几项指标同时在一个时间点前后发生变化，去版本记录里看那几天改过什么，往往能对上。没有这份记录，这种关联只能靠人的记性，而人的记性在忙的时候正好最不可靠。

更新这件事要有一个不依赖某个人的入口。写手册的那个人休假了，这几周出现的新情况就没人往手册里补，等他回来补的时候，好几件事的细节已经没人记得清了。可行的做法是规定出问题处理完之后，处理的那个人顺手补一条，不必等谁来汇总，也不必追求文字漂亮。

最后一点是有取舍。手册更新到一定程度，会发现有些条目随着做法变化已经不再成立，这时候要删掉而不是保留。留着过时的条目比缺一条更麻烦，因为读的人分不清哪条还能用，最后会整本都不信。删的时候在版本记录里留一句，说明这条因为什么原因撤掉了，将来有人问起也有答案。

有一个方法能让手册的更新变得毫不费力，就是在每次处理完一件事之后，把当时的处理过程三言两语记在一张便条上，攒着。到了例会之前把这几张便条过一遍，确定哪几条值得写成规则，一次写进去。这样写出来的句子带着当时的语境，也避开了事后再回想时容易丢掉细节的问题。

手册的更新还要看住一个方向：只往里加，从不往外删，用不了多久它就变成一份没人愿意读的厚文件。删的判据和加的一样，都是看它有没有对应的具体场景。原先那条规则对应的场景已经不再出现了，这条就该撤下来。撤下来的条目按时间堆在一个归档区里，不放在正文，将来要查还能查到。

多人同时改手册这件事要留出一点余地，不必要求每次改动都同步给所有人，但要让改动本身可被发现。做法是改动区按时间倒序排，最新的在最上面，谁顺手打开都能看到最近有什么变化，不必专门发通知。通知这件事本身是有成本的，成本一高，人就会选择不发，而选择的次数多了，同步这件事就名存实亡了。

时间与责任这两类写完就能用，分步流程那一行最容易落成空话

新人和老人用同一份手册的差别

老人翻手册是查，新人读手册是学，两种用法对手册的要求不一样。老人心里已经有一套做法，他翻手册是想确认自己记得对不对，所以他最关心的是这条规则还是不是现在这样。新人心里是空的，他最关心的是遇到这种情况应该找谁、做完交给谁，两拨人找的是不同的东西。

一份手册如果只照顾其中一种人，另一种人就会绕开它。只写了原则和依据的手册，老人看得懂，新人读完还是不知道该从哪一步下手。只写了分步动作的手册，新人能照着走，老人发现不了某一条其实上个月已经改过，两边都以为自己是对的。

兼顾的办法不复杂，每条规则的后面留两个小格就够用：一个写上次确认的时间，一个写这件事归谁盯。前者服务老人，让他一眼看出这条有没有被更新过；后者服务新人，让他知道拿不准的时候去问谁。两个小格的维护成本很低，省掉的是每一次交接时重复解释一遍的时间。

新人读手册的起点不是第一条，而是他当天要做的那件事。手册如果按章节顺序排，新人要找一条规则得先判断这件事大概属于哪一章，这一步对他来说是额外的负担，因为他本来就不熟悉这套业务的边界在哪。可行的做法是另外配一张索引，按你现在要做的是什么来排，指向手册里对应的条目。

老人对手册最大的需求是一条：跟上次不一样了没有。所以每条规则后面标一个上次确认的时间，他扫一眼就能判断这条要不要重读。没有这个时间，老人会从头到尾重读一遍，读完发现没什么变化，白花几分钟，几次之后他就不再看手册，改成凭记忆做事了。

两拨人对手册的期待不同，提问题的方式也不一样。新人会问这里为什么这样，老人会问这里什么时候改的。手册里如果同时留了改动的原因和上次确认的时间，这两类问题在手册内部就能被回答掉，不用每次都去找当初写它的那个人，也不会出现问了半天没人记得的情况。

交接的时候这个差别最明显。接手的人是新手，他需要的是从哪一步开始做的指引；接手的人是老手换个店，他需要的只有这家店和别人不一样的那几条。同一份手册要同时支持这两种读法，靠的是条目本身写得短、索引足够清楚，以及每条规则后面那个确认时间能让人判断需不需要重读。

为新人配的那张索引要按动作来编，不按业务模块来编。写的是今天要补货、今天要发货、今天要看退款这类当天要做的事，每条后面指向手册里的哪几条。这么编因为新人是从当天要干的活出发找规则的，他不会先想这件事属于哪个模块，再往下找。

老人那边可以少给一份东西，因为他需要的信息本来就少。给老人的部分主要是几条最容易记错的规则，加上每条后面的确认时间。把老人不需要的内容也一并推给他，反而会让他在翻找上花掉时间。同一份手册，两拨人的入口不同，读到的东西也就自然不同，不必强求一致。

有一类规则对两拨人的意义不一样，就是要停下来问人的边界条件。对新人来说这是一条安全线，知道自己什么时候该求助；对老人来说这是一条责任线，明确哪些情况必须由他来接。同一条规则同时服务两个方向，这也是它值得写在显眼位置的原因，因为它一写清楚，两个人的动作就都对上了。

还有一种情况是两拨人对同一条规则的理解本来就不一样，而且都不觉得自己错。发现这种分歧的办法很简单，让两个人在不看手册的情况下分别说出这条规则的要求，说法对不上就说明这条写得不够明确，或者实际操作里已经有了两种做法。这种分歧是手册最该优先处理的部分，因为它每一天都在产生不一致。

两拨人对手册的用法不同，还带来一个排版上的要求：条目要能短到一屏之内看完。新人读完一条转身就要去操作，条目的长度超过一屏，他读完前面已经忘了后面。老人的需求量更小，只要在条目后面看到时间就够了。把每条压短，两类人都受益，写的人花的力气主要在这一步。

手册里还可以专门留出一节写这类情况不要按手册处理。有些场合是手册覆盖不到的，比如平台临时改规则、大促期间的特殊流程，这时候照着手册做反而是错的。把这类情况明确写出来，比让人自己去判断手册什么时候失效要可靠，因为判断失效这件事需要的经验，恰好是新人还没有的那部分。

同一份手册同时服务两拨人，最关键的一点是不要在手册里假设读者已经知道什么。写的人往往不自觉地省掉自己觉得理所当然的环节，而这些省掉的恰恰是新人最缺的。有一个检查办法，把写好的条目给一个完全没做过这件事的人读一遍，看他能不能照着做出来，读的过程中卡住的地方就是被省掉的部分。

规则从事故里长出来，重复出错的次数降得比耗时更快

手册写到什么程度算够用

够用的标准不是页数，而是新人能不能只靠它把一周里的大部分例行事务处理完，遇到拿不准的知道去找谁。这条标准听起来松，实际挺严，因为多数手册做不到这一点。做不到的原因通常不是写得少，而是写的大多是结论，缺少遇到情况时的判断路径。

另一个判据是看手册的厚度还在不在涨。刚开始写的时候长得快，因为素材多、缺口大。写到某一层之后，新增的条目多数是已有条目的另一种说法，这时候再往里加只是把同一件事说了两遍。发现这个现象就可以停一停，把力气放到让已有的条目真正被用起来上。

还有一个反向的判据，是看手册里有多少条从来没被翻到过。做法很简单，给条目做上编号，出问题的时候顺手记一下是翻到第几条解决的。过两三个月回看这份记录，会发现被用到的一直是那二三十条，其余几十条基本是陪衬。陪衬太多，真正有用的那几条反而被淹没了。

写到够用之后，手册的作用会变一层。它起初是用来防错的，防住那些反复出现的老问题。写到一个程度之后，它会变成一件可以交出去的东西，别人接手的时候不需要先跟着你干半年。这一步的价值不在手册本身写得有多好，而在于里面的每一条都对应着一件真实发生过的事。

有一个很实际的停手信号：看最近一个月新增的条目里，有多大比例是在补充已经有过的条目，而不是在补新的缺口。补充的比例超过一半，说明主要的问题已经被覆盖到了，后面加进去的多半是同一件事的另一种说法。到这个程度就可以先停一停，把力气转到让已有的条目真正被用起来。

另一个信号来自新人。拿同一批问题去问一个只靠手册上手的人，再问一个干了很久的人，如果两个人的答案大体接近，说明手册这一层的覆盖已经够用了。差别还很明显的那几处，往往就是下一批该补的条目，而且这种找法比凭空想更准，因为它直接指着实际没被覆盖到的地方。

手册写到够用之后，它的用法会从查答案变成对答案。做事的人心里已经有了判断，翻手册是做一次确认，确认自己这一遍没记错。这时候手册的价值不在它写了什么新东西，而在于它让几个人对同一件事得出同一个结论，这个作用在人多起来之后才会显现出来。

还要接受手册永远写不完这件事。业务在变，新的问题会不断长出来，手册的厚度会跟着涨一点。只要它涨的速度不快于新问题出现的速度，它就一直在起作用。反过来，追求一次写完，很容易出现在一次大而全的整理之后，整本东西被放进文件夹里再也没人翻开的情况。

写到够用的手册有一个特征，就是它读起来不太像一份正式文件。里面的句子短，很多条只是一句动作，语句之间没什么过渡，看起来像随手记的清单。这个长相恰恰说明它好用的地方，因为每条都是独立可执行的，不需要靠上下文才能读懂，翻到哪一条都能直接用。

判断够用与否还有一个时间维度的办法，看这份手册在最近一段时间有没有被改过。一直在被小的修改，说明它在被使用，因为使用过程中会发现需要写清的地方。长期一动不动，有两种可能，一种是它已经足够稳，另一种是没人再看它。要区分这两种情况，问一句上个月有谁按它做过事就够了。

写到够用之后，手册能替你做的最实际的一件事，是让新来的人不用先跟着谁学半年。过去带人的方式是人跟着人，新人在旁边看着老手做，看几个月慢慢会了。有了手册，这个过程可以压缩成先读一遍、再按手册做一轮、拿不准的来问。真正需要跟着学的，只剩下那些手册里写不出来的手感部分。

最后要说的是，手册的价值不在它本身写得多完整，而在于它让标准从某个人的脑子里搬到了纸上，于是别人也能照着用。这句话反过来读更清楚：一份没有被任何人用过的完整手册，和一份只写了十条但每天都在被翻的手册，后者对一家店的帮助大得多。写完不等于完成，被用起来才算。

还有一层判断标准跟业务有关：手册能不能支撑起一次人员调整。某个人的一段时间要挪去做别的事，他手上那几家店能不能被另外一两个人接住，接的时候不用打电话问他。这个测试做一遍，手册的缺口会立刻显出来，而且是最真实的那种缺口，因为它测的不是手册写得好不好看，而是它到底能不能替代一个人的记忆。

这个测试本身也值得固定下来做。每隔一段时间安排一次小范围的换手，让甲去处理乙手上的两三件事，做完问甲卡在哪里。卡住的地方记下来往手册里补，补完下次再试。这么循环几轮之后，手册会自己长到够用的程度，而且长出来的每一条都对应着一次真实的交接，不会写空。

关于判断依据这一层，可以用外部数据来定一个参照。给某个品类定投入方向、判断某个款还值不值得继续做的时候，依据通常落在两处：一类是站点的类目结构和大致的价格分布，一类是竞品和选品信号。知虾站在这一层，看到的是多站点数据、站点分析、竞品监控与选品信号，把这些写进手册的时候，写清依据取自哪一层就够。

最后，手册写到什么程度算够用，这个问题本身没有统一答案，因为它取决于你有几家店、几个人、以及人员流动的频率。可以确定的只有一点：只要还有一件反复发生的事每次都要靠问人来解决，手册就还没写到够用。这个判据随时可以自查，不需要等做完一次完整整理，也不需要谁来评估。

常见问题（FAQ）