Shopee店群管理工具管不住的那部分：店与店之间的关系

工具管点，管不了点与点之间的关系

先把工具认得的东西列一遍。它认得店铺编号、商品资料、价格、库存、订单状态这些字段，每一项都对应一个具体的值。它按这些值判断该做什么，值对了就执行，值不对就报错。至于这些值背后代表什么，它不问。

把关系放进来试一次就明白了。你想让工具在两家店同时缺货的时候先保住甲店的库存，这件事它做不到，因为它看不到甲乙之间谁是主力。两边对它来说是格式相同的两个店铺对象，没有轻重之分。轻重只存在于你的安排里。

还有一种情形更能说明问题。两家店卖同一批货，你想让乙店只在甲店卖完之后再上，这个先后顺序工具也不认识。它认的是这件货在乙店上没上架这个状态，不认为什么现在还不能上。先后属于人的决定。

这不是工具做得不够好，而是它站的位置决定的。它站在执行这一层，执行需要的是明确的指令，不需要理解指令背后的理由。理解理由这件事留在人手上，因为它要用到的是对整盘生意的判断。

所以工具能帮你把十家店的操作拉到一个标准上，标准定得对不对它不管。标准来自关系，关系来自你对这批店的分工思路。工具放大的是执行的力度，不是这套思路本身的质量。思路歪了，它只会把歪的执行做得更快。

有一个判断办法很省事。把你想让店群做成的事一件一件写下来，逐条问一句：这件事需要同时知道两家店的情况吗。如果需要，它就是关系层面的事，工具接不了，得先由人定下来。

按这个办法过一遍，会发现落在关系层面的事比想的多。哪批货先给谁、新类目让谁去试、价格战的时候哪家跟进哪家不跟、淡季的时候哪家缩量哪家保量，每一条都跨越了两家以上的店，每一条都不在工具的判断范围内。

剩下的那些只涉及一家店的事，比如这家店的图要换、这个描述要改、这个价要调，才是工具真正发力的地方。它们在数量上占大多数，也是日常最花时间的那部分，交给工具确实划算。

看清这个分工之后，用工具的姿势就不一样了。工具负责处理只涉及一家店的事务，关系层面的事单独拿出来，固定在一段时间里集中讨论。两件事混在一起做的时候，往往是最需要判断的那部分被跳过，因为执行的动作更顺手。

判断的顺序也要摆对。先把关系层面的事定完，再让工具去执行单店层面的事。反过来先开工具，人会陷在操作里，觉得一切都在推进，但真正决定这批店往哪走的那几个问题一直没说清楚。

还有一个边界要说清楚，免得把关系这件事寄托在工具上。知虾不是店群管理工具，也不做多店管理、批量操作、订单归集、库存同步这些事。它站在看清行情这一层，给的是各站点的类目与价格信息，帮人在定关系的时候多一个外部参照。

这个位置的说明很重要，因为它划出了两条线。一条线是工具能接的执行工作，另一条线是人必须自己扛的判断工作。数据类工具明确站在后一条线的上游，给判断提供依据，但不下判断，也不替人执行。

顺着这条线看，同一件事在不同工具上的落点是不一样的。比如两家店要不要同时上这个类目，数据类工具给的是这个类目在各站点的需求量和竞争密度；至于两家都上还是一前一后，那个决定没有任何一个数据工具能替你做。

把这条线记住，选工具的时候就不容易被带跑。有些工具会说自己能管多店，听上去覆盖了更多，实际上它管的是操作，关系那一层仍然是空的。空着的那一层不解决，操作层面的效率提升会被关系层面的混乱吃掉一部分。

所以正确的用法是分两段走。先用外部信息把该定的事定下来，再让工具去执行定好之后的操作。两段都做，工具的收益才是完整的。只做后一段，等于把最需要判断的地方跳过去，只优化了执行。

工具站在第一步后面，它认识的是一份清单，不认识一份结构

店群之所以叫群是因为有关系

