Shopee店群管理工具和订单归集：多店订单怎么不打架

多店订单混在一起的代价

第一层代价是切换成本。每一个后台都要登录、找位置、看清状态，处理完一家再切到下一家。这个成本看起来不大，但一天里可能重复几十次，尤其是订单量上来之后，切换的次数几乎是跟着订单量一起涨的。

第二层代价是记录的重复。同一笔货在不同的店里卖出，发货记录要在两处分别登记，退回来的货要在两处分别核销。手工做这件事的时候，两边记得不一样是常事，而对不上之后要花的时间比记两遍还多。

第三层代价是遗漏。几家店的订单分散看，某一家里有一笔快到发货时限的单子很容易被漏掉，因为它不在你当下正在看的那一家里。遗漏的代价往往在买家投诉或者平台提示之后才显形。

第四层代价是判断失真。订单分散的时候，你对整体情况的感知是拼出来的，不是看出来的。今天处理了多少单、还有多少待发、哪家的售后压着，这些都要在脑子里拼，拼出来的图往往不准。

有一种情况最能说明这些代价叠加的效果。某个店群在做活动，几家店同时在出单，人把注意力放在出单最多的那一家上，结果另一家的几笔单子过了发货时限才被想起。这类事故的发生机制并不是谁不负责，而是分散的结构让注意力天然偏向热闹的地方。

有一个可以立刻验证的办法。今天处理订单的时候，随手记一下从打开一个后台到处理完一单，中间做过哪些动作。记上一天会发现，单笔的处理时间并不长，长的是那些在后台之间来回找、来回切的部分。

这部分时间之所以不容易被察觉，是因为它分散在很多次很短的停顿里。每次停顿几秒钟，一天停下来几十次，加起来就是一个不小的量。它不会出现在任何一份统计里，只会让人感觉一天下来很忙却说不出忙在哪。

记录的价值就在这里。把切换和重复记录这两类时间单独记出来，才能看清代价到底有多大。很多时候看清之后会发现，光是减少切换这一项，就足够支撑归集前期的工作量了。记录的时间不必长，连续记上一周，量级就已经能看出来了。

还有一个连带的损失是人对整体状态的判断力。订单分散的时候，被问到还有多少待发的时候，多数人的回答是一个大概的范围，而不是一个确切的数。判断建立在估算上，决策自然也跟着含糊。

这个损失在平时不显形，在忙的时候显形。忙的时候订单多、注意力紧，判断的偏差会被放大，本该先处理的那几笔被放在了后面。忙中出错的机制，往往就在这一层。把这两类情形分开记，能看出哪些错是状态造成的，哪些是流程造成的。

有一个边界条件要说清楚。上面这些代价在店少的时候并不明显，一家两家店的时候，切换的成本可以忽略，人也能靠记忆把所有订单装在脑子里。所以判断这些代价有没有发生，看的不是店的数量，是有没有出现记不住、对不上、漏掉这三种情况。

记录方法上可以做一个很简单的动作，连续三天记录每天出现的三类情况：有没有一笔订单过了时限才被发现，有没有两处记录对不上，有没有需要重复登记同一件事。三天就足够看出趋势，不必记很久。

还有一种代价容易被算漏，就是人的心理负担。订单分散的时候，人会带着一种没处理完的感觉下班，因为他并不能确认所有店的状态。这种负担不体现在工时上，但它会影响第二天开始工作时的状态。

分散处理还会拖慢协作。两个人分头看不同的店，需要沟通的时候要说清是在哪一家、哪一笔，沟通成本比坐在一处看同一屏要高。人多了之后，这部分成本会累积得很快。把沟通的载体固定下来，比如固定一处在说这件事，能省下不少来回。

所以代价这件事不能只按工时算。它既有看得见的时间，也有看不见的漏掉和反复，还有协作里的摩擦。归集之所以值钱，是因为它同时压住了这三类，而压住看不见的那两类往往收益更大。

