跨境团队的分级权限怎么设计：谁该看到什么？

运营离职两周后，主管才发现后台还有三个子账号能登录，其中一个在凌晨改过两次收款绑定；另一个团队，店长同时握着店铺设置和提现权限，一次误操作把两家店的回款提进了同一张卡。

这类事故的根因通常不是“人不可靠”，而是权限表只回答了“给他什么角色”，没回答“他能看到什么、能改什么、能把钱挪到哪里”。多店、多平台、多主体的结构会把这个问题放大：同一个“运营主管”职级，A 可能在管三家跨境店，B 却在管一家泰国本土店的收款主体。按职级切权限，等于按职级切风险。

下面按风险半径重做一次权限设计：先分清三层权限，再分角色，最后用店铺分组把平台子账号、ERP、浏览器环境和资金权限对齐到同一张矩阵。

先拆权限的三层：看见、操作、转移

把权限笼统写成“管理员 / 运营 / 客服”，订不出边界。先按“能造成什么损失”拆成三层：

• 数据可见层：订单明细、客户联系方式与地址、真实成本与毛利、广告消耗与投产比、供应商与采购价。这一层主要造成信息外泄和议价能力损失，不会直接动钱。
• 操作执行层：上架与改价、发货与改地址、退款与补发、优惠券与活动报名、客服回复。损失有单次上限但会累积，一个错误折扣能吃掉一家店整月的毛利。
• 转移与主体层：收款账户绑定与变更、提现与付款、税务与法人资料、店铺主体与授权、广告付款方式。这一层没有损失上限，而且平台侧留痕追溯的是主体，不是操作人。

三层的授予顺序和直觉相反：数据可见可以放宽到岗位需要，操作执行按店铺组收窄，转移与主体层永远保持最小集合并加复核。多数团队出问题，都是因为第三层被顺手发给了第二层的人。

按风险半径分角色，不按职级分角色

“主管看全部、运营看自己店”在多店团队里会立刻失效，因为风险半径跟职级无关，跟这个角色能碰到什么有关。同一个职级的人，可能一个只改标题，另一个能改收款。

一个够用的判据是：假设这个角色判断失误或被恶意操作，最大损失是什么？这个损失当天能不能被发现？答案决定他落在哪一类。

• 能碰资金链路和主体资料的，损失没有上限——负责人、财务，通常不超过两人，且不参与日常执行。
• 能改价格、库存、活动、发货的，损失以店铺月毛利计——店长，权限绑定到店铺组，不跨主体。
• 只处理订单与客户对话的，损失以单笔订单计——运营、客服，权限限定在订单层，看不到成本和收款。
• 没有长期信任关系的，损失以信息外泄和账号外借计——外包设计、达人对接、临时兼职，只给带期限的窄权限，任务结束即撤。

四类角色的最小可见集

下表是最小授权的起点而不是标准答案。任何一个格子的例外都要有理由，并且写进权限清单里，否则半年后没人说得清为什么他能看。

店铺分组是权限的第一层容器

逐店勾选在 3 家店时勉强可行，到 8 家、10 家必然出错：新店开出来没人记得配权限，于是直接复制上一个账号的勾选，把不该给的范围一起复制过去。把角色绑到“组”，新店只需归组就自动继承。

1. 第一层按平台分组：TikTok Shop、Shopee、Amazon、独立站各自成组。跨平台的角色能力不通用，一个人同时管两个平台的中控台，等于把两套风险口径混在一起。
2. 第二层按国家或站点分组：泰国、越南、马来西亚分开。本土店的注册资料、收款主体和售后规则按国别不同，混在一个组里会出现“能看泰国店的利润，就顺带看到越南店的”。一国多店的分组细节可参考TikTok Shop 东南亚本土店矩阵的分组与子账号映射。
3. 第三层按注册主体分组：同一营业执照下的店铺归一组，不同主体的店不允许出现在同一个角色范围里。角色一旦跨主体，离职交接时你无法判断他带走了哪些主体的资料。
4. 第四层按风险等级标注：主力店、测试店、待处置店分开。测试店可以给宽权限提速，主力店的改价、换主图、改收款必须走复核。

组名要能自解释，例如“TTS-TH-主体A-主力”，避免“组1”“新组”这类名字——半年后没人知道它包含什么，也没人敢删。

子账号、ERP、浏览器环境必须对齐到同一张权限矩阵

只在平台后台配子账号，通常会被下面三个入口绕过，而且绕过时后台日志看起来一切正常。

• 浏览器环境归属：一个 Profile 绑定了哪几家店，这个环境的持有者就能登录其中任意一家。平台子账号切得再干净，共用 Profile 依然让权限形同虚设。Profile 与店铺的一对一归属做法见一台电脑同时运营多个 TikTok Shop 的环境配置，也可以从多账号管理的思路里挑适合自己规模的隔离粒度。
• ERP 店铺范围与 API key：ERP 主账号和开放的 API key 往往比平台子账号权限更大，能一次性拉走全部店铺的订单和利润数据。给运营开 ERP 子账号时，店铺范围必须和平台侧一致；冻结清单里，API key 要排在子账号前面吊销。
• 共享收款与付款账户：多家店共用一个收款账户时，能进这个账户的角色实际上能影响所有店。几个店铺共用一个收款账户的连带风险里，最先暴露的往往就是这类交叉。

核对方法很笨但有效：拿一张表，行是角色，列依次是平台角色、可见店铺组、ERP 店铺范围、浏览器 Profile、API key 归属、收款与付款权限。每个角色填完之后，找一行出现“全部”的地方，问一句为什么。

资金与合规权限：任何角色都不能一人闭环

如果团队只有三个人，双人复核做不到，退一步的替代方案是：资金类操作集中到一个主账号，主账号的登录环境单独隔离，每次资金操作在团队群里留一条记录，写清时间、金额和去向。这不是合规方案，但它能把“没人知道”变成“有人看到”。

入职、转岗、离职的权限变更顺序

1. 入职当天只给组和最小角色，不给单店逐项勾选。新人先跑一周订单和客服，确认确实需要更多数据时再加。
2. 试用期结束按岗位补数据可见层，比如成本和广告消耗；操作执行层按店铺组放开；转移与主体层不开放。
3. 转岗先减旧组、再加新组，顺序不能反。先加后减会让账号在两个组里同时存在一段时间，日志上无法区分他用哪个身份操作。
4. 离职前 48 小时依次冻结平台子账号、吊销 ERP API key、收回浏览器 Profile、移除收款与付款授权、移出广告账户，最后才改主账号密码。只改主密码是最常见的漏项，完整的项目清单见运营离职账号交接的权限清单。
5. 交接确认表逐项签字，包含店铺组、数据范围、未处理完的退款和未花完的广告预算。

常见反模式与边界条件

• 全员管理员：3 人团队最容易这么做，图快，代价是任何一次误操作都没有边界。
• 子账号共用：两人用一个账号，日志无法归因，出了问题只能猜。
• 财务看全部店铺利润：本身合理，但如果同一个财务还有提现权限，资金链路就没有第二道门。
• 外包用主账号：最常见的账号外借形式，通常以“就传几个文件”开始。
• 离职只改主密码：子账号、API key、旧 Profile、收款授权都还开着。

三人以下的团队不必照搬四类角色，但至少保留两条线：资金操作与店铺设置分开，执行账号与主账号分开。人再少也不建议把两者合并在同一个人身上，因为合并之后没有任何机制能发现问题。