Shopee店群管理工具的账号与权限怎么设计

店群为什么一定会涉及多人协作

一家店的时候，几乎所有的事都由一个人来做，从看数据到写内容到处理售后，中间没有交接，也就不存在权限的问题。这个人知道所有正在发生的事，不需要向谁确认，也不需要留下什么说明。

店开到几家之后，这件事的自然解法是找人分担。分担首先出现在事务量最大的那几项上，通常先是客服回复，然后是内容写作，接着是价格跟进，最后连看数据和安排一天的事情也会有人一起参与进来。

一旦有第二个人参与，就会立刻出现一类过去不存在的问题：他需要看到什么、能改什么。这两个问题看起来简单，但它们没有默认答案。不给权限他做不了事，给多了又会牵动本来不该他碰的部分。

所以多人协作带来的不只是人手，它还带来了一道新的接口。这道接口过去不存在，因为一个人自己和自己之间不需要接口。它的成本体现在沟通和对齐上，也体现在出问题时能不能说清楚是谁做的。

判断是不是已经进入多人协作阶段，有一个很直接的办法：回看最近一周，有没有哪件事需要先和别人对齐之后才动手。有的话，说明协作已经在发生，哪怕这个人只是偶尔帮一下忙也算数。

这也是为什么店群管理的议题里，账号与权限总是绕不开的一段。它不是一件可做可不做的配置，它是多人协作自然的伴生物，早晚都要面对，早一点处理比晚一点处理要省力得多。

对齐这件事一旦出现，就意味着信息不再只装在一个人脑子里。别人要知道背景、要知道边界、要知道前面已经做到哪一步，这几样东西如果不被写下来，每一次都要重新解释一遍，解释的次数会相当可观。

第二件要做的事是把手上所有的事列出来，逐项标一下现在是谁在做。标完之后常会发现有几项没有明确的人，它靠的是临时安排或者谁顺手谁做。这几项在协作阶段最容易出问题，因为没有人认为那是自己的事。

第三件事是看有没有哪一项被两个人同时在做。重复做同一件事在店少的时候代价不大，人多了之后它会带来另一种麻烦：两个人的做法不一致，最后的结果取决于谁先做完，看起来像是随机的。

这三件事做完，协作的实际情况就清楚了：哪些事有人负责、哪些事悬着、哪些事被重复做。它们决定了权限该按什么分，也决定了哪些位置需要补人，比直接讨论权限配置更接近问题的根部。

举一个具体的例子。一位卖家手上六家店，最初自己一个人做，后来找了一个人帮忙做客服。开头两周很顺，客服知道常见问题的答法，遇到说明不清楚的地方就来问一句，两个人配合得挺自然。

第三周开始出现新的情况。客服发现有一家店的售后退款规则和其他几家不太一样，不知道该按哪一套回复，于是自己按理解处理了一次，结果那家店的买家得到了一个和规则不一致的答复。

这件事本身没有造成什么损失，处理一次也就过去了。但它暴露了一个新的问题：现在有别人在做决定了，而这个人手上的信息是不完整的。他不知道这家店的规则为什么和别人不同，也就无法判断该照哪一套。

这类问题在多了一个人之后会持续出现，因为信息分散了。过去一个人做的时候，所有背景都在他一个人脑子里，没人需要解释；现在需要把某些背景主动交出去，交不交、交多少，就成了新的议题。

所以多人协作真正的开始，不是招到第二个人那一天，而是第一次发现别人需要知道你自己脑子里的东西。这个时点之后，账号、权限、记录这几件事就从可有可无变成了需要认真处理的部分。

要减少这类误用，做法不是把信息交代得更细，而是把边界说出来。比如明确告诉他这条规则只对这一家店成立，其他几家为什么不同，这样他在遇到别的情况时会知道该来问一句。

这也是为什么权限与账号这件事总在店群议题里被反复提起。它看起来是配置问题，实质上是把原本装在一个人脑子里的那套规则，用可以传递、可以核对的方式固定下来的过程。它看起来是配置问题，实质上是把一个人脑子里的规则变成可以传递的东西。