很多人对店群的理解停留在一个数量概念上，觉得店多了自然就是群。按这个理解，十家互不相干的店也叫店群，一家店开十个类目也算。这两种情况在实际管理上，和一个真正意义上的群是完全不同的两回事。

群这个字的重点落在关系上。同一个群里，成员之间有往来，有先后，有主次。放到店铺上，就是这批货先给谁、这个类目让谁去试、预算紧的时候谁先让。这些往来才把一堆店连成一个群，店的数量只是背景。

按这个标准回头看，很多所谓的店群其实是一堆店。它们各自照自己的节奏在跑，之间没有往来，也没有主次。每家的数据单独看还行，合起来看不出什么，因为合起来本来就没有东西可看。

这种状态在店少的时候问题不大，每家自己管自己就够了。店一多，成本就出来了。同一个坑被三家店分别踩一遍，同一个类目被两家店分别去试一遍，重复花掉的钱和时间没有人在算总账。

关系定清楚的第一个好处，是让重复的事情只做一次。一家店试过的东西另一家不必再试，一家店踩过的坑别家可以绕开。这件事的前提是店与店之间有一条通道，而这条通道只能由人来搭。

判断自己的店铺算不算一个群，有一个很直接的办法。随便挑一件事出来，看它是不是需要两家以上的店配合。比如这款货要不要同时上三家，比如这个类目要不要两家分开试两个价位。这类问题如果存在，说明店与店之间本来就有往来。往来存在而没有被写下来，它就以口头约定的形式散在各人手里，随时会被忘掉。

如果哪件事都是各家自己做自己的决定，中间不需要通气，那就是一堆店，不是一个群。这种情况下谈店群管理，谈的其实是把一堆店的操作收拢起来，管理两个字用得偏了。管理的前提是有共同的目标和相互的约束，一堆互不相干的店既没有共同目标，也不需要相互约束，收拢操作只是省事，不是管理。

反过来说，只要有两家店之间存在一条约定，这个群就开始成形了。哪怕只是最简单的一条，比如这两家不同时上同一款。一条约定就能省掉一次内部撞车，省下来的钱和时间是实际的。约定越多，这个群的轮廓越清楚，管理起来也越有依据。

约定攒到一定数量，就值得写下来。零散的约定放在各人脑子里，时间一长就散了，新人来了也不知道有这些约定。写在一起之后，这套约定本身就变成了这家店群的结构。结构这个词听起来大，落到实际上就是这些具体的约定和它们之间的先后关系。

这一步做完，工具的位置也清楚了。它执行的是这些约定落到具体操作上的那一部分，比如按约定只给某家店上某款。约定本身不在工具里，它在你的说明里，工具照着说明跑。所以工具的边界是由结构决定的，结构定得多细，工具就能替你做多细的那一段。

有一个具体的场景能说明这个区别。计划开一个新站点，手上有三家店可以选一家去试。如果这三家之间没有定义过关系，选哪家会变成一场讨论，各自都有理由，讨论完还可能反悔。

如果定义过关系，这件事几分钟就能定。测试类的店去试，这是它存在的意义；主力店不去分心，它该做的是把手上的事做扎实；备胎店留着，等这个新站点跑通之后由它去接。选择变成了照定义执行的动作。

这两种情况的差别不在决策者的水平，而在有没有一套现成的定义。有定义的时候，判断的成本被提前支付过一次，之后每次遇到同类问题都能直接取用。这是把关系写下来最实际的一笔回报。

反过来，没有定义的店群会把每一个新问题都当成第一次遇到。新类目、新站点、新价位、新玩法，每一次都要从头讨论，讨论的结论还可能和上一次不一样，因为每次的讨论起点都不同。

时间一长，这种重复的成本会比工具的费用大得多，只是它分散在每一次讨论里，不容易被看成一项成本。把它集中看一下，就能明白关系这件事值得先做。做法也很简单，把最近一段时间里重复讨论过的事情列出来，看看有几件是因为身份没定义才反复出现的。

