做希音多店铺矩阵的朋友，应该经历过：A 店铺有个品卖得不错，顺手就在 B 店、C 店也上了。品是同一个品，供应商也是同一家，但各个店铺的发货是分开处理的——每家店各自预约取件、各自承担运费。
咱们算一下就知道：假设 3 个店铺同一批货交给同一个供应商代发，分别发货的话，每张运单各算一次首重，本来一批货走一趟物流就够了，首重却按店铺数量重复计了。
这就导致我们的运费成本会非常高，本来现在利润空间就越来越薄。 好怀念之前备货运费，全部由平台承担的那段时光了。
希音后台其实有个"多店铺合并发货"的功能，很多朋友可能还没用过，这个功能刚出来的时候，我看了一眼规则，觉得好复杂，就没管。后来因为备货运费越来越高，不得已就去研究了一下。今天咱们把这件事拆清楚。
在这之前我们得先搞清楚一件事：多店铺合并发货，合并的不是包裹，是运费结算。
平台不支持把不同店铺的订单合到同一张发货单上，每个店铺仍然各自创建发货单、各自打包、各自贴面单。真正被"合并"的，是符合条件后的运费计算方式。
后台也明确列出了 5 个条件，必须同时满足，系统才会把不同店铺的运单合并计算运费——哪怕只差一项也不行。
第一，同一个商群。 商群就是咱们在后台把几个店铺，绑定在一起建立的合并发货关系。如果几个店铺还没有建立这个关系，系统不会把它们的运单放在一起计算。
第二，相同取件日期，且实际上门取件时间一致。 光是同一天取件还不够，具体的上门取件时间也要对得上。咱们在给不同店铺预约取件的时候，需要确认日期和时间都完全一致，不能一个约上午、一个约下午。
第三，相同物流公司。 各店铺运单必须使用同一家物流公司，不同物流公司之间无法合单。
第四，相同寄收信息，优先使用共享地址。 各店铺的发货地址和收件信息必须完全一致——这个"完全一致"包括标点符号和空格。一个地址用了中文逗号、另一个用了英文逗号，系统就会判定为不同地址，合单直接失败。
这个后台有"共享地址"功能，建议大家把各店铺的发货信息统一设置为同一个共享地址。
第五，急采单只能跟急采单合单，备货单只能跟备货单合单结算。 需要注意一个地区例外：广东地区的朋友，急采单与备货单之间可以合单结算；但这条只适用于广东，其他地区不能照搬。
大家在操作之前，可以先拿一组准备发货的订单，按这 5 项逐条对照一遍。全部满足之后，系统会自动判断合单，不需要咱们手动触发。
这套流程得按照一定的顺序操作，否则即便条件都满足，但最后运费还不会减少。
合理的操作顺序如下，大家可以直接参照着来：
第一步，建立多店铺合并发货关系。 先到后台检查各店铺之间，有没有已建立的合并发货关系。如果还没有，在发货管理相关页面找到入口，把需要合单的店铺先关联起来。
第二步，统一共享发货地址。 把各个店铺同一个品的发货信息，都设置成同一个共享地址。地址不统一，第四项条件直接过不了。
第三步，选择店铺和订单，分别打包。 发货时选好要操作的店铺，确认这批订单的取件时间、物流公司、发货地址一致，然后各店铺分别创建发货单、分别打包、分别贴面单。
这里有个误区，提醒大家一声：合单合的是运费结算，不是把不同店的货装进同一个包裹。
第四步，签收后查看预合单号。 运单签收 3 天后，到「补扣款列表」里查看有没有出现预合单号。有预合单号，说明系统已经把这批运单合并计算运费了。如果没有出现，回头逐项对照上面 5 项条件，看是哪一项没有满足。
分摊规则。 合单之后，总运费按各店铺运单的计费重量占比，分摊到我们对应店铺的运单上。
打个比方：比如A 店运单计费重量占总重量的 60%，B 店占 40%，那总运费就按 6:4 各自承担。
如果我们某个店铺在新商免运费期间，或者有优质商家的运费权益，这些优惠是在分摊之后、按各店铺自己的权益再计算的。
减免只作用于这个店铺分摊到的那部分，不是合单后的运费就会全部减免。
现在平台发展到这个阶段，想要拿到更大的结果，做矩阵店铺是必不可少的。
但想要做好矩阵店铺也并不简单：
首先，我们得有一套 SOP 流程，清晰地知道在什么节点该做什么事项。比如：在上架后的前 10 天、上架后的前 28 天等等；
其次，我们得知道如何分配运营好多个店铺，要会相互借势。
另外，随着店铺越来越多，需要盯的数据、操作的事项必然也会越来越多，很容易顾头顾不了尾。这时候，合理利用工具，或者借助 AI 全方面提效，就会变得尤为关键。
这也是 2026 年往后，我们做好希音的关键和破局点所在。如果还是纯靠人力、纯靠手动的话，必然会在未来越来越激烈的竞争中慢慢离场。
我是可行，一名前产品经理+程序员，多个SHEIN希音店铺实战中。我从希音全托的核心，高效选品&运营技巧，到具体落地执行的SOP，运用AI、Agent智能体、skill、工作流、自己开发的脚本、插件提效实践，梳理成《2026 希音全托管破局指南》文档，有需要的朋友可以给我留言。