权限的层次就是照着这几段动作分出来的

权限设计的三层结构

把权限按三层来分，比按人来分清楚得多。第一层是查看层，管的是能看到什么；第二层是执行层，管的是能做什么动作；第三层是决定层，管的是能定下什么。三层由宽到窄，责任也由轻到重。

查看层可以放得比较宽。让所有参与的人看到同样的各店数据，好处是大家讨论的时候有一份共同依据，不至于各人凭各自印象说话。这一层放开的风险很低，最多是信息多了占一点注意力。

执行层按手上的分工给。负责内容的给内容相关的动作，负责客服的给订单相关的动作，不需要每个人都能碰所有事。这一层的判断依据是这个人日常经手哪一类事，而不是他的职级或者资历。

决定层要收得比较紧，具体收哪些可以按影响面来判断。影响一家的、随时能回滚的，放在执行层就够；影响几家店的、回滚要花时间的，放到决定层；影响整个结构安排的，收在一个人手上。

三层分开之后，权限讨论就不再是给不给的问题，而变成这件事属于哪一层的问题。这个转换让讨论有了依据，也避免了每次都要重新争论一遍谁该有什么，讨论的成本会明显下降。

三层之外还有一种更细的分法，就是按店铺来分。同样是执行层的人，可以只给其中几家店的权限，而不是所有店。这种做法在人数多、店铺角色差别大的时候比较有用，能避免一个人经手自己不熟悉的店。

实际用起来多数是两种结合：执行层按职能分，决定层按店铺或者按整盘分。这样执行的时候每个人都有明确的范围，做决定的时候又能把几家店的同类信息放在一起看，不至于只盯着自己那一块。

按店分有一个前提，就是店铺的角色已经定清楚了。哪几家是主力、哪几家在试、哪几家在收尾，这些定下来之后，把人对应到店上才有依据。角色没定的时候按店分，容易分得随意，过一阵还得重来。

另一种分法是按职能分，一个人只管内容，一个人只管客服，一个人只管价格。这种分法在执行层很顺，因为职能清楚、边界明确；但在决定层会遇到问题，因为决定往往需要跨职能的信息才能做。

分法不是越细越好。分得越细，权限表越长，维护成本越高，而且出现跨范围的事情时要来回协调。比较合适的粒度是分完之后，一个人能说清自己手上的范围，遇到边界的事情知道该找谁。

举一个三层落地的例子。一家卖家有六家店、三个人参与。负责内容的那个人拿到的是全部六家店的查看权限，加上内容相关的执行权限；负责客服的那个人是全部查看权限，加上订单相关的执行权限。

价格调整、对外发布和分配店铺这几类放在负责人一个人手上。他不需要亲自做每一次调整，而是把调整的口径写出来，让经手的人按口径执行，遇到口径之外的情况再来找他确认一下。

这个安排跑起来之后，日常动作没有被挡住，因为内容与客服各自在自己的范围内可以直接动手；同时风险大的几类也没有散出去，价位和对外发布不会因为某个人临时起意而改变。

还有一项容易被忽略的安排，就是负责人要保留查看全部记录的能力。这个权限他自己用不上几次，但一旦出现争议，能快速看出是哪个环节发生了改动，比把所有人都叫来对一遍高效得多。

分层还有一个实际的好处，就是它让新来的人知道自己的位置。他不需要摸索自己能碰什么不能碰什么，看一眼分层就知道自己在哪一层、边界在哪，上手的时间会明显缩短。新来的人看一眼分层就知道边界在哪，试错的时间会明显缩短。

执行层的划分要考虑动作之间的连带。有的动作看起来独立，实际上一动就会牵动另一处，比如改价之后活动设置也要跟着调。这类动作如果是两个人分别负责，就要在中间留一个确认的动作。

决定层收在少数人手上，并不意味着这几个人要做得很多。更合理的状态是他们定口径、定边界，把大部分按口径就能完成的动作交给执行层，自己只在口径之外的情形上出现。他们定口径、定边界，日常的按口径执行就够了。

