Shopee 六国站点一起开的时候，账号怎么分组才不乱

六国站点一起开，最先乱的通常不是销量，是后台：泰国站的运营在马来店后台点了发货，菲律宾站收到的却是马来收款账户的验证提醒，新人接手时对着十来个账号不知道哪个能改价。

这类事故的根源不是没分组，而是分组维度互相打架——按国家分、按店型分、按人分，任意两套都会覆盖第三套。

先把结论放前面：Shopee 马来、泰国、越南、菲律宾、印尼、新加坡六国站点同时开的时候，先别按国家分组，先确认每个账号背后的控制变量是否一致。控制变量一致的一组账号才是同一组，「国家」只是其中一个变量。

六国站点一起开，先别急着按国家分组

MY 组、TH 组、VN 组这种切法，在「一人管一国、一国一店」的阶段完全够用，因为国家刚好等于控制变量。问题出现在同一国家内部开始分层的时候：泰国有跨境店也有本土店，本土店还可能挂在两张不同执照下，履约仓和收款主体都不一样。

这时「泰国组」这个标签会把这些差异盖住。同一个组里的账号注册主体不同、收款账户不同、发货仓不同，但因为在同一张分组表上，日常操作就会默认它们可以互换——共用一套浏览器环境、共用一组子账号、共用一份客服话术。

平台判断多个账号是否属于同一主体时，看的不是单一信号，而是网络出口、设备与浏览器指纹、身份与支付信息、行为轨迹这几层变量的重合度（拆解见平台判断几个账号是同一人的时候，通常看哪些维度）。按国家分组只对齐了站点字段，其余几层仍是散的，真被要求补充验证时，你也说不清是哪一层先重合。

先判断你在哪个阶段，再决定主分组轴

分组不是越细越好，团队规模不同，主分组轴就该不同。先在下表里找到自己那一行。

判断标准只有一个：如果两组账号可以被同一个人用同一个浏览器窗口先后登录而没人觉得奇怪，说明它们还没真正分开，分组只停在表格上。

用「运营单元」做主分组轴，再挂站点、店型、履约和收款

运营单元指的是控制变量一致的一组账号：同一注册主体、同一收款归口、同一履约方式、同一套环境配置、同一负责人。它衡量的是风险半径，不是文件夹层级——一个运营单元可能是 1 家店，也可能是同一执照下泰国的 2–3 家本土店。

确定单元之后，站点、店型、履约仓、收款账户、子账号、ERP 绑定这些字段全部挂在单元下面，而不是平行分组。这样做的价值在于：任何一次调整都只动一个层级，新人入职只需要知道自己在哪个单元，不需要背六国站点的全部差异。

需要提醒的是，本土店和跨境店的差别不在后台按钮，而在主体、履约、资金和多店环境这条链路上（Shopee 本土店和跨境店，运营上的九个差别）。把它们放进同一个单元，等于把两条链路的变量混在一起，分组表后面怎么维护都会出错。

六国站点直接套用的分组表：4 类运营单元怎么放

下面这张表是按「控制变量一致」排出来的常见形态，可以按自己的实际执照和收款情况增减行，但列的判断逻辑不要改。

表里最重要的是最后一列。分组乱，通常不是分得不够细，而是有人为了省事把「不能混」的账号塞进同一组。本土店矩阵的账号隔离顺序、选品与合规流程可以配合Shopee 本土店矩阵与 Lazada 多店铺的账号隔离实操一起对照，但隔离顺序不能反过来迁就分组习惯。

跨境店和本土店混营时，分组顺序按这四步走

1. 先按收款主体分。钱归谁，是平台与收款机构交叉比对的锚点，也是多店被归到同一控制人的第一层线索（原因见几个店铺共用一个收款账户，会发生什么）。收款主体不同的账号，无论站点是否相同，都不能进同一单元。
2. 再按履约方式分。本土仓发货、3PL 代发和跨境 SLS 是三条不同的链路，时效承诺、退货地址、客服话术都不一样。同一单元内履约方式必须统一，否则一个退货地址填错就是两个站点的事故。
3. 再按站点和店型分。到这一步才轮到国家和跨境／本土标签。前两步已经保证了单元内部的资金和货是一致的，国家只用来给单元起名。
4. 最后按运营人员权限分。人是最容易变的一层，放在最后。谁负责哪个单元，用子账号授权表达，而不是把账号密码和环境一起交出去。