订单分散还会让人看不清各店卖的东西到底有没有重叠。几家店如果卖的是同一类目里很近的款，订单层面的混乱往往只是表面，下面其实是选品重叠。判断某个店的品要不要换，看的是竞品与选品信号这类信息，知虾在这一层能看到同类的销量与上新节奏，至于订单怎么归集，它不参与。

订单归集真正难的不是把单据放到一起，是归属怎么定

订单归集要解决的三件事

第一件事是让订单能被统一看见。不管订单从哪家店来，进到同一处之后，今天的待发、待处理售后、异常单，这几个数都能一眼看到。这一层解决的是遗漏问题。这一层不需要很复杂，能把几个数放在一处并且不遗漏就已经达到目的。

第二件事是让待办能浮出来。订单本身是被动的记录，待办是主动的提醒。哪几笔快到时限、哪几笔买家已经催过、哪几笔卡在物流，这些要按紧急程度排在上面，而不是等人一单一单翻。

第三件事是把归属说清楚。这一件最容易被跳过，也最容易留下后患。一笔订单成本记在哪家、一单退货由谁处理、一个纠纷谁出面，这三件事要在归集之前定好，而不是出事之后临时商量。

三件事的顺序不能颠倒。先看得见，才能浮待办；待办浮出来之后，归属的模糊才会被反复碰到。如果先定归属再考虑怎么看，会在还没看清问题的时候就先花大量时间定规则，效率很低。

归集做得好不好，有一个很直接的检验办法。让它跑一段时间之后，问一句：这段时间里有没有出现两家店对同一笔订单重复处理的情况，有没有出现一笔订单两边都以为对方在处理。有，说明归属那一层还没定清。

举一个具体的例子。某店群有四家店，归集之前每天下班前都要分别登录四次核对待发。偶尔出现两家店的同一笔货被重复发货，处理起来要翻两边的记录，还要跟买家解释一次。这两类问题一个来自效率，一个来自规则，处理的办法也不一样。

归集之后的第一周，最明显的变化是下班前的核对从四次变成一次。第二周开始出现一个新问题，就是有一笔退货在两家店之间来回推，因为没人知道该由谁来对接。这个问题在归集之前不存在，因为那时候两家的售后本来就是分开的。

这件事说明归集把原本分开的流程放到了一起，也把原本不会碰面的模糊地带暴露了出来。暴露本身是好事，但要提前有个准备，就是归集之后的一段时间里，类似的归属问题会集中出现。

处理的办法是给这段时间留出一个明确的机制。每天或者每两天花十几分钟把当天遇到的归属问题过一遍，能当场定的就补进规则，不能定的单独记下来找时间统一解决。这个机制只在前几周需要，规则稳定之后就可以停。

还有一个细节是规则的可见性。补进去的规则要让所有经手的人都能看到，而不是只存在补规则的那个人的记录里。看不见的规则在执行时会被各人按自己的理解走回原来的样子。规则放在大家都会经过的位置，比放在某个人的记录里管用得多。

记录方式上，把这个阶段的归属问题做成一份清单，标出日期、情形、临时处理方式、最终规则。这份清单跑完一两个月，就是一套贴合自己店铺实际情况的规则，比照搬别人的流程要实用得多。

有一个容易被忽略的细节，就是归集之后哪些信息要保留各店的差异。订单的基本字段可以统一，但各店的时效承诺、售后话术、运费规则这些要保留下来。统一得过头会让各店失去它原本的灵活性。

判断哪些该保留，可以问一句：这一项的统一会不会影响对买家的承诺。会影响就保留差异，不会影响就可以统一。这个标准比逐项讨论要快得多。按这个标准筛一遍，真正需要保留差异的往往只有三四项。

待办的排序规则也值得细想。按剩余时间排是一种，按买家催促次数排是一种，按金额排是一种。不同的排序方式会把人的注意力引向不同的方向，选哪一种取决于这个店群当下最怕什么。