这套分法在实际使用中会有一个调整期。开头分的层级往往不完全贴合实际，跑一两个月之后会遇到几次分不清归属的情况，把这些情况记下来调整一次，之后基本就稳了。调整一次之后，这套分层基本就稳下来了。

数值越高表示权限可以放得越宽，越低表示越要收紧

谁能看、谁能改、谁能发

谁能看这一层最容易处理，但有一项常被漏掉，就是看操作记录。多数人只给看数据的权限，忘了给看记录的权限，结果出了问题只能靠几个人互相回忆，而回忆往往是不完整的，拼不出完整的过程。

看这一层里还有一点值得单独说，就是看数据的范围要不要按店分。有人觉得数据都看过一遍没什么坏处，实际上数据太多会挤压判断的时间。给一个人看全部数据，等于让他每天从一大堆数字里筛自己需要的。

谁能改这一层的关键是把改动按影响面分级。改一条描述、换一张主图这类影响面小的，给经手的人就行；改一批价、调一场活动这类影响几家店的，要收在少数人手上，改之前有一步确认的动作。

谁能发这一层最容易被忽略，因为发布这件事看起来只是操作。但发布是这家店对外说话的那一刻，内容写错了、价位挂错了，外面看到的就是这个结果，所以它天然应该比内部的改动更严一些。

这三层之外还有一层隐藏的权限，就是分配权限本身。谁可以给新来的人开权限、谁可以收回权限，这件事如果没人明确负责，权限表会慢慢变得臃肿，很多已经不在岗的人的权限还留在上面。

四件事都定下负责人之后，这套安排才算完整。完整的标志不是权限分得多细，而是随便问一个人他手上有什么、谁给的、什么时候收，都能答得上来，答不上来说明这套东西还没有真正落地。

改这一层有一个常见的模糊地带，就是商品信息的修改。改一条描述看起来影响很小，但它属于对外说话的部分；改库存看起来影响大，其实谁也看不到。所以按字段类型分比按动作大小分更准。至于某个品要不要换，看的是竞品与选品信号，知虾给出的正是这一层依据，它不参与具体的改动。

更实用的做法是按各自的职责给数据范围，负责内容的重点看点击和内容相关的数，负责客服的重点看订单与售后。这样每个人看到的量少了，看的时候也更清楚自己该关注哪一段的变化。

发这一层建议不要和改混在同一批权限里。发出去的内容是外面看到的结果，改错了还能再改一次，发出去之后往往已经有人看过甚至下过单。这两件事的影响阶段不同，权限也该分开来处理。

四件事都定完之后，还有一件收尾的工作，就是把定下来的安排写在一处，让参与的人都能看到。写下来的意义在于它不依赖谁来解释，新来的人自己看一遍就能知道边界在哪里，不用问人。

举一个改的层级的例子。一家店在做一个活动，需要把几件商品的价位调低一档。这件事看起来只是改几个数字，但它涉及对外展示的价格，也会影响到其他店要不要跟着调整，属于要收住的那一类。

同一时间还有另一件改动，就是把某个商品的描述里一处错别字改掉。这件事影响面很小，改错了再改回来也就是一分钟的事，给经手的人直接做完全没有问题，不需要事先问过谁。

这两件事的区别不在动作的复杂度，而在影响面。改错别字的影响停留在这一条内容上，改价位的影响会扩散到几天之内的单量和别家的相对位置，扩散范围决定了它属于哪一层权限。

看得太多还有一个副作用，就是注意力被分散之后，该注意到的变化反而不容易注意到。数据范围收窄之后，同样的时间能看得更细，出现异常的时候也更容易被立刻发现。数据范围收窄之后，同样的时间能看得更细。要让范围分得准，先得知道各站点的品类行情在哪，知虾看到的是各站点的类目结构与价格带分布，这一层材料能帮看的人确定该重点关注哪一段。

发这一层如果要设审批，建议只设一步。曾见过一些团队把发布设成三步审批，结果是每次都要等，最后大家都把发布攒到一起做，反而更容易在集中发布的时候出错。把发布攒到一起做，反而更容易在集中发布的时候出错。

