想做好ERP跨境电商，先掌握增长策略中的权限管理
我做过一件很多跨境卖家不愿意承认的事：把公司所有 ERP 主账号的密码重置了一遍，然后看有多少人来找我要新密码。27 个主账号里，有 9 个在重置后的 48 小时内没有任何人认领，包括我自己。也就是说，这些账号是谁开的、谁在用、用来干什么，公司里已经没人说得清了。
这件事发生在我负责一家跨境电商公司运营中台的第二年。那一年店铺数从 3 个涨到 27 个，团队从 5 人涨到 43 人，年 GMV 翻了接近 6 倍。听起来是漂亮数字，但真正让我夜里睡不着的不是增长本身，而是增长过程中被甩在身后的权限管理。我们不是被风险掐死的，是被流程拖死的：开一个新店要等 3 天才能配好账号，招一个运营要等一周才敢让他看订单，接一个代运营要先交出店铺密码。
后来我复盘这一段，得到一个和主流说法不太一样的判断：权限管理不是跨境电商的 IT 安全话题，它是增长策略的一部分。它决定的不是"你会不会出事"，而是"你能安全地把多少事交出去"。这篇文章就是把这个判断拆开讲清楚，包括我踩过的坑、我用来做判断的标尺，以及一张你今天就能拿去用的自检表。
我见过太多团队把权限当成一个"合规动作"，出了事才想起来配，配的时候照着 ERP 后台的默认模板点一遍，点完就再也不看。这种做法的隐含假设是：权限的作用是防坏人。但跨境团队里真正的痛点，绝大多数不是坏人造成的，而是好人造成的。
第一个结论：权限是增长速度的接口。每一次增长动作，背后都对应一次权限动作。招人，对应角色预设；开新店，对应店铺数据范围划分；接代运营，对应服务商账号授权；进新国家，对应多法人、多币种、多仓的数据隔离。这些动作如果不能在权限层"通上电"，增长就会被卡在流程上，而不是卡在市场上。
第二个结论：增长速度 × 数据边界 = 可持续扩张。这个乘法关系里，任何一项趋近于零，结果就是零。管太松，边界塌陷，一次离职就能带走半个客户池和成本底价；管太死，速度归零，所有决策堵在老板一个人身上，业务自然长不大。真正难的不是"要不要管"，而是找到那个"刚好"的位置。
第三个结论：权限的设计单位是"岗位 × 数据范围 × 操作类型"，不是人名。按人名配权限看起来最灵活，实际是最脆弱的。人走权限留，变成孤儿账号；岗位调整权限不改，变成越权访问；新人来了复制前任权限，等于把前任的问题一并继承。
第四个结论：权限能力是 ERP 选型里被严重低估的分水岭。绝大多数选型对比表只比订单、库存、财务、物流，权限那一栏常常只写一句"支持子账号"。团队在 10 人以下时，这一栏确实无关紧要；到了 20 人以上、5 个店以上、出现第一个代运营时，这一栏会直接决定你要不要换系统。
抽象的模型说服力有限，我更愿意讲清楚具体的卡点长什么样。下面四个场景，是我在不同规模的跨境团队里反复见到的，按团队规模从小到大排列。
这个阶段用共享主账号是常态。老板一个号，运营一个号，客服一个号，谁需要什么自己去后台看。这个阶段共享账号几乎不产生可见损失，因为每个人都知道所有事，信息本来就不需要隔离。
问题在于，这个阶段的"习惯"会被带进下一个阶段。等到第 6 个人入职、第 4 个店开起来，团队仍然在用同一套做法，只是没有人意识到它已经失效了。
多店铺运营开始分工，A 运营负责美国站，B 运营负责欧洲站。这时候共享账号的第一个副作用出现了：A 能看到 B 的广告花费和转化率，B 也能看到 A 的。表面上无损，实际上团队开始互相比较，运营不愿意把真实的投放策略写进系统，数据开始"体外循环"。
更实际的问题是绩效核算。月底算提成时，运营说"这个店的单子有一半是我处理的"，财务翻 ERP 日志翻不出来，因为没有到人的操作记录。这是我见过最频繁的权限诉求来源，权限问题往往先以"算不清账"的形式暴露，而不是以"泄密"的形式暴露。
这是权限债务集中爆发的临界点。代运营要登录后台看数据、上新、调价、处理客服，但他们不该看到你的进货成本、供应商联系方式、真实的利润率。
我见过最常见的处理方式是：直接开一个管理员子账号，然后口头约定"不要看财务页"。没有任何系统层面的约束，全靠人情。代运营团队换人、离职、甚至和你谈崩，风险完全敞开。这个阶段真正需要的不是"更严的规则"，而是能在系统层面把"能做的事"和"不能做的事"分开的技术能力。
到这个规模，每个月都有人来有人走。如果没有一套"入职即配、离职即收"的流程，你会持续处在一种状态里：你不知道现在有多少个能访问核心数据的账号在外面。
我那次密码重置，本质上是一次被动审计。9 个没人认领的账号，就是 9 个不知道在谁手里、能不能访问订单和成本数据的入口。这里面可能有已经离职半年的前员工，也可能有早就该注销的测试账号。
在讲正确做法之前，我想先把错误做法讲透。因为大多数团队不是不知道权限重要，而是对"什么才算管好"的判断本身就有偏差。
这是最根深蒂固的一条。很多老板把权限配置交给行政或 IT，理由是"这是系统的事"。但行政不知道哪些字段是敏感的，IT 不知道运营为什么需要临时看别人的店铺数据。
真实情况是：权限的决策必须由业务负责人做，IT 或系统管理员只负责执行。谁能在什么情况下看到成本价，这是一个业务判断，不是一个技术配置项。
最小权限原则本身没错，但它在跨境场景里有三个失效点。第一，大促期间需要临时提权，严格按最小权限配会导致活动响应变慢；第二，跨岗位协作频繁，一个新品上市需要运营、采购、客服同时看数据；第三，当权限严到影响正常工作，员工会自己找绕过办法，最典型的就是共享账号。
严到让人绕路，等于把风险从"可见的权限系统"转移到了"不可见的账号共享"里，这是更糟的结果。
按人配的好处是精准，坏处是无法复制。新人入职时，要么复制前任的全部权限（继承问题），要么从零开始猜（低效）。而且按人配的团队，一旦人员超过 15 个，权限表就没人维护得动了。
正确的单位是岗位。岗位是稳定的，人是流动的。角色应该跟着岗位走，人走角色留，新人套角色。
很多老板为了"安全"，把唯一的管理员账号攥在自己手里。结果是所有需要临时开权限的事情都要等老板有空，审批链变成瓶颈。更麻烦的是，老板自己往往不熟悉系统的每一个配置项，配置质量反而不如专职管理员。
这是我认为最需要单独拿出来讲的一条。查看和导出，是完全不同量级的两种权限。查看是瞬时风险，导出是持久风险。一个人看一眼成本价，损失有限；一个人把全店订单和成本表导成 Excel，这份文件会在他的私人电脑里永久存在。
我后来给自己定了一条铁律：导出权必须单独授权，并且默认不随岗位角色自动继承。这条规则拦住的风险，比其他所有规则加起来都多。
这句话在 10 人以下成立，在 15 人以上开始不成立。ERP 的权限能力差异极大，有的只支持到"角色 + 模块"，有的能细到"字段 + 数据范围 + 操作类型"。而团队扩张的速度往往快过系统切换的周期，等到发现问题时，你已经处在"要么忍受，要么迁移"的两难里。
讲完误区，我给出我自己在用的判断框架。这个框架不复杂，但它的价值在于把"谁能干什么"这个模糊问题，拆成了四个可以分别配置、分别检查的层。
账号层是所有权限的基础。它要回答的问题只有一个：系统里的每一个身份，能不能对应到一个真实的人。
这一层的判断标准很简单：你能不能把一个账号，在三分钟内对应到一个在职员工的名字和工号。如果做不到，说明账号层已经失控了，后面三层配得再好也没有意义。
具体要做的事包括：一人一号、禁止共享、入职即开、离职即收、开启多因素认证（MFA）、限制登录设备或 IP 范围。最后这两项在跨境团队里尤其重要，因为团队可能分散在国内多个城市甚至海外。
角色层是把权限从"人"解耦到"岗位"的关键。做法是按岗位建角色，而不是按人建权限。
一个典型的跨境团队角色清单大概是：运营（分平台）、客服、采购、仓储、财务、广告投放、代运营（外部）、管理者（分级）。这里的关键判断标准是：当一个人离职时，你是删掉一个角色实例，还是要逐个收回权限？前者是一分钟的事，后者是一小时的事，而且会漏。
我建议在角色命名上保持和实际组织架构一致。角色名不要用系统默认的"角色A、角色B"，用真实的岗位名称。这不是美观问题，是可维护性问题，半年后你回头看，只有真实岗位名还能看懂。
数据层是跨境 ERP 权限里最有价值、也最容易被忽略的一层。它通常包含四种数据范围：店铺级、仓库级、部门级、字段级。
前三级是横向切割：A 运营只能看北美店铺，B 客服只能看自己负责的仓库，C 部门只能看本部门订单。第四级是纵向切割，也是最重要的一级：成本、利润、供应商联系方式、物流报价这些字段，应该独立于岗位之外单独设限。
我做过一个粗略统计：在我接触过的团队里，真正做了字段级隔离的不到两成。而恰恰是这两个成不到的团队，在人员流动时几乎没有出现过价格体系外泄的情况。
操作层把"能看"和"能做"分开。常见的操作类型包括：查看、编辑、审核、导出、删除。这五种权限应该分开授权，而不是打包成一个"可编辑"。
我的排序建议是：导出权和删除权，是两个必须单独审批的权限；审核权和编辑权，可以跟岗位绑定；查看权，基本可以按数据范围放开。
因为在所有操作类型里，只有导出会把数据变成"可脱离系统存在"的形态。编辑和查看都留在系统里，导出则把数据复制到了你的控制范围之外。
删除是不可逆的，而且在跨境电商场景里，订单、库存、财务记录往往有对账和售后需求，一次误删可能影响几个月的追溯。删除权建议只给到明确的负责人，并且配合操作日志。
前面四层解决"怎么配"，这里解决"配到什么程度"。我用了很久的三条标尺，比"最小权限原则"更好用。
标尺一，损失标尺：这个人拿走这份数据后，能造成多大的实际损失？损失小于一天的沟通成本，就直接给；损失超过一个月的利润，就必须走审批。这条标尺取代了按职级一刀切的做法，因为职级高不代表不会泄密，职级低不代表数据不敏感。
标尺二，交接标尺：这个人离职时，这套权限能不能在 10 分钟内完全收回？如果不能，说明权限是散落在多个地方的，需要先做一次归集。
标尺三，审计标尺：如果他做了某件不该做的事，你能不能在三分钟内定位到是他做的、什么时候做的、做了什么？如果不能，说明你缺的不是权限控制，而是操作日志。
国内电商的权限模型相对简单：多店铺、多客服、多仓库，基本就这些维度。跨境电商在这之上多出五类特殊问题，而恰恰是这五类，最容易在选型时被忽略、在上线后才被发现。
代运营是跨境团队最常见的外部协作形式。问题在于，代运营需要权限的深度往往超出你的预期：他们要看库存、要调价格、要处理客服、要上新，甚至要看一部分广告数据来优化投放。
我的处理方式是把代运营单独作为一个角色类型，而不是"低配版运营"。这个角色的数据范围只覆盖他们负责的店铺，字段上屏蔽成本和供应商信息，操作上禁止导出和删除，并且所有账号必须实名到具体对接人，不能用一个公共账号。
这里有个容易被忽略的细节：代运营的账号要有明确的到期时间。合作结束时账号自动失效，而不是等你想起来去关。
跨境 ERP 需要对接亚马逊、独立站、TikTok Shop 等多个平台，这些对接依赖授权凭证或 API 密钥。这些凭证的权限等级，往往比普通用户的账号更高，它们代表的是店铺本身。
我在审计时发现的一个常见问题是：授权凭证是"谁都能看、谁都能改、没人负责撤销"的状态。这类凭证一旦外泄，对方的操作不会被记录为某个员工的行为，而是以店铺的身份出现。
处理原则有三条：能看的人越少越好；每次授权都要记录授权时间、授权范围和操作人；建立撤销清单，把"哪个平台、哪个凭证、谁能撤、怎么撤"写清楚。至于各平台具体的授权规则和接口权限，请以平台官方最新文档为准，不要凭记忆操作。
当你开始使用海外仓，或者在不同国家注册了不同主体，数据隔离的需求会立刻变得复杂。海外仓的库存数据、当地的税务和财务数据，往往对应不同法人主体，需要物理意义上的隔离，而不只是"打标签"。
这一层的判断标准是：如果两个法人的数据必须分开报税、分开审计，那么它们在系统里就应该是两个独立的数据域，而不是靠筛选条件区分。靠筛选条件区分的数据，只要有一个人能看到全部，隔离就是形式上的。
跨境团队的岗位轮换频率比国内电商更高，因为平台差异大、人员流动快。轮换和离职会带来同一类问题：权限的交接被遗漏。
我的做法是把权限项写进交接清单，和电脑、工牌、门禁卡放在同一个清单里。具体包括：账号回收、角色移除、代运营账号关闭、API 凭证轮换、导出的文件归还或销毁。
最后一项最容易被漏掉，也最重要。一个人离职时电脑还回来，但他导出的 Excel 有没有还回来，很少有人问。
前面四条都是"防止发生"，这一条是"发生之后怎么办"。审计留痕的价值在于，它把权限从"信任机制"变成了"验证机制"。
判断标准很直接：如果明天有人声称"这份客户名单不是我从系统里拿的"，你能不能拿出证据？能，说明你有审计能力；不能，说明你需要先补的不是权限，是日志。
前面讲的是判断逻辑，这一节讲落地。我最近用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）搭了一套测试环境，把前面说的四层权限模型完整配了一遍。之所以选它，是因为它本身就是面向跨境电商场景设计的，多平台、多店铺、多仓的隔离需求是它的默认前提，而不是后加的功能。
账号层的配置最直接。每个成员对应一个独立账号，账号与手机号或邮箱绑定，开启登录验证。我在测试环境里建了 43 个账号来模拟我经历过的那个团队规模，配置完成后做的第一件事就是检查：每个账号能不能对应到一个具体岗位。
这一步没什么技术含量，但价值极高。它把"系统里有多少个身份"这件事从模糊变成了可数。
我建的角色清单是：北美运营、欧洲运营、客服、采购、仓储、财务、广告投放、代运营（外部）、管理者。每个角色对应一组权限，新人入职直接套用角色。
这里我特别想说一个细节：代运营角色是单独建的，不是给运营角色减几项权限。因为它的数据范围和操作范围都不一样的，隔离维度也不同。用"减法"做出来的角色，每次有人调整总角色，代运营就会被动获得新权限。
下面是我在测试环境里用的角色定义结构，用来说明"角色 = 数据范围 + 操作类型 + 字段可见性"这个组合关系：
{
"role_name": "海外代运营_北美站",
"account_scope": {
"shop_ids": ["US-01", "US-02"],
"warehouse_ids": ["US-WEST-01"],
"expire_at": "2026-12-31"
},
"field_policy": {
"visible": ["order_no", "sku", "qty", "shipping_status", "ad_spend"],
"hidden": ["cost_price", "gross_margin", "supplier_contact", "logistics_quote"]
},
"operation_policy": {
"view": true,
"edit_price": true,
"edit_order": false,
"audit": false,
"export": false,
"delete": false
},
"login_policy": {
"mfa_required": true,
"device_whitelist": true
}
}这个结构里我认为最重要的三行是：expire_at、hidden 里的成本与供应商字段、以及 export: false。它们分别对应了"到期自动失效""字段级隔离""导出单独管控"这三条我认为最值钱的规则。
数据层是我在测试里花时间最多的部分。店铺级隔离相对直接，北美运营只看北美店铺，欧洲运营只看欧洲店铺。麻烦的是跨国、跨仓的组合场景。
我的处理方式是先画一张"数据归属图"：把每个店铺、每个仓库、每个法人主体列出来，标注它属于哪个团队、哪个国家、哪个财务口径，然后再回到系统里配置。先画图再配置，比边配边想效率高得多。
字段级隔离需要单独强调。成本价、利润率、供应商联系方式这三类字段，我建议在系统里做成独立权限项，与岗位解耦。因为它们的使用场景很特殊：财务需要，采购需要，但运营和客服通常不需要。
操作层里我只重点管两项：导出和删除。其他操作可以跟角色走，这两项必须独立。
我给自己定的规则是：导出权默认关闭，需要时按次申请，申请里必须写明导出范围、用途和保存方式。这条规则刚上线时被抱怨过，两周后就没人抱怨了，因为大部分导出需求其实是"想确认一下数据"，用查看和筛选就能解决。
我没有一次性把所有权限配完，而是分三阶段上线，这也是我推荐给其他团队的做法。第一阶段收导出权和删除权，第二阶段做店铺级数据隔离，第三阶段细化到字段级和操作类型。
分阶段的原因很实际：如果你一上来就把权限收到最紧，团队会集体抵触，最后的结果是制度被架空。先收最关键的，让大家感受到"没有变慢，但风险小了"，后面再推进就容易得多。
讲完逻辑和案例，最后落到行动。我按团队规模分了四个阶段，每个阶段只给最紧要的几件事，避免一上来就想做全套。
这个阶段不需要复杂配置，但有两件事必须现在做，因为它们的成本最低、收益最长。
这个阶段不要做的事：不要建复杂的角色体系，不要引入字段级隔离，不要写权限管理制度文档。规模不到，制度是负担。
这个阶段是从"能跑"到"能管"的过渡期，重点是角色化和数据隔离。
这个阶段最容易犯的错是"等有新店再说"。我的建议是，只要你的运营超过两个人，就该做店铺级隔离。
这个阶段的重点从"控制"转向"结构"。
到这个阶段，权限已经不只是"谁能看什么"，而是"数据在哪个主体的控制之下"。建议做三件事：
我在这篇文章里一直在讲"要管"，但我也想认真讲讲"不要管过头"。因为我在实际推进权限体系的过程中，见过太多因为管得太死而失败的案例，失败的形态比管得松更隐蔽。
这是最根本的一组取舍。审批链每增加一级，平均响应时间就会明显拉长。我做过记时，一个需要三级审批的导出申请，从发起到拿到文件平均需要 6.5 小时；降到一级审批后是 1.2 小时。
我的判断是：不要用审批级别来表达重视程度。更有效的做法是降低审批的必要性，把权限设计得足够精细，让大部分人根本不需要申请，本身就拿到了刚好够用的权限。
角色标准化会牺牲一部分灵活性。有些岗位确实特殊，硬套标准角色会让人干不了活。我的处理方式是留一个"例外角色"，但要求例外的原因、期限和审批人都有记录，并且每季度复核一次。没有期限的例外，等于没有标准。
这个问题在 20 人以上会被反复讨论。我的判断标准是三条：你的 ERP 能不能做到字段级隔离；能不能做到导出权单独授权；操作日志能不能按人按时间检索。三条都能做到，就用自带的；做不到两条以上，就该考虑换工具或者补一层外部管控。
自建一套权限系统的成本通常被低估。除了开发成本，还有长期维护成本，以及"自建系统本身成为新的安全薄弱点"的风险。除非你的业务规模已经大到 ERP 无法承载，否则优先选择权限能力足够的现成系统。
有三类场景，我认为可以适度放松。
第一类是大促期间。活动高峰期需要临时提权，这时候应该走"临时授权 + 到期自动回收"的机制，而不是临时改角色。改角色容易忘记改回来，临时授权会自己失效。
第二类是新人试用期。试用期员工可以先给查看权，不给导出和编辑权，转正后再套完整角色。这样既不耽误上手，也控制了风险窗口。
第三类是核心管理层。对 2 到 3 个核心管理者，权限可以放宽，但必须配合完整的操作日志。因为对他们的管控成本高于收益，而日志可以覆盖事后追溯的需求。
如果只让我留一条规则，我会留这一条：权限的松紧，应该以"这个人拿走这份数据后能造成多大损失"为标尺，而不是按职级一刀切。
职级高不代表不会泄密，职级低不代表数据不敏感。一个客服拿走全部客户联系方式，损失可能比一个总监看到利润率大得多。按数据敏感度分配权限，而不是按人头分配信任，这是我认为最接近正确的一条原则。
我不太喜欢在结尾写"建议企业建立完善的权限管理制度"，因为这句话没有动作。我把它换成三件今天就能做的事，以及一张可以对着 ERP 后台逐项打勾的自检表。
下表是我自己在用的版本。建议你打开 ERP 后台，对着逐项确认，而不是凭印象回答。
| 层级 | 检查项 | 判断标准 | 是否已配置 |
|---|---|---|---|
| 账号层 | 一人一号 | 每个账号能在 3 分钟内对应到在职员工 | 是 / 否 |
| 账号层 | 离职即回收 | 离职清单包含权限回收项，且有执行记录 | 是 / 否 |
| 账号层 | 登录验证 | 管理员账号与含敏感数据账号已开启多因素认证 | 是 / 否 |
| 角色层 | 按岗位建角色 | 不存在以人名为单位维护的权限配置 | 是 / 否 |
| 角色层 | 外部角色独立 | 代运营/服务商角色独立于内部角色，且含到期时间 | 是 / 否 |
| 数据层 | 店铺级隔离 | 运营只能看到自己负责的店铺数据 | 是 / 否 |
| 数据层 | 字段级隔离 | 成本、利润率、供应商联系方式为独立权限项 | 是 / 否 |
| 数据层 | 主体级隔离 | 多法人主体的数据独立成域，非筛选条件区分 | 是 / 否 |
| 操作层 | 导出权独立 | 导出权限未随角色自动继承，需单独授权 | 是 / 否 |
| 操作层 | 删除权独立 | 删除权限仅授予明确责任人 | 是 / 否 |
| 操作层 | 审计留痕 | 可按人、按时间检索关键操作记录 | 是 / 否 |
如果你的自检表里"否"超过四项，不要一次性全改。我建议按这个顺序推进：先收导出权（一周内可完成，见效最快）→ 再做店铺级数据隔离（两到四周）→ 最后细化到字段级和操作类型（一到两个月）。
这个顺序的逻辑是风险优先：导出权是外流的主要通道，也是改动成本最低的一项；店铺级隔离同时解决风控和绩效两个问题，最容易获得团队支持；字段级隔离见效慢，但一旦做好，长期价值最高。
那次密码重置之后，我把 9 个无人认领的账号全部关闭，然后做了一件事：把每个在职员工的账号、角色、数据范围、导出权限整理成一张表，发给了对应部门的负责人确认。两天内我们收回了 3 个不该存在的导出权限，也发现了一个已经离职四个月、仍然能登录后台的账号。
这件事让我彻底改变了对权限管理的理解。它不是一份要建立的安全制度，而是一个应该跟着团队一起长大的结构。你的团队每长一岁，这个结构就得跟着调整一次；调得及时，它就是增长的加速器；调得不及时，它就是增长的刹车片。
所以回到标题：想做好 ERP 跨境电商，先掌握增长策略中的权限管理。不是因为权限能帮你防住多少风险，而是因为它能决定你敢于把多大的事交出去。而一个跨境团队能长多大，归根结底取决于此。
如果你现在正准备做这件事，我建议的第一步是：打开 ERP 后台，把管理员级别的账号全部列出来。看看有几个是你叫不出名字的，这个数字，就是你现在真实的增长上限。
我们团队从3个店做到十几个店，最开始就是给每个人开个账号就算完事，结果运营能看到财务数据，客服能导出全店订单。后来想认真整理，又不知道从哪一层下手，看ERP后台那一堆开关头都大了。
我一般按四层来拆，顺序不能反。第一层账号层：一人一号，禁止共用主账号，离职当天回收，能开二次验证就开。第二层角色层：按岗位建角色（运营、客服、采购、财务），不按人名建，人走角色留着，新人直接挂上去。
第三层数据层：先按店铺分，再按仓库分，最后才是字段级，成本、利润、供应商和货代的联系方式这几项单独拎出来限制。第四层操作层：查看、编辑、审核、导出、删除要分开授权，其中导出权是最该单独管的一项，因为它等于把数据复制出系统的通道。
判断标准很简单：任何一个账号，你应该能用一句话说清它为什么需要看到这些数据，说不清就是配多了。上线顺序建议先收导出权，再分店铺数据范围，最后细化操作权限，因为前两步能立刻止住最大风险，第三步最容易卡住日常协作。
我们做亚马逊和TikTok Shop，找了个代运营团队帮忙打理两三个店。他们要求给管理员权限，说不然操作不方便。我心里很清楚这不合适，但又怕权限给少了他们推不动事，一直卡在这个点上。
核心思路是给他们一条独立通道，而不是把现有账号借出去。具体做法：先让他们用自己公司的邮箱注册子账号，绝不共用你们员工的账号，这样人员变动时你只需停用对方公司这一条线。然后按店铺授权，只给他们在服务的店铺，其他店铺一律不可见；
操作层面给查看、编辑、上架、广告这类日常权限，采购成本、利润报表、供应商联系方式、平台API密钥和授权凭证这几项坚决不给。管理类权限比如成员管理、权限配置、财务设置、数据导出，一个都不放。如果你用的系统支持数据范围设置，把他们的可见范围锁死在指定店铺，防止他们通过报表间接看到其他店的经营数据。
合作开始前把授权清单写成文字双方确认，合作结束当天停用账号并检查一遍还有没有遗留的授权。判断依据是：他拿走的任何一项数据，如果转头给到你的竞争对手，你能不能承受，承受不了就不给。
我们去年还是5个人3个店，大家一个主账号谁用谁登，也没出过什么事。今年人招到十几个，店也开到七八个，突然感觉哪儿都在漏风，但又说不上来具体是哪一步该动手。
没有统一的魔法数字，但有四个信号出现任意一个，就说明该动手了。第一个是团队跨过十人左右，因为超过这个规模你就没法靠记忆判断谁该看什么。第二个是店铺跨过五个左右，多店铺的数据归属开始变得模糊，运营之间容易互相看到对方的店铺。
第三个是出现第一个代运营或外部服务商，只要有一个外部账号进来，账号共享这套做法就彻底不成立了。第四个是出现第一个境外主体或海外仓，财务和库存的隔离需求会突然变强。之所以按信号而不按人数判断，是因为权限问题的本质是组织复杂度，不是人头数，5个人做5个国家的生意，复杂度可能比20个人做一个站点还高。
真要动手，我建议从一份现状清单开始：把所有管理员级别账号列出来，看看有几个是你叫不出名字的，这份名单通常就是最直接的行动起点。
我们之前吃过一次亏，一个运营误删了大量数据，之后我就把权限收得特别紧。结果审批链变长，跨部门取个数要等两天，大促期间更是急死人。后来发现有人偷偷用共享账号绕过权限做事，等于白管。
管太紧和管太松都是成本，区别只是成本出现在哪。管太紧的代价通常是三块：审批链变长、跨部门取数变慢、员工为了干活绕过制度去用共享账号，最后反而制造了一个更大的监控盲区。可控的松绑有三个机制，关键是每个都要带回收条件：一是临时授权，明确起止时间，到期自动失效，别用永久提权代替；
二是例外审批，走一个留痕的流程，批了就有记录，事后能复盘是谁批的、为什么批；三是大促提权，活动前集中放开，活动结束当天统一回收，把回收动作写进大促复盘清单里。
判断松紧的标尺不是职级，而是这个人拿走这些数据之后能造成多大损失，一个只做客服的岗位就算给他看店铺列表影响也有限，但一个要接触成本和利润字段的岗位，哪怕级别不高也必须收紧。所以不要按层级一刀切，按数据敏感度分档更实用。
读者评论
看到9个无人认领的主账号那段挺有共鸣。我们公司30多人时也做过类似盘点，结果发现测试账号和离职员工账号混在一起，根本分不清。后来强制按岗位建角色才理顺，但确实花了两个月。
作者把权限说成增长接口，这个角度比较少见。不过我觉得关键还是老板愿不愿意放权，很多中小卖家卡住不是因为系统不行，而是决策本身不敢交给别人。
导出权单独授权这条建议很实用。我们之前有人把成本表导出去做私活，事后查日志才发现。现在导出必须走审批，虽然麻烦一点，但至少知道文件在谁手里。
权限模型讲得清楚，但落地时最大的阻力是运营嫌麻烦。大促期间临时提权如果流程太长，他们就会用共享账号绕过。所以技术和制度要一起改，光靠ERP功能解决不了。
个案例里账号共享占38%，这个数据倒是符合实际。我在代运营公司做过，客户直接给主账号的太多了，出问题才想起来要子账号，但那时数据早就不安全了。