还有一种情况会让重复的成本更高，就是参与讨论的人换过。新人不知道上一次讨论的结论，会从头再问一遍前面那些前提。前面的人已经形成默契的部分，到新人这里全部要重新对齐一次。

前四条落在工具能接的范围内，后两条落在工具完全够不到的地方

店与店的关系有哪几种

常见的分法就那么几类，叫法各家不同，实质差不多。一类是撑销量的，一类是试方向的，一类是备用接手的。还有一类专门消化库存，一类专门立门面。分清这几类，管理动作自然就分开了。

撑销量那一类店，特点是资源优先给它。新款先上它这里，预算紧的时候先保它，人手不够的时候也是先顾它。判断它跑得好不好，看的是整体趋势而不是某一款卖没卖爆，因为单款的一次波动说明不了问题。

试方向那一类店，特点是要给它一段允许失败的时间。它的价值不在自己赚多少，在于它把结论带回来。判断它跑得好不好，看的是它有没有给出清楚的结论，而不是它这个月的进账数字够不够漂亮。

备用接手那一类店最容易被忘掉。它平时不用做太多事，但状态要保持健康，评分不能掉，类目不能荒。它的意义是主力店出状况的时候能顶上去，所以平常看不出价值，出事的那一天价值才显出来。

消化库存的店和立门面的店，逻辑又不一样。前者看清货速度，越快越好，不必在意单件利润。后者看位置的稳固，宁可少上几件，也不能让这个类目看起来杂乱。判断标准不同，管理动作也跟着不同。

除了那几类常见身份，还有一种状态需要单独说，就是待定。有些店开出来之后一直没有明确定位，既不是主力也不算备胎，就那么放着。这种店多了，整盘结构会变得含糊。含糊的坏处是它占着位置和成本，却不为任何一个明确的目标做贡献，时间一长还会拖慢其他店的动作。

待定本身不是问题，长期待定才是。给待定设一个期限是有用的做法，比如几轮之内要定下来用它做什么。到了期限还没定，就按现有条件做个决定，是转测试还是收掉，不要一直挂着。挂着的成本不会显示在账面上，但它确实在发生。

身份之间也会叠加。一家店可以同时是某个类目的主力，又是另一个类目的测试店。这种叠加在小规模的店群里很常见，写说明的时候把类目写清楚就行，不必强求一家店只有一个身份。

叠加的时候要注意资源冲突。同一家店既要冲某个类目的量，又要试另一个类目的新方向，两件事抢的是同一批人手和同一份预算。写清楚哪件事优先，比把它们都记成待办要实际得多。

还有一类身份是季节性的。有的店平时是常规店，旺季的时候临时转成消化库存的店。这类身份有明确的开始和结束时间，写说明的时候把时间段标上，免得到了淡季还按旺季的配法在配资源。

除了身份本身，还有一个要一起定的东西，就是每家店当前看哪几个数。主力店看的是整体趋势和复购，测试店看的是试出来的结论，备胎店看的是状态是否健康。看的数不同，管理动作才有差别。

这一步经常被跳过，结果是所有店都看同一套指标。同一套指标下，测试店永远显得弱，因为它本来就不以销量为目标；备胎店永远显得闲，因为它的作用不在产出上。看错指标会导致对这两类店做出错误的处置。

记录方式也可以统一一下。每家店的身份、看哪几个数、什么条件下换身份，这三样写在一处就够了。不必做得很复杂，一张表或者一份短说明都能承载，关键是放在大家都看得到的地方。

表定好之后要有一个责任人。谁负责定期看这些身份还准不准，谁负责在条件触发的时候提出来改。没有责任人的时候，这张表会慢慢过期，过期的表和没有表一样，甚至会误导人按旧的身份去判断。

记录里还可以留一栏写清楚当初为什么这么定。过一段时间回头看，能看出当初的理由现在是否还成立。理由不成立而身份没动，就是需要处理的地方，这一栏能帮人很快找到它们。

关系没定清会出现什么现象

最先冒出来的现象是撞款。两家店的选品人各自看到了同一个款，各自觉得能做，于是各自上了。表面上两边都动了手，实际是把一份需求拆成了两份供给，结果两边都吃不饱，谁也跑不出量来。