一个更实用的做法是把发布和改动绑在一起看。改动通过了、确认无误，发布就该跟着完成，中间不要留太多等待的余地。这样既有确认，也不会因为等待太久而出现内容与实际不符的情况。

分完之后还要考虑一件事，就是这个分法要不要让所有人都知道。建议是让参与的人都看到完整的分层，即使某几层的权限和他无关，知道整体结构之后，他做起事来会更清楚自己该找谁。

账号共用是最常见的坑

账号共用之所以常见，是因为它在短期里确实省事。新来一个人直接给他现有的账号和密码，省掉了开通和配置的步骤，当天就能开始做事。这个便利是真实的，所以很难靠讲道理让人改掉它。

它真正贵的地方在出事之后。几个人用同一个账号，系统的记录上只会留下一个名称，改动是谁做的看不出来。这时候能依靠的只剩下当事人的回忆，而当事人往往也是从别处拼凑出来的印象。

追不出改动来源这件事的代价不会立刻显现，它往往在某一次价格被改乱、或者某一段内容被改得不对的时候集中出现。找不到原因就只能整体回退，把这一段时间内所有人都做过的事一并撤掉。

整体回退的代价除了工作量的重复，还有对参与者的影响。做事的人会发现自己认真做的部分也被一并撤掉了，而原因并不是他做错了什么。这种经历会让愿意主动做事的人变得谨慎起来。

要判断自己有没有掉进这个坑，可以做一个很小的检查：现在如果要回答上一周某一条商品的价格是谁改的，能不能在几分钟内答出来。答不出来，说明记录和账号之间的对应关系是断掉的。

所以账号共用的账要连着看：短期省下的是开通的时间，长期多出的是排查、回退和沟通的成本。这几个成本都不是一次性的，它们会随着人数增加而变得更容易发生，也更容易变大。

改起来其实不难，第一步不是去开账号，而是先把现在有几个人在用、分别在做什么列出来。这一步不清楚，开了账号也不知道该怎么配，配完了还是会出现几个人共用一个账号的情况。

第二步是把共享的那个账号的用途定义一个边界。常见的做法是把它降级成一个只用来查看的位置，或者直接停用，改动全部走各自的账号。这样做的代价是每个人要先熟悉自己的入口，多花一点时间。

第三步是把所有人都过一遍，确认每个人都有自己能用的入口。这一步最容易漏掉偶尔参与的人，比如一周帮忙回几次消息的那种。这类人不在正式名单里，但他们的改动同样会出现在记录上。

三步做完之后，短期内的效率会下降一点，因为每个人都要重新试一遍。这段适应期不长，撑过去之后就基本回到原来的节奏，而记录和人员的对应关系从此是清楚的，后面出问题的排查会容易很多。

举一个追查的例子。一家店某个商品的价位被改低了，发现的时候已经卖出去一批。要弄清楚是谁改的、什么时候改的，第一步是查记录，但记录上显示的是共用的那个账号名称，看不出具体的人。

接下来能做的只有逐个去问。问了一圈，每个人都说印象里好像没改过，或者记得当时改的是别的东西。最后能确定的范围只有一个大致的时间段，以及那段时间里有哪些人在做事。

处理方式只能是把这个时间段内所有的价格改动一起回退，其中包括几条本来改得没错的。回退之后要重新核对一遍所有被影响的商品，这个工作量比当初改价本身大出许多，还容易再出错。

这件事带来的问题是工作分配的依据失真。负责人以为某个人还在承担一部分事情，实际上那部分已经由别人在做，而这种错觉往往要到某件重要的事情被漏掉之后才会被发现。负责人以为有人在承担，实际那部分已经由别人在做。

从排查的角度看，共用账号还有一个问题，就是它让改动的影响范围无法限定。如果某一次改动造成了问题，不知道是谁做的，也就不知道这个人平时还碰过哪些别的地方。不知道是谁做的，也就不知道他还碰过别的地方。

分开账号之后这类情况会清楚很多。每个人的动手范围明确，出问题的时候能立刻把范围收窄到一个人几个动作上，处理的效率完全不同，也不至于把无关的工作一起推翻。出问题能立刻把范围收窄到一个人几个动作上。