归属这一层还有一种是跨阶段的。一笔订单的归属在发货阶段和在售后阶段可能是不同的人，因为这两段涉及的技能和资源不一样。把两个阶段的归属分别定下来，比笼统地定一个订单负责人更实用。

记录方式上，把这三件事各自的完成标准写下来。看得见的标准是什么、待办浮出来的标准是什么、归属清楚的标准是什么。写成可检验的形式，才好在跑一段时间之后回头判断有没有做到。

越靠近物的环节越容易统一，越靠近责的环节越要先说清

发货时效的跨店差异

差异的第一个来源是各店自己的承诺。有的店在商品页上写了更短的发货时限，有的店按平台默认。这些承诺是对买家做出的，归集不能把它们拉平，拉平等于单方面改了承诺。归集要做的不是改承诺，是把承诺摆出来让人按各自的承诺去处理。

第二个来源是发货的实际条件不同。同一批货在同一个仓，各店的出货速度可以做到一致；如果货分散在不同的地方，各店的时效天然就有差别。归集能统一的是提醒的口径，不是物理上的速度。

第三个来源是物流渠道。各店谈好的承运方可能不同，同样距离的时效差别不小。归集把订单放到一处之后，这些差别不会消失，只会变得看得更清楚。看得更清楚本身就是价值，因为它让不合理的差异浮出来了。

第四个来源是各店所处的阶段。新店为了积累评价往往会更快发货，老店可能已经稳定在一个节奏上。归集如果把所有店按同一个标准提醒，新店会觉得催促无意义，老店会觉得被过度提醒。

处理办法是按店保留时效标准，归集只负责按各自的标准提醒。同时留一栏记录实际发出的时间，用来观察哪些店的承诺和实际差得远。这一栏的作用不是考核，是把不合理的承诺找出来调整。

有一个处理时效差异的具体做法。在归集后的订单列表里，除了给每笔订单标上它所属店铺的时限，再标一个剩余时间。剩余时间这一栏能打破店铺之间的差别，让人按紧急程度而不是按店铺来安排工作。

这个做法的关键在于两条信息同时存在。只看店铺会带着对店铺的既有印象，只看剩余时间会忘记时效标准本身不同。两条一起看，安排起来才既不漏也不误。两条信息缺一条，安排工作时都会出现偏向。

还有一层是提醒的时机。提醒太早会变成噪音，提醒太晚就失去了作用。合理的做法是按剩余时间设两个节点，一个提前提醒准备，一个临近提醒处理。节点定在哪，取决于这个店群实际的处理速度。

差异还可能随时间变化。某个店换了承运方，时效会变；某个店扩了品类，出货复杂度会变。归集的时候把这些变化记录下来，才不会用一套过时的时效去提醒。时效这件事属于会过期的信息，定期回看比一次定死要稳。

有一种情况需要特别留意，就是时效的差异被买家感知到。同一批货从两家店买，到达时间差很多，买家会在评价里提到。这类评价对其中一家的影响是不公平的，但它确实存在，值得在调时效时作为一个参考。

还有一个具体的处理办法，是把时效差异变成一次梳理的机会。归集之后，各店的时效标准摆在一起，哪些是真实条件造成的、哪些只是历史习惯留下来的，一眼就能看出来。梳理出来的结果要写下来，不然下一次调整又要重新讨论一遍。

历史习惯造成的差异建议慢慢收拢。收拢的办法不是一次拉平，而是先选一家标准最合理的作为参照，让其他家在下一轮调整时向它靠。这个过程的节奏要慢，因为买家的预期也是慢慢形成的。

条件造成的差异要如实保留。一个仓和一个仓之间的物理距离不同，时效本来就该不同。硬要拉平的结果是要么承诺做不到，要么另一家被迫放慢。这两种结果都不好。把每一条差异的原因写下来，后来接手的人就不会误以为是不一致。