第二个现象是资源被平均分。因为没有主次，各家报上来的需求看起来都合理，预算就被摊平了。摊平之后没有一家店能拿到足够的量去把一件事做成，每家的进度都卡在差一口气的那个位置上。

第三个现象是问人。新人接手一家店，不清楚这家店现在该干什么，只能去问。问来的答案还常常不一致，因为不同的人对这家店的定位本来就不一样，问三个人有可能得到三种不同的说法。

第四个现象是决策反复。同一件事这周定了这么做，下周换了个人看又改成那样。改的理由往往不是数据变了，而是参与讨论的人对这家店的身份理解不同，大家讨论的其实不是同一件事。

这四个现象放在一起看，根子是同一个。店的身份没有落到纸面上，就只存在于各人的印象里。印象之间有差异，所有需要协作的环节都会在差异上摩擦，而摩擦的成本最后都会变成时间和钱。

有一个现象很能说明问题，就是会议的数量。关系没定清的时候，同样的一件事会在不同场合被重新讨论一遍，因为每次参与的人不一样，对这件事的前提理解也不一样。讨论看起来在推进，实际在原地。这种原地打转最难察觉，因为每次讨论都有新的说法，听起来像是在往前。

这种现象有成本。反复讨论消耗的是最贵的那部分注意力，参与讨论的往往正是要拿去做判断的人。他们的时间被重复占用，真正该想清楚的那些问题就更没有空去想了。一件本来十分钟能定的事，因为前提没对齐，可以反复花掉几个人的几个小时。

第二个现象出在人身上。关系没定清的时候，做得越多的人越容易觉得自己吃了亏。他多上了一个款，别人没上，销量算在店上不算在他身上，他下一次就不会再主动多上。这个机制不需要谁去抱怨，它自己就会运转，结果是整盘的动作越来越保守。

第三个现象出在数据上。各家的口径不一致，看板拼在一起之后，有些指标是加总的，有些是平均的，有些是各自算完再报上来的。拼出来的总数看起来完整，实际每条指标背后的定义都不同。口径不同的时候，越看数据越容易得出相反的结论。

这三个现象的共同点是它们都不会自己消失。关系没定清，会议就会继续开，主动性会继续被消耗，数据口径会继续分叉。它们要等到有人把关系写下来，才会停下来。写下来这件事本身不产生收益，它产生的是让其他事情能产生收益的条件。

除了内部现象，还有一类往外冒的现象，就是同一批买家在不同店里遇到重复的内容。两家店上同一款、写同一个描述、用同一组图，买家逛到第二家的时候会有很明显的重复感。这种感受不需要对比才发现，逛的过程中就直接产生了。

这种重复感对平台侧的判断也不利。同类内容在同一个站点重复出现，被识别为低质重复的可能性更高，曝光会受影响。这件事两家店各自的负责人未必知道，因为他们各看各的，看不到两家合起来的样子。

还有一种现象是价格上互相踩。两家店卖同一批货，一家觉得要冲量所以压价，另一家觉得要保利润所以守着不降，最后的结果是低价那家把两家共有的需求吸走，高价那家的库存压着不动。

这三种往外冒的现象都有一个共同点，它们在单店视角下都是合理的动作。压价的那家在自己店里看没有任何问题，重复用图的那家也没觉得不妥。问题只在两家店的关系上，而这正是单店视角看不到的地方。

所以要发现这类问题，看数据的方式就得换一下。不是一家一家看，而是把有关系的几家放在一起看。哪些款重叠了、哪些价撞了、哪些图重了，放一起才看得出来。这一步用不着很复杂的工具，一张对照表就够。

这个关系该由谁来定

这件事只能由对整盘生意负责的人来定。判断哪家该当主力，需要知道手上还有多少预算、能拿到什么货、这段时间想把力气往哪个方向使。这些信息聚在一个位置上，判断才做得出来。