要说共用账号还有什么留着的理由，大概只剩下极端临时的场景，比如某个人休假几天需要有人顶一下。这种临时安排可以用一个明确的临时入口，用完就收，不必长期共用。这种临时安排用一个临时入口就够，用完就收。

操作留痕为什么比想象中重要

操作留痕最直接的作用是还原。一件事过去了几天甚至几周，当时为什么这么改、改之前有没有先说过，这些问题靠人的记忆很难答准，而记录上的时间点和内容能把过程拼回一个大致的样子。

它的第二个作用是让讨论有依据。几个人对一件事的看法不一致时，翻记录看看当时是怎么定的，比各自回忆要快，也少了一层情绪。记录提供的是一个中性的参照，不偏任何一方。

第三个作用和交接有关。接手的人最想知道的是这家店最近被改过什么、为什么改，有一份记录他就能自己看，不需要把前任或者同事拉着问上一两个小时，交接的时间会明显缩短。

留痕这件事有一个很实际的门槛，就是记录要能被看懂。一份只写了时间和字段名的记录，有用但有限；如果记录里同时能看出改前和改后的值，排查的时候就不用再去问人当时改成什么样了。

这三个作用有一个共同点，就是它都在事情不顺利的时候才显出价值。顺利的时候没有人会去看记录，所以留痕这件事很容易被当成多余的步骤，等到需要的时候才发现前面没有留下。

要让它真的留下，做法不是要求每个人更认真，而是把记录做成默认发生的。比如改动通过同一条路径完成，记录自然生成，不需要额外填一行。默认发生的记录才可能长期存在下去。

第三个门槛是有人会去看。记录留下来了但从来没有人翻，等于没有。做法可以是在某几类事情上定一个习惯动作，比如每次改动影响到几家店之后，顺手看一眼记录确认范围，看多了就自然养成。

过了这三道门槛，记录才算真的能用。它也才可能在需要的时候派上用场，因为排查问题的时间窗口很短，等到想起来去找记录再发现记录不全，往往已经错过了最容易处理的阶段。

留痕还有一个附带的好处，就是它让做事的人更愿意留下依据。知道改动会被记下来，人自然会在做之前多看一眼、多想一句，这个习惯本身就会减少一部分失误，这部分收益不好量化但确实存在。

举一个和交接有关的例子。一家店换了负责内容的人，新人接手时最想知道的是过去这段时间内容改过什么、为什么改。如果没有记录，他只能靠问人，而问到的往往是结论，缺了原因这一层。

有记录就不同。翻一翻改动的时间和内容，能看出这家店最近在往哪个方向调，标题的口径变过几次，描述的侧重从哪一条换到了另一条。新人看完之后，接手的方向就比较清楚了。

记录还有一个作用是可以和外部材料对上。内容改动的方向往往和市场上的变化有关，比如某个词的热度上来了、某个价位段的竞争变密了。改动的时间点和这些变化放在一起看，能还原当时的判断。

要看市场的这些变化，用的材料是各站点的行情与关键词的走势，知虾看到的是各站点的类目结构、价格带分布与关键词搜索指数，这一层信息能让记录里的改动与外部变化对得上位置。

减少这种阻力的办法是让记录尽量自动生成，把需要人工填的部分压到最少。改动的内容、时间、经手人是可以自动带上的，人只需要在必要的时候补一句原因，负担就轻多了。人只需在必要的时候补一句原因，负担就轻多了。

还有一个细节是记录放在哪里。分散在各处的记录等于没有记录，因为排查的时候要一个一个找。集中放在一处，哪怕只是一个共同的表格，用起来的效果也完全不同。集中放在一处，哪怕只是一个共同的表格，用起来也完全不同。

记录集中之后，它还能被用来看趋势。一段时间里改动集中在哪几家店、哪一类字段，这些分布能反映平时的重心在哪里，也能看出某些店是不是被冷落了很久。也能看出某些店是不是被冷落了很久。

这些用途都不是留痕的本意，但它们是在留痕已经发生之后自然出现的。也正因为如此，留痕这件事的价值往往比当初设想的要大，前提是它先被老老实实地做下来。前提是它先被老老实实地做下来。