顺序不能颠倒。先按人分，一次调岗就会把两个收款主体塞进同一套环境；先按国家分，一个「泰国」里会同时出现本土店和跨境店，后面每一步都要打补丁。

一个运营单元对应一整套配置：独立浏览器环境、代理出口、子账号权限、收款账户和 ERP 绑定

分组之后，环境、子账号和收款要落到同一张映射表

分组只要停留在表格里，最多三天就会失效。真正让分组生效的，是每个运营单元都对应一整套配置，并且这套配置能被核对。

具体要落的是五项：独立浏览器 Profile（店铺指纹、Cookie 与登录态互不共用）、绑定到该 Profile 的代理出口（同一单元可以共用出口，不同单元不要混用）、该单元的子账号权限范围、收款账户与提现链路、ERP 或打单系统的店铺绑定。五项里任何一项跨了单元，这一组就不算干净。

把这张映射表放在团队都能看到的地方，新店上线时先填表再开店，比事后排查省事得多。运营离职或调岗时，按店铺账号交接与权限交接清单的顺序冻结入口，映射表就是最直接的核对依据。

交接时先核对固定字段，再交负责人和后缀；固定字段一改就等于换组

命名规则：让新人一眼看懂账号属于哪组

命名只需要表达四件事：站点、店型、单元号、负责人。常用模板是 站点_店型_单元号_序号_负责人，例如 TH_LOC_U03_02_Lin 表示泰国本土店、第 3 单元、该单元第 2 家店、负责人 Lin；跨境店把店型换成 CB 即可。

必须固定的字段是站点代码、店型代码和单元号，这三个决定归属，改了就等于换组，必须同步映射表。可以变动的只有负责人和后缀。序号只在同一单元内递增，不要跨单元连续编号，否则扩店时序号会互相插队。

交接卡是命名的补充，用来记录写不进名字的部分：店铺 ID、注册主体、收款账户、履约方式、浏览器 Profile 名、代理出口、子账号列表、ERP 绑定、最后变更日期。交接时逐项过一遍，任何一项对不上就先停下来，不要靠「应该是这个」继续操作。

三个最容易把分组搞乱的边界条件

• 多店共用收款账户。如果两家店必须共用一个收款主体，就把它们按同一个运营单元处理，别再拆成两组；确实想拆开，先拆收款链路，再改分组表。
• 跨组临时调人。让临时接手的运营用子账号进入目标单元，不要把自己的账号密码、Profile 或代理给出去。人走了权限还在，是最难查的一类串组。
• 扩站时直接塞进旧环境。新开新加坡站或加一家越南本土店，先建独立 Profile 和出口，再首次登录。已经用旧环境登过的账号，不要靠「以后注意」补救，直接按新单元重配一轮并记录变更日期。

常见问题

六国站点能不能放在同一个浏览器里用不同标签页开？

能不能开和该不该开是两件事。同一个人先后登录不同单元的账号，会让登录态、Cookie 和本地存储在同一个环境里累积，出问题时无法判断是哪一层先重合。跨单元一律换 Profile，哪怕只是看一眼后台。

一个运营同时负责泰国和越南，分组要按人拆开吗？

不需要。分组按控制变量走，人负责几个单元就配几个单元的权限，切换时换环境。按人分组会把人员变动直接变成账号重组，成本远高于多配一套 Profile。

子账号可以跨运营单元共用吗？

不建议。子账号是登录入口，也是操作轨迹的归属标记。一个子账号同时挂在两个单元下，两个单元的行为轨迹就会交叉，后续很难分清某次改价、改库存是谁做的。

新开新加坡站，应该归到哪个单元？

先看收款主体和履约方式，而不是看它和哪个国家「比较像」。走跨境链路、收款与原跨境主体一致，就并入单元 A 并在命名里加 SG；如果是独立主体或独立收款，单独建单元。

分组表和映射表多久更新一次？

按事件更新，不按时间更新：新店上线、收款账户变更、负责人变更、履约仓切换、扩站换环境，这五类事件发生当天就改。日常巡检只核对命名与映射表是否一致，不要顺手改结构。