运营可以参与，但不该拍板。运营站的角度是这家店怎么跑得更好，这个角度本身没有错，但它是单店角度。把六家店各自的单店最优合起来，得到的常常不是整盘最优，有时还会互相抵消。

定关系这件事也不需要多正式。一份说明就够了，写明有哪几家店、每家现在是什么身份、这个身份对应哪些优先权、什么情况下会换。写得越具体，执行的时候争议越少，扯皮的空间也越小。

难的地方不在写，在承认取舍。定了主力就意味着其他店要往后排，定了测试就意味着这家店一段时间内不追求好看的数据。愿意把这些话说明白，这份说明才站得住，不然就只是一张纸。

定完之后要让相关的人都看到。放在某个人脑子里，等于没定。写在一处大家都看得到的地方，新人入职、临时换人、旺季调配的时候，都能少一轮解释，也少一次因为理解不同而返工。

定关系的时候有一个依据来自外部。比如打算让某家店去试一个新类目，得先知道这个类目在各站点大致是什么行情、值不值得试。知虾站在这一层，它看到的是各站点的类目结构与价格带分布，拿来判断值不值得试，不是拿来定谁去试。

还有一类信息是这个判断要用到的。打算让某家店去试一个方向，得先知道这个方向的需求大致在什么量级、同类卖家的价位集中在哪个档。这类信息可以在数据工具上找到，它看的是各站点类目的搜索量与价格带分布，拿来做参照。

拿到这类信息之后，判断的重心落到取舍上。工具给的是这一类的外部行情，至于用哪家店去试、试到什么程度算完成、试不出结果怎么收，这些仍然在定关系的人手上。两者各管一段，不重叠。

定关系的时候还有一个常被忽略的输入，就是各店现在实际在做什么。有的店名义上在卖某个类目，实际上因为几款尾货一直在清，动作已经偏了。把各店的现状盘一遍，比看当初的计划表更有用。

盘现状可以用几个简单的条目。这家店近几轮上的都是什么类目、价位集中在哪一档、有没有正在推的主推款、库存压在哪个规格上。这几条理出来，这家店实际上是什么身份，往往一眼就清楚了。

盘出来的结果和当初定的身份对不上，就是需要调的时候。对不上不一定意味着当初定错了，也可能是这家店已经漂到了别的方向上。能看到这个漂移，比坚持当初的定位更有价值。

定关系这件事也有它的边界。它不能定得太细，细到每一款归哪家店，那样会僵死，实际跑起来处处对不上。它要定的是档位和优先权，不是逐款分配。留出执行的空间，关系才用得久。

定关系的人还要负责一件事，就是在取舍的时候讲清理由。为什么这家是主力而那家是测试，为什么这个类目给这家试不给那家。理由讲清楚，执行的人遇到没覆盖到的情况才推得下去。

理由不说清楚的时候，执行层遇到新情况只能猜。猜对了没事，猜错了就要返工。返工的成本看起来是一次两次，累积起来会让整个团队对这套结构失去信心，最后又回到每件事都要问一遍的状态。

讲理由还有一个作用，就是让这套结构能被质疑。别人听懂了理由，才能指出其中不合理的地方。理由不透明的时候，结构只能靠权威维持，一旦换人或者情况变化，这套结构就撑不住了。

理由也不用写得很长，一句话能说清就行。比如这家店的职责是把试出来的款放大，那家店的职责是把新方向试出来。一句话把职责说清楚，后面遇到的具体问题大多能自己推出来。

到这里可以说清知虾的边界。它站在看清各站点品类行情这一层，看到的是类目结构与价格带分布，不给谁该当主力的答案。答案在你手上，它站在提供依据的那一层，不越到定关系这一层。

这个边界对所有数据工具都成立。数据能告诉你外面发生了什么，不能告诉你该怎么排自己的资源。把这两件事分清，用数据的时候就不会拿它去回答它回答不了的问题。分清之后还有一个附带的好处，就是选工具的时候知道该看什么，不会被那些承诺覆盖全流程的说法带偏。

只要问题涉及两家店之间的关系，属于工具的格子就基本是空的