共用那一列里，防得住的只有效率

权限与效率怎么平衡

权限收得太紧，最先出现的是动作变慢。每一次改动都要先问一遍、等一句同意，经手的人会慢慢形成一种习惯：能不改就不改。这种习惯本身没有任何恶意，它是被流程成本塑造出来的。

权限放得太宽，问题会以另一种样子出现。改动很快，但没有人知道是谁改的，哪一次改动造成了哪一段结果也追不上。这两种状态在感受上完全不同，一个让人觉得憋屈，一个让人觉得顺畅，代价都藏在后面。

平衡的做法是按改动的影响面分档，而不是按对某个人的信任程度分档。影响面小、随时能回滚的，放；影响几家店、回滚要花时间的，收在少数人手上；影响整个安排的，收在一个人手上。

分完档之后，判断就变成了一件很快的事。遇到一个改动，先看它属于哪一档，属于哪一档就走哪一档的流程，不需要临事讨论。规则的作用就在于把反复出现的判断提前解决掉。规则的作用是把反复出现的判断提前解决掉。

这个分法还有一个好处，它不依赖对个人的评价，所以在被收权限的时候，人不容易觉得是针对自己。规则越客观，执行的时候越少一层解释的工作，也越容易长期维持下去。规则越客观，执行时越少一层解释的工作。

分档之后建议把每一档的具体内容写下来，一张简单的表就够：第一列写什么样的事情，第二列写由谁动手，第三列写要不要先跟谁说一声。写下来之后，日常遇到事情就不用每次讨论了。

这张表刚开始难免有遗漏，用上一两个月会遇到表上没有的情况。遇到的时候不要临时决定就算了，把它记下来，然后补进表里。补几次之后，这张表基本能覆盖日常绝大多数情形。

写表的时候有一个值得注意的地方，就是别把审批写成流程。流程意味着每一步都要走一遍，而很多改动其实不需要那么多步。更轻的做法是事前说一声，说完就做，出问题的时候有据可查就够。

轻重之间的区别在感受上很明显。事前说一声不会打断手上的活，走审批则要先放下手上的事情去等。日常动作的频次很高，每多一步步骤，累积起来的时间成本都会相当可观。每多一步步骤，累积起来的时间成本都相当可观。

所以分档的目标不是把权限管住，而是让日常动作尽量不被挡住，同时把风险大的几类确实收住。这个目标想清楚之后，具体怎么分就有了方向，也不容易在上面加越来越多没必要的步骤。

举一个收得太紧的实际场景。一家店的做法是任何改动都要先问负责人，包括改一条错别字、换一张主图。开头大家还照做，过了一个月，改动静悄悄地变少了，很多小问题就一直挂着没人处理。

没有人是有意偷懒。只是每次改之前先要等一句同意，等的成本比改本身还高，久而久之，经手的人形成了能不改就不改的习惯。这种习惯看起来不影响什么，但店里的细节会慢慢变差。

另一家店的做法相反，所有人都能改所有东西。开头很顺，改什么都快；三个月之后负责人发现有几件商品的价格和描述在某段时间被改过好几次，每次是谁改的、为什么改都说不清楚。

两家店的对比说明一件事，就是分档这件事不能省。不收不放也做不到，收得太紧会让人不敢动手，放得太宽会让改动没有来源，两头的代价都不轻，中间的解法就是按影响面分档。

活动期收权限听起来会让效率下降，但它换来的是一段高风险时期里的稳定。做法不需要很复杂，活动期间把调价的权限临时收到一个人手上，活动结束再放开，中间的说明写清楚就行。

临时收权限要和参与的人说清楚，包括为什么收、什么时候放开。不说清楚的话，经手的人容易把它理解成不信任，本来是一件风险控制的事，结果变成了需要解释的误会。不说清楚，经手的人容易把它理解成不信任。

说清楚之后，这类调整就不会积累情绪。人在知道边界和期限的情况下，配合起来是自然的；不知道的时候，每一次被收权限都会被当成一次评价，成本就高了。不知道的时候，每一次被收权限都会被当成一次评价。