时效还和商品结构有关。同样的店，卖标准品的发货快，卖需要定制的慢。同一家店里不同的品类时效也可能不同，归集的时候如果只按店铺设时效，会遇到不适用的情况。遇到这种情况，时效就按品类设，而不是按店铺设。

有一个边际情况要考虑，就是节假日和特殊情况。这段时间的时效普遍会变慢，归集时要能把这段时间单独标出来，不按平时的标准去衡量。这段时间的记录要单独存，不要和正常期的数据混在一起算。

记录方式上，把每周或每月的实际发货时长和承诺时长放在一起看。差得越远，说明承诺需要调整；差得很近甚至更好，说明还有向上承诺的空间。这两条曲线放在一张图上，偏差的方向和幅度都很直观。

库存共享与超卖的关系

超卖的机制很直接。同一个库存数被两家店同时参考，两家各接到一笔订单，都认为库里有货。等到发货的时候才发现只有一件。这个问题的根源不在归集，而在共享的那个数没有留余量。

留余量的做法有两种。一种是按比例留，比如按可用量的一个百分比对外展示；另一种是按固定量留，比如始终留几件不出。哪种合适取决于这个款的出货速度和补货的确定性。两种方式也可以叠用，走货特别快的款用固定量兜底，其余按比例留。

还有一种更细的处理是给不同的店分配不同的余量。走货快的店留多一点，走货慢的店留少一点。这个分配不是固定的，要跟着各店近期的出货节奏调。这个差别最好写在同一个位置，避免有人按老习惯去改。

共享库存还会带来一个副作用，就是某个款在一家店卖爆之后，其他店的页面还挂着同样的库存，买家下单后要等。这种情况比直接超卖好一点，但买家的等待体验会受影响。把这个款单独标出来，补货的时候优先补它，等待的时间能缩短。

把共享和独立分开看会更清楚。常用的、走货快的款适合独立备货，各店各留各的，互不牵扯；长尾的、走货慢的款适合共享，因为压货成本高。这个分法比一刀切要实用。按这个分法走一遍，多数店群的库存压力会明显下降。

库存数据以哪一处为准，这件事要在归集之前定死。常见的选择是以实际仓为准，页面上的数字由它推出去。定死之后，所有关于库存的争议都回到这一个源头上解决。定死之后要写下来，口头约定的规定在忙起来的时候会被绕过。

举一个具体的例子。某店在两家店同时卖同一批货，库存五十件。共享库存之后，两家店各卖出一些，一段时间之后总销量超过了五十件，多出的部分只能等补货再发。买的早的那几位等的时间最长，评价也最差。

这家店的调整是给这个款留了百分之十的余量，两边展示的库存加起来不超过四十五件。超卖的情况基本压住了，代价是有几件货到最后是当尾货清掉的。这个代价比处理超卖的代价小得多，是划算的。

这个例子里有一个判断点，就是余量留多少。留太少压不住超卖，留太多会造成积压。这个数不是一次定死的，它随款的出货速度和补货周期变化，走货越快、补货越慢，余量就要留得越多。

还有一个细节是余量的可见性。谁在什么时候调整了余量，要留痕。不然出现超卖的时候，会先花时间争论余量是不是被人动过，而不是去处理已经发生的问题。留痕的方式可以很简单，改动的日期、人、幅度三栏就够。

边界条件上还要考虑促销。做活动的时候出货速度会突然变快，平时的余量在活动期间可能不够。活动之前临时把余量调高，活动结束再调回去，这个动作要有明确的负责人，不然会有人以为别人会调。

记录方式上，把每次超卖的发生时间、涉及的商品、当时的库存设置记下来。攒几次之后能看出来，超卖主要发生在活动期间还是平时，是余量不足还是数据本身滞后。这几栏凑起来，超卖的原因基本能定位到是设置问题还是节奏问题。