关系定清之后工具才好用

关系定清之后，不同身份的店可以配不同的规则。主力店的商品资料要求规格编号齐全、图片完整，测试店的可以轻一点、先跑起来。规则分开了，工具照着跑，跑出来的东西才符合各店的身份。

还有一个变化是判断变快了。以前看一屏数据，得先想这家店现在该以什么为标准来衡量。现在标准是既定的，看一眼就知道这家店这一段跑得算好还是算差，不必每一次都重新对一遍基准。

排查问题也变快了。同一件事出在测试店和出在主力店，处理方式完全不同。前者可以放着看，后者要当天处理。身份写清楚了，看到店名就知道该用哪一套反应，不用再问一遍该不该管。

反过来看，关系没定清的时候，工具越强越容易掩盖问题。它能让六家店的页面看起来一样整齐，整齐之下各家的定位混乱还在，只是被表面的统一遮住了，看数据的时候不容易发现。

所以上的顺序应该是先定关系再上工具。关系定清楚了，工具装好当天就能用，因为规则是现成的，配一遍就能跑。反过来先装工具，往往要花一段时间才发现真正缺的不是工具，是一份说明。

有一个检验办法，可以看看关系定清到底有没有效果。看新人上手一家店要问多少个问题，以及这些问题里有多少是能在说明里直接找到答案的。这个数字降下来，说明关系确实定住了。

上手要问的问题通常集中在几类：这家店优先上什么、报预算的时候算哪家优先、出问题的时候谁决定、这家店的数据按什么标准算好。这几类问题如果说明里都有答案，上手时间会明显缩短。

另一个检验办法是看决策的速度。关系定清之后，同样的决策要经过的人少了，因为前提是既定的，不需要每一次都从头对齐。决策快了，业务推进的速度也就跟着上来。这个收益在旺季特别明显，那时候每一天的响应速度都直接对应到能不能吃到这波需求。

这两个检验办法的好处是它们不依赖工具，也不依赖主观感觉。问问题的数量能数出来，决策从提出到落地的间隔能记下来。前后对比一次，这套关系到底有没有用，自己心里就有数了。

还有一个容易被忽略的收益是对外的一致性。同一批货在不同店里的呈现方式一致，买家在哪个店遇到它感受都一样。这种一致靠临时对齐很难维持，靠写清楚的关系来约束就稳得多。

有一个细节值得单独提一下，就是规则定下来之后的试用方式。不要一次把六家店全切到新规则上，先拿一家跑一轮，看规则落到实际操作里有没有对不上的地方。这一轮的目的不是验证规则对不对，而是找出它在执行层面卡在哪里。

对不上的地方几乎总会有。可能是某个类目的商品资料要求太严，实际操作时凑不齐；也可能是某个优先权在旺季根本不成立，因为几家店同时在赶。这些问题只有跑起来才会显出来。

跑一轮之后再改规则，改的成本就很低。改完再放量，其他店直接按改过的版本执行。这个顺序比全量上线之后再调整要省事得多，因为全量上线之后每改一次，六家店都要跟着动一遍。

试用还有一个好处，就是能提前看清工具在这套规则下的表现。哪些规则配得进去、哪些配不进去只能靠人盯，试用一轮就清楚了。清楚之后，多出来的那部分人工盯守就能提前安排人手，不至于临时抓人。

这个顺序反过来也说明了一件事，工具好用不好用，很大程度上取决于规则给得清不清楚。规则清楚，工具跑得顺；规则含糊，工具要么跑不动，要么按含糊的规则跑出一堆需要返工的结果。

关系写成一份说明之后，重复讨论和上手耗时这两件事都会往下走

关系会随着阶段变化

一家测试店把结论拿回来之后，它的身份就该动。要么提成主力，要么转去试下一个方向，要么因为结论不成立而收掉。停在测试身份上不动，等于把一个已经完成任务的岗位继续占着资源。