记录补齐之后，两件事的耗时都往下走，且不容易反弹

人员变动时权限怎么交接

人员变动这件事有一个特点，就是它的时点往往不是完全可控的。提出离职到实际离开之间的这段时间不长，如果权限清单是临时整理的，很容易漏掉几项，而漏掉的那几项通常是最不常用的那几个。

更稳的做法是把清单做成一份需要定期更新的东西。每个人手上握着哪些店的哪些权限、能改什么、能对外发什么，这些内容在有变动的时候就更新一次，不等到离职才整理，整理的时候就不会太赶。

交接的时候要分两个方向做。一个是收，把离开的人手上的权限逐项回收，确认没有遗留的常用入口；另一个是交，把这些权限对应的工作接到接手的人身上，并且当面确认接手的人知道有哪些。

只收不交会留下一个更隐蔽的问题，就是工作看起来有人在做，实际上没有人明确负责。这类情况在过渡期不会暴露，等到某件事拖了很久才被发现，那时候追究起来也说不清是谁的责任。

举一个交接出问题的例子。一位兼职帮忙的人离开时，大家只想到了他手上的客服权限，把它回收了。几个月之后发现有一家店的商品信息被改过，改动来自一个当初还留着的入口。

这件事的麻烦不在于损失，而在于期间没有人知道那个入口还在。它一直没有被使用，所以没有触发任何提示；一旦被使用，也会因为人员已经离开而没人认领，处理起来要多绕几道弯。

还有一类变动不是离职，而是换岗。换岗的人还在，只是做的事情变了，这时候权限也要跟着调整。只加不减是最容易出现的状态，时间一长，每个人手上都握着一堆已经用不上的权限。

把清单做出来之后，建议指定一个人负责它。这个人不需要是负责人，只需要是一个会定期看一眼的人，比如每季度确认一次清单上的人还在不在、手上的权限还有没有在用得上。每季度确认一次清单上的人还在不在、权限还有没有在用。

定期确认这件事的价值在于它把交接从一个突发事件变成了一件例行的事。临时整理清单的时候人会紧张、容易漏；例行确认的时候每次只改一两项，出错的概率低得多，也不会有额外的压力。

交接的时候还有一个容易忽略的方向，就是把这个人的经验交接出去。他手上可能有几条没人知道的判断习惯，比如某个字段在这一类商品上要单独调、某个店的活动节奏和别人不一样。

这些经验不在权限清单里，也不会写在任何一份文档上，但它对接着做的人很有价值。交接时留出一段时间专门聊这些，比只交接账号密码管用得多，也能减少接手之后走弯路的次数。

最后一步是把交接这件事留一个记录，写清交接了哪些权限、从谁到谁、什么时候完成。这份记录不是为了追责，而是为了在一段时间之后回头看，还能知道当时的安排是什么样子。

要避免遗留入口这类情况，做法是把入口和权限分成两层来管。入口是能不能进来的问题，权限是进来之后能做什么的问题。回收的时候两层都要看一遍，只收一层会留下能进却看不出用途的位置。

另一个实用的做法是把常见的操作路径也列进来。一个入口能做的事往往不止这个入口名字所示的那一件，比如商品信息入口通常还能改价格和上下架状态。按路径过一遍，比按入口名字过一遍更不容易漏。

交的部分还要多一步确认。把权限交给接手的人之后，建议让接手的人实际走一遍最常见的几件事，确认自己确实能进得去、能做得成，而不是只看一遍权限列表就够了。确认自己确实能进得去、能做得成，而不是只看一遍清单。

这一步确认花的时间不多，但它能避免一种常见情况：权限看起来都交接了，接手的人实际操作时发现有一处进不去，于是又回头找已经离开的人帮忙，反而更慢也更乱。免得又回头找已经离开的人帮忙，反而更慢也更乱。

整个过程做完之后，把登记更新一次，把离开的人划掉、把接手的人添上。表单上的人员和实际参与的人保持一致，这套安排才算真的被维护起来了。表单上的人员和实际参与的人保持一致，这套安排才算被维护起来。

常见问题（FAQ）