还有一个更根本的处理思路，就是把共享的范围缩小。不是所有款都共享，只把那些压货成本高、走货慢的款放在共享池里；走货快的款干脆各店独立备货，各留各的。范围缩小之后，共享池这件事本身的管理成本也会跟着降。

这个思路的依据是，走货快的款本身补货就频繁，独立备货的周转速度足够快，没必要共享；走货慢的款压货的代价高，共享能明显降低总库存。按这个标准分一遍，多数店群的共享池会比一开始设的小很多。

还有一种做法是共享库存但错开上架时间。同一批货在两家店不同时上，一家先上卖一段时间，剩下的再上另一家。这样两家不会在同一时间争同一批货，超卖的概率大幅下降。错开的间隔不必很长，能避开同一批买家的下单高峰就够。

共享带来的另一个问题是对账。两家店卖同一批货，成本要按什么方式分摊到两家，这个规则要在共享之前定。不定的话，到月底算两家的单店盈亏时会发现怎么分都不公平。不定分摊规则的话，两家的账都会算得偏高或者偏低。

分摊的做法可以很朴素，比如按各店实际的销售件数分。简单的方式比复杂的方式更容易坚持，也更容易在争议的时候讲清。越简单的方式越经得起时间，也越不容易在争议时被推翻。

记录方式上，把每个共享款的超卖次数记下来。如果某个款反复超卖，说明它的销售节奏已经超出共享设计的承受范围，该转成独立备货了。积累几次之后，哪些款不适合共享会有很清楚的答案。

决定哪些款进共享池、哪些款独立备货，还要看这类货在各站点行情里处什么位置。知虾看到的是各站点的类目结构与商品数据，它站在行情这一层，给的是这个款值不值得多押的判断依据，具体留多少余量仍由你自己定。

订单归集与售后归属怎么定

按订单来源定归属是最常见也最稳的做法。哪家店卖出去的，售后就由那家店的负责人对接。这样做的好处是责任清晰，买家那边看到的信息也一致。这种做法还有一个好处，就是买家的沟通对象前后一致。

碰到同一批货从不同店卖出的情况，归属会变得模糊。这时候要补一条规则，比如退回的货进哪个仓就由哪个仓对应的人跟进。这条规则的目的是让归属有一个客观依据，而不是靠商量。

退款的额度也需要定。多少金额以下的可以直接批，多少以上要往上确认。这个额度按店定还是按人定，取决于各店的客单价水平。额度定得太紧，小事也要等人，处理速度会掉。额度可以随季节或者活动期调整，调整的时候要同步通知经手的人。

纠纷出面的人要先定。有些纠纷需要以店铺名义处理，有些可以让仓库或者客服直接对接。谁出面的问题不解决，出了纠纷会先花时间讨论谁去，而不是讨论怎么解决。出面的人不必是最高的那一位，但要是能当场给结论的那一位。

归属规则还有一个时间维度。归集刚做起来的时候，规则可以定得粗一点，跑一段时间之后再细化。一开始就定得很细，往往定的是想象中的问题，实际遇到的问题可能完全不同。规则粗一点没关系，关键是要有，要在能用得上的状态。

规则定完要写下来并且让所有人看到。留在口头上的规则在事情不急的时候能用，一旦出事，参与的人会各自按自己的理解来处理，最后还是回到扯皮上。写下来的规则还要有人维护，过期的规则不清理会变成干扰。

有一个具体的争执场景值得预先想清楚。同一批货从两家店卖出，买家在同一时间提出退货，货退回同一个地址。两家店的负责人都在等对方处理，货在仓库里停了两天。预先想清楚这类场景，比在真发生的时候临时协调要省力得多。

如果事先定好了「货进谁的仓由谁跟进」这条规则，这个场景就不会发生。规则的形态可以很简单，一句话写在共享的位置上，但它解决的是一个具体的、通常会出现的场景。这条规则的价值不在规则本身，在于它把讨论的成本提前消掉了。