主力店也会掉身份。连着几轮投入都没有起色，或者它所在的类目整体在走下坡，这时候继续按主力供资源，付出的成本换不回对应的回报。这种判断需要人主动去做，它不会自己发生。

备用店的身份最容易被忘。有些店一开始是备着的，后来主力店的状况一直不错，这家备店就长期闲着。闲置也是有成本的，房租、人力、日常维护都要花钱，只是花在明面上不容易被算进去。

关系变化要有触发条件，不能靠感觉。比如测试店拿到结论就算完成，或者试满多少轮还没结论就收；主力店连续几轮投入后增幅低于某个档位就该重新看。条件写出来，谁看都能得出同样的结论。

每隔一段时间整体过一遍也是个办法。把六家店的身份重新看一次，该提的提、该降的降、该关的关。过这一遍花不了多少时间，但能避免身份长期不动带来的资源错配。这一遍最好固定在同一批人手上，标准才不会被换人换掉，前后两次的判断才有可比性。

有一个很实际的信号可以拿来判断该不该改关系，就是看当前这套结构下，还有没有明显没人管的地方。哪件事出问题了，大家都觉得不归自己管，那就是结构上缺了一块。这种缺口在平时不会显出来，往往等到事情已经造成了损失，才被发现原来一直没人负责。

这种空白通常在两个地方出现。一个是两家店的交叉地带，两边都不认为该自己负责。另一个是新出现的事，比如刚开了新站点，谁去管这个站点还没有安排，就一直悬着。交叉地带和新事项这两处，是结构最容易漏的地方，隔一段时间专门看一遍值得。

补这些空白不需要大动结构，加一条约定就行。约定写清楚这件事归谁管、管到什么程度、需要配合的时候找谁。补上之后，下一次同样的事就不会再悬着。补空白这个动作成本很低，收益是长期的，难的是有人愿意定期去找这些空白。

除了补空白，还有一种调整是收窄。随着店群运转，有些身份已经名不副实，比如挂着备胎名头其实一直在做主力的事，或者挂着测试名头其实早就不试东西了。把名字改成实际的样子，结构才准。

改关系的频率不宜太密，改得太勤会让人记不住当前的规则。也不宜太疏，长期不改会让结构越来越偏离实际。半年左右整体过一次，中间有明确触发条件时单独处理，这个节奏大多数店群都够用。

改完之后要让相关的人都知道改了哪里，以及为什么改。只改内容不说明原因，下一次遇到类似情况，大家还会按老办法处理，改动就白做了。说明和原因放一起写，改动才落得下去。

有一个具体的例子可以说明身份变化带来的连锁反应。一家测试店试出了结果，要提成主力。它原来用的图片规格、描述深度、价格策略都是测试档的，提成主力之后这些都要跟着往上走。

如果只改身份不改这些配套的东西，会出现一种错位。身份上是主力，实际呈现出来的还是一个测试档的店。买家看到的是内容，看不到你的内部身份，错位会直接反映在转化上。这种错位的麻烦之处是它很难被归因，看数据只会看到转化不理想。

配套的调整还涉及资源。提成主力之后，它要拿的款从试的那几款扩到一个类目，预算从试错的档位提到主推的档位，人手也要跟着加。这几样不同步改，身份的变化就只是一句话。

降身份也一样。一家主力店转成备胎，原来配给它的款和预算要收回来，收的时候还要注意节奏，不能一次抽干，否则数据会有一个断崖。断崖本身不是问题，问题是没有准备，看到断崖的时候会误判成店铺出了问题。

把这些配套动作列成一张清单，跟着身份变化一起走，改动就不容易漏。清单不必长，把款、预算、人手、内容规格这四样写进去，覆盖大部分情况就够用了。清单的作用是在忙的时候当一个提醒，身份变了该动的东西一件一件对过去。

最后一点是时间。身份变化的效果不会立刻显出来，通常要经过几轮才有迹象。这个过程中的数据需要用新的标准去看，拿旧标准衡量会得出错误的结论，然后做出多余的调整。等迹象稳定下来再评估一次，比急于下结论要稳当。

常见问题（FAQ）