规则的另一层作用是避免重复处理。两家店如果都以为对方在处理，可能出现两边都联系买家的情况，买家收到两次沟通会觉得混乱。这条比不处理更伤体验，因为它让人感觉这家店内部没有协调。

处理速度也和归属有关。归属清楚的时候，一笔售后从提出到收口的路径是固定的；归属不清楚的时候，每一步都要先确认谁来做，确认的过程本身就要花时间。想把这段确认时间省掉，靠的就是规则写得够具体。

还有一层是纠纷的升级路径。什么情况下由一线处理，什么情况下要往上报，报给谁。这条路径在平静的时候用不上，在真出事的时候决定了处理的速度和结果。升级路径往往是事后才想起来的，但它确实每天都可能被用到。

记录方式上，把每次出现的归属争议写下来，写清当时的情形和最后怎么定的。这类记录是规则修订最直接的依据，比凭空想规则要准得多。写下来之后，同类争议第二次出现时就有现成的答案可以用了。

有一个细节是关于买家侧的。买家在一家店下单，售后也在这家店处理，这是最清晰的形态。但如果买家同时从两家店买了东西，又一起提出售后，归属就要靠规则来切，不能让买家自己去分辨。

处理这类情形的办法是内部先切清再由一个人对外。对外只用一个身份，买家看到的是一条清晰的沟通线。内部怎么分是店铺自己的事，不该变成买家的负担。内部的切分规则不需要对外解释，但必须让内部的人都知道。

归属规则还要考虑人员变动。负责某家店的人离职了，他手上的售后归属要交接清楚，避免出现无人跟进的情况。这一步常被忽略，因为交接往往关注的是正在进行的事，而不是规则本身。

有一种归属约定的方式是按品类而不是按店铺。如果这个店群是按品类划分人手的，那么某类商品的售后不论来自哪家店，都由这个人负责。这种方式在品类差异大的店群里更顺。按什么分要看实际的分工，规则和分工不一致时，规则会慢慢失去作用。

按店还是按品类，取决于这个店群实际的分工方式。规则要跟着分工走，两者不一致的时候，规则会在实际执行中被慢慢绕过。分工一旦调整，归属方式也要跟着调，两件事要一起想。

记录方式上，把归属规则和人员对应表放在同一处。人员变动的时候只改对应关系，规则本身不动。这样的结构在人员调整频繁的店群里特别省事。对应表更新的时候顺手看一下规则还合不合适，一次改动完成两件事。

归集能定的是流程，定不了的是责任落在谁头上

归集之后的对账怎么做

对账要做的第一件事是统一口径。同一个费用在哪家店里怎么记，算法要一样。不统一的时候，两边的数字怎么对都对不上，而且说不清是谁错。口径写在明面上，对账的时候就不必先花时间确认两边在说什么。

第二件事是定对账的周期。日对、周对、月对各有适用场景。订单量大的时候日对能及时发现问题，量小的时候周对或者月对更省事。周期定下来之后保持稳定，频繁改周期会让数据失去连续性。

第三件事是定差异的处理方式。对账总会有对不上的地方，小额差异是直接调整还是逐笔追查，要有一个门槛。没有门槛的时候，人会在几分钱的差异上花掉一整个下午。门槛定下来之后，人对小额差异就不会再犹豫，处理速度会明显快起来。

第四件事是留痕。每次对账的差异和处理方式都记下来，积累一段时间之后，能看出差异集中在哪一类费用上。这类规律比单次的差异更有价值，因为它能指向流程上的问题。留痕还有一个作用，就是换人接手的时候能看出账是怎么走的。

对账还有一层作用常被低估，就是它能反过来检验归属规则。如果某个费用反复出现归属争议，说明当初定规则的时候漏掉了这一类情形，规则该补上。把这类争议记下来，规则会在几次修订之后变得相当贴合实际。

有一个实际的做法值得借鉴，就是把对账和归属放在一起来做。对账时发现归属有问题的，当场记录下来作为规则修订的依据，不必单独开一次会讨论。两件事放在一起，各自要解决的问题反而更容易看清。

举一个具体的例子。某店群归集之后第一个月对账，发现两家的快递费用加不起来。查下来发现一家把快递费算进了成本，另一家算在单独的费用里。两边的总额都对，但分摊到单笔订单上差得远。

统一口径之后，这家店把费用项重新排了一遍，明确哪些进成本、哪些单列。重排之后不光对账顺了，单店的成本核算也清楚了不少。这是归集带来的一个附带好处。重排之后要留一份说明，写清每一项为什么放在这里。

这个例子里还有一点值得注意，就是口径统一之后历史数据要重新理解。之前按两种算法记的数据，不能直接拿来和新数据做趋势比较。要么把历史数据按新口径重算一遍，要么在图上把口径变更点标出来。

对账的周期还要和处理人员的节奏配合。如果对账周期和实际记账周期不一样，每次对账都会碰到周期错位的问题。周期定得一致，对账就成了一件例行的小事。周期错位的时候，每次对账都会有一截数据处在半路上。

还有一个实用的做法是建一个小额调整池。对不上的小额差异先进这里，月底统一处理。这样既不会漏掉，也不会让日常对账被零碎的差异拖住。池子里的差异每月复盘一次，能看出小额差异主要来自哪一段流程。

记录方式上，把每次口径调整的原因和时间记在同一个位置。口径变更比数据本身更需要留痕，因为它是解释数据为什么变了的关键信息。口径变更的记录比数据本身更需要留着，它是解释数据的关键。

还有一个更省事的做法，是把对账的口径和看板的口径统一起来。同一套算法既用于对账也用于看板，两边的数字就不会打架。分开维护两套算法，等于给自己埋了一个长期的对不上。

对账的责任人也要明确。如果对账由多人分担，每个人只对自己那部分负责，跨店的部分就容易漏。指定一个人统筹，其他人提供数据，这样的结构最不容易出错。统筹的人还要负责把差异的原因往上反馈，不然同样的问题会反复出现。

对账的频率还和资金压力有关。资金紧的时候，现金流的变化更需要及时掌握，对账的周期可以短一些；资金宽松的时候，按正常周期走就行。周期可以随情况调整，但口径不能随意改。

有一个细节是退货和退款的时间差造成的对不上。退货从提出到入库有一段在途时间，这段时间的账面上是挂着的。对账的时候要把这部分单独标出来，不要当成差异去追。把在途的这部分单独列出来，对账的时候就不会反复去追同一个数。

对账之外还建议做一次定期的完整核对。把各家店的订单量和实际发出的件数对一遍，这个动作能发现一些日常对账发现不了的问题。这种核对不必频繁，一个季度一次就足够发现系统性的偏差。

记录方式上，把每次对账发现的差异按类型分类。分上几次之后，差异会集中到少数几类上，那几类对应的流程就是该优化的地方。分类的方式要固定，换来换去的话前后几期就没法放在一起看了。

对账的时候如果发现某几类货的利润一直很薄，问题可能不在账上，而在定价。知虾看到的是各站点的价格带分布与关键词对应的需求冷热，它站在定价判断这一层，成本口径怎么统一、费用怎么分摊，它不做也不该由它来做。

归属写清之后，处理速度的提升来自不再需要临时商量

到什么规模才需要订单归集

规模的第一层判断看订单量。一天几笔的时候不需要，人记得住。到了每天几十笔并且在几家店之间分散，靠记忆就不可靠了。这个门槛不是固定的，它和处理订单的人有多少也有关系。

第二层判断看的是同一批货跨店销售的情况。如果几家店卖的是同一批货，那订单就必须放在一起看，不然超卖和重复发货会反复出现。这种情况下的归集需求比单纯的订单量更迫切。

第三层判断看售后。售后分散在几家店处理的时候，同一类问题会被不同的人用不同的方式答复，买家的体验不一致。到了这个阶段，归集的需求就不仅是效率问题，还包括一致性。

有一种情况不必急着做归集，就是各店之间几乎没有关联。各自卖各自的货、各自发各自的货、各自处理各自的售后。这种情况下归集带来的收益有限，反而会增加一层协调成本。这种情况下更值得做的是把各店的账放在一起看，而不是把操作放到一起。

还有一种情况要提前做，就是准备开店的时候。如果新开的店和老店会卖同一批货，最好在开店之前就把订单和库存的处理方式想清楚，而不是等出问题之后再补。开店之前想清楚，比开了之后再改要省下不少调整成本。

判断的时候可以用一个很实际的问题。现在这套做法，如果订单量翻一倍，还能不能撑住。撑得住就先不动，撑不住就说明现在已经在临界点上，只是还没到爆发点。这个问题问出来，多数人心里其实已经有答案了。

有一个很具体的判断依据。如果现在每天花在订单上的时间里面，有一半以上是花在切换和重复记录上，说明已经到了该归集的时候。这个比例比单看订单量更能说明问题，因为它直接对应着归集能省下的部分。

另一个依据是有没有出现跨店的相关问题。超卖、重复发货、售后推诿，这三类问题只要出现过一次，基本可以判断这批店的订单已经到了需要放在一起看的时候。出现过的次数也要记，一次和反复出现代表的问题程度完全不同。

反过来也有一个不该做的信号。如果这几家店的订单放在一起看之后，你发现几乎不需要做任何比较或者协调，只是单纯地把它们堆在一屏上，那说明归集带来的只是方便，收益有限。

归集的投入主要在前期的规则梳理上，这部分投入是固定的。规模小的时候，这部分投入摊到每天的收益上显得很贵；规模一大，它就摊得很薄了。判断值不值得，看的其实是这个摊薄的过程走到了哪一步。

有一个过渡做法可以先试。不做完整的归集，只把待办和异常这两件事放到一处，订单的详细处理仍然留在各家后台里。这种做法投入小，能先验证归属规则定得对不对，跑顺了再往下做。

记录方式上，归集之前先记一段时间现状。每天花在订单上的总时间、其中切换占多少、出现过几次跨店问题。这些数据是判断该不该做的直接依据，也是做完之后衡量效果的基线。

有一个很实际的判断方式，就是看有没有出现无法回答的问题。比如被问到手上这批货还剩多少、今天还有几单没发、某个买家催的那一单到哪了，如果这几个问题你答不上来或者要翻很久，说明现状已经撑不住了。

还有一个判断角度是店铺的关联程度。几家店如果是同一批人管、同一批货卖、走同一个仓，那它们本来就该放在一起处理，分散反而是一种人为的复杂化。关联程度高的店不归集，等于每天人为地给自己制造一次重复。

反过来，如果几家店在人员、货源、仓库上都是分开的，只是因为属于同一个店主而被放在一起讨论，那归集的意义就不大。这种情况下好的做法是各管各的，只在上层看整体的账。

归集这件事还有一个不可逆性。做完之后，各店的操作会越来越像，独立性会下降。如果将来打算把某家店卖掉或者交给别人独立经营，归集做过的那部分可能需要拆开，这个成本要提前想到。

有一种渐进的做法是按功能分步归集。先把库存归集，跑稳了再把订单归集，最后才是售后和成本。每一步都跑稳再走下一步，出问题的时候容易定位是哪一步带来的。分步走还有一个好处，就是每一步都能停下来评估，不必一次押上全部。

记录方式上，把每一步归集前后的几个关键数字都记下来：处理订单的时间、跨店问题的次数、对账的耗时。这几个数字在每一步之后的变化，是判断下一步该不该走的直接依据。这几个数放在一起看，下一步该不该走会有很清楚的判断。

常见问题（FAQ）