去年秋天，我帮一个做亚马逊+Shopee+TikTok Shop三平台的卖家做运营诊断。团队 11 个人，管 27 家店，看起来是标准的多店扩张节奏。问题出在一个很不起眼的细节上：他们的客服主管为了方便处理售后，给三个客服开了 ERP 的订单导出权限，因为"导出后筛选退款单更快"。三个月后，其中一个客服离职，带走了近 8 万条客户订单数据，包括姓名、电话、地址和购买记录。这件事最后没有被追责成功，因为他们的 ERP 操作日志只保留 30 天，导出行为也没有单独记录操作人和导出条数。
这不是一个"员工道德"的故事，而是一个权限设计缺失的故事。27 家店、11 个人，听起来不大，但涉及平台子账号、ERP 账号、浏览器环境三层身份体系，任何一层没对齐，都会出现"该看的人看不到、不该看的人全能看"的局面。我这几年接触过几十个多店团队，权限管理做得好的不到两成，绝大多数是"出过事才补"。
这篇文章不谈 ERP 有哪些功能，而是把权限管理这件事从"后台设置"拉到"经营基础设施"的位置上讲清楚：为什么多店经营必须先把权限理顺、常见的三类误区、五层权限模型怎么搭、不同规模团队该怎么取舍，以及选型时该问服务商哪些问题。
我观察到一个反常识规律：很多卖家从单店做到十店、二十店，卡住的地方不是选品不行、不是广告打不起来，而是内部责任链断掉了。老板不知道哪家店的成本价被谁改过，主管不知道哪个客服批量删了订单备注，财务发现利润数据对不上但查不到源头。这些问题的共同根因都是权限边界模糊。
我见过太多老板把权限管理理解成"防内鬼"。这个理解方向错了，也容易把团队氛围搞僵。真正要防的是三件事：越权操作、误操作连带损失、离职/外包交接时的数据失控。前两件事跟员工忠诚度无关，纯粹是权限颗粒度不够造成的。第三件事才涉及风险控制。
举个例子：一个运营同时管 6 家店，他被允许修改所有店铺的商品价格。某天他批量调价时选错了店铺范围，把 A 店的活动价同步到了 B 店，B 店当天出单 400 单，全部按错误价格成交。这件事和"信任"没关系，而是批量操作权限没有做店铺级隔离。
单店的时候，一个老板账号加一个运营账号就够了。做到 20 家店、3 个平台的时候，账号数量不是线性增长，而是组合式增长：平台数 × 店铺数 × 角色数。3 平台 × 20 店 × 6 角色 = 360 个潜在权限组合点。这个数量级靠"临时想起来再设置"是管不住的。
这是我做过最有价值的一个判断：权限问题不会在配置错的那天暴露，而是在半年后、一年后暴露，而且往往叠加在别的危机上。比如离职带走数据、代运营看到全店利润后自己单干、财务对账时发现成本被改过但查不到人。等到问题爆发时，日志过期了、责任人离职了、证据链断了。
所以判断一个团队权限管理做得好不好，不要看现在有没有出事，而要看两件事：操作日志能不能追到人和时间、离职账号回收有没有固定流程。这两个问题答不上来，说明权限体系是虚的。
要讲清权限，得先把多店经营的"人员，店铺，数据"三张网铺开。我按自己接触过的团队样本做个分层，你会发现权限复杂度是跟着团队形态变的，不是跟着店铺数量变的。
第一种是夫妻店 / 3 人以内。老板自己管账号，运营一两个人。这个阶段权限管理的痛点几乎没有，因为人少，信任成本低于管理成本。硬上复杂权限反而拖慢效率。我的建议是只做两件事：老板账号开二次验证、运营账号不要给财务字段。
第二种是10，30 人的成长型团队。这个阶段最危险。团队刚过"靠人盯"的临界点，但还没建立制度。典型症状是：老板还在用主账号处理日常操作、运营和客服权限混用、财务能看到全部店铺但业务员也能看到成本价。我见过的数据泄露、误改价事故，八成发生在这个阶段。
第三种是50 人以上或含外包/代运营的团队。这时候权限管理已经不是选择题，而是合规题。外包人员流动性高、代运营可能有竞品客户、跨平台数据流动涉及合规，权限必须做到限时、限量、留痕。
我用一个具体流程说明权限有多绕。一笔亚马逊退款，从客户发起，到钱退回，中间可能经过：客服接收并登记、运营主管确认是否属于产品质量问题、采购核对供应商是否有责任、财务执行退款并记账、仓库确认是否要退回货物。这五个环节里，每个人都只该看到自己需要的那部分。
但现实往往是：客服有订单全量查看权，能看到利润；运营主管能改价也能改库存；财务为了对账拿到了全部店铺的成本价；采购为了核价看到了客户退货地址。结果是每个人都"有理由"拿到超出职责的数据。权限失控很少是恶意设计的，几乎都是"为了方便"一点一点让出去的。
亚马逊、Shopee、TikTok Shop、Temu 各平台的子账号体系规则、可授权范围、日志能力都不一样。有的是平台内角色固定，有的是按店铺独立授权，有的支持操作审计有的不支持。这意味着平台子账号权限天然是碎片化的，ERP 的价值恰恰在于把碎片拼成一张统一口径的表。
但要注意一个高频漏洞：ERP 里禁用的操作，可能依然能通过平台后台完成。比如 ERP 里限制了某运营不能改价，但如果他手上还有平台子账号，可以绕过 ERP 直接去平台后台改。所以权限设计必须"两头一起管"，只做一头等于没做。具体规则建议发文前查各平台最新官方文档核实，平台政策变动频繁。
我在做诊断时，会把对方对权限的理解准确度当成一个信号。因为误区一旦存在，后面配得再细也是错的。下面三个误区我遇到频率最高。
这是一个听起来正确、做起来很贵的主张。我见过一个团队把权限做到按钮级，连"导出"和"导出为 CSV"都分开授权，最后结果是运营改个价格要找主管审批三次，日常处理一单售后的时间从 2 分钟变成 5 分钟。三个月后主管自己把审批全关了，等于白做。
我的判断标准是：权限颗粒度应该跟着团队规模和风险金额走，不跟着功能数量走。涉及钱的（价格、退款、采购金额）要细；不涉及钱的（查看订单备注、标记发货）可以粗。先把高风险动作管住，再逐步细化低风险部分。
这两个是完全不同的层级。平台子账号管的是"能不能登录平台后台、能不能操作平台内的事"；ERP 权限管的是"在 ERP 这个统一工作台里能做什么"。很多人以为 ERP 设置了权限就安全了，但平台的子账号规则没同步收紧，照样能绕过去。
反过来说也一样：只收紧平台子账号，但 ERP 里所有店铺数据对所有账号可见，那财务、利润、客户信息依然裸奔。正确做法是把两者做映射，问自己一个问题：这个岗位在平台后台能做什么、在 ERP 里能做什么，两者是否匹配。
这是最隐蔽的误区。权限问题的潜伏期可能是一年，且很多问题不会被认定为"事故"。比如代运营看了全店利润后带着数据去谈下一家客户，这事不会被记录成事故，但损失是实实在在的。
所以我建议用一个更主动的指标来衡量：能不能在 10 分钟内查清"某家店的某个字段在某个时间点被谁改过"。这个动作能完成，说明权限体系是活的；完不成，哪怕现在没出事，也是靠运气在撑。
讲完误区，我给出自己在这几年里反复用的一套模型。它把权限拆成五层，从身份到审计，逐层收口。这个模型的好处是：不管用的是哪家 ERP，你都可以用这五层去检查它是否支持，或者检查自己的配置是否有漏洞。
这一层管的是"谁在用什么身份登录"。核心要素有四个：账号实名（谁是这个人）、子账号隔离（一人一号，不共用）、二次验证（登录门槛）、离职/转岗禁用（身份失效）。
我见过最多的问题就是共用账号。三个客服共用一个账号，看起来省事，但一旦出现异常操作，你永远不知道是三个人里的谁做的。所有下游审计都失去意义。判断标准很简单：如果操作日志里出现"同一账号在两地同时登录"，说明你们在共用账号。
这一层管的是"这个岗位该被归到哪一类"。典型角色包括：老板/管理员、运营主管、运营、客服、财务、采购/仓管、外包/代运营。注意角色是抽象的，岗位是具体的，一个人可能同时有两个角色（比如小团队里的运营主管兼运营）。
设计这一层的关键原则是按角色授权，不按个人授权。按个人授权会导致每次有人离职或转岗都要重新配一遍，而且极容易漏。按角色授权后，新人进来直接套角色模板，走人直接停用账号即可。这是权限体系能不能规模化复制的分水岭。
这一层管的是"能看到哪些菜单、能点哪些按钮、能执行哪些批量动作"。菜单级权限是最基础的，比如客服看不到财务菜单。按钮级权限是进阶的，比如运营能看订单但不能点"批量退款"。
我特别想强调批量操作权限要单独对待。因为批量操作的破坏力是单次操作的几十倍：批量改价影响几十上百个 SKU、批量改库存影响在售状态、批量导出直接带走几十万条数据。我的建议是批量操作默认关闭，按需开给主管级别的角色，并且强制留日志。
这一层管的是"能看到哪些数据"。它比功能权限更细，因为它管的是"看到什么"，而不只是"能做什么"。维度包括：店铺范围（只看自己的店）、平台范围（只做亚马逊不看 Temu）、仓库范围、字段级可见性（成本价、利润、供应商、客户信息）。
我判断这一层的核心是默认不可见，按需授权。很多系统默认所有字段可见，靠人工取消勾选，这种设计一定会漏。正确的默认值应该是"看不到"，然后针对岗位逐个放开需要的字段。尤其是成本价、利润、客户信息这三类字段，应该是默认锁死状态。
这一层管的是"高风险动作要不要过审、做过的事能不能查"。要素包括：审批流（改价审批、退款审批、采购审批、导出审批）、操作日志（谁在什么时候改了什么）、登录记录（IP、设备、地点）、告警（异常行为自动提醒）、定期复盘。
审计层里我最看重的是日志保留时长。我开头讲的那个案例，问题就出在日志只有 30 天。我的建议是至少保留 12 个月，涉及财务和客户信息的日志越长越好。另外，日志本身也要有权限，不能让普通运营看到全部人的操作记录，否则又是一层新的越权。
五层模型讲完，落地时最实用的工具是一张矩阵表。下面这张表是我根据多店卖家的常见岗位整理的建议配置，可以直接拿去对照调整。要说明的是，不同公司岗位设置不同，这是一张建议基准，不是统一标准。
| 角色 | 店铺范围 | 订单/售后 | 刊登/改价 | 广告 | 库存/采购 | 财务/利润 | 批量/导出 | 审批权 |
|---|---|---|---|---|---|---|---|---|
| 老板/管理员 | 全部店铺 | 全权限 | 全权限 | 全权限 | 全权限 | 全权限 | 全权限 | 最高审批 |
| 运营主管 | 分管平台/站点 | 全权限 | 可改价需审批 | 全权限 | 查看+申请 | 查看经营数据 | 限店铺范围 | 一级审批 |
| 运营 | 指定店铺 | 处理+备注 | 改价需申请 | 查看+调整 | 查看 | 不可见成本 | 不开放导出 | 无 |
| 客服 | 指定店铺 | 处理售后 | 不可见 | 不可见 | 查看可售 | 不可见 | 不开放导出 | 退款限额内 |
| 财务 | 全部店铺(只读) | 查看 | 不可见 | 查看花费 | 查看 | 全权限 | 对账导出 | 退款/采购审批 |
| 采购/仓管 | 按仓/按店 | 查看发货 | 不可见 | 不可见 | 全权限 | 不可见 | 不开放导出 | 采购申请 |
| 外包/代运营 | 仅授权店铺 | 按合同范围 | 按合同范围 | 按合同范围 | 查看 | 不可见 | 禁止导出 | 无 |
这张表里有几个我坚持的原则，值得单独说明：财务只读业务数据、运营不可见成本、外包禁止导出。第三条经常被忽视，但我见过的数据泄露案例中，涉及外包的比例不低。外包人员流动性高、可能同时服务竞品，导出权限应该是硬性禁止，而不是"看情况给"。
除了矩阵本身，还有三条设计原则贯穿始终。第一条是最小权限：只给完成工作必需的最小范围，宁可从窄到宽。第二条是职责分离：能改价的人不能同时审批改价，能采购的人不能同时做付款确认，避免单人闭环。第三条是默认不可见：新增字段、新增店铺、新增功能默认对所有角色关闭，按需放开。
这三条原则的价值在于，它们能对抗"为了方便一点点放权"这个惯性。权限管理的失败，几乎都发生在一次次"这次先给他用"的妥协里。
模型和矩阵是框架，真正让老板睡不着的是一次次具体事故。我挑了六个在多店卖家身上反复出现的场景，每个都给出风险表现、建议配置和审计动作。
风险表现是运营在批量调价时选错店铺范围或时间范围，导致错误价格上架出单。建议配置是改价功能只对运营主管以上开放，运营只能提交改价申请；批量改价必须走审批；改价前后价格差异超过一定幅度时强制二次确认。审计动作是记录改价人、原价、新价、涉及 SKU 数、审批人。
风险表现是客服为了跟进售后拿到全量客户数据，离职时带走。建议配置是客服默认不可见完整客户信息（手机号、地址做脱敏展示），只保留处理售后必需的订单号与联系方式；导出权限对客服默认关闭，确需导出走审批且日志记录导出条数。审计动作是监控导出行为，单次导出超过一定条数触发告警。
风险表现是运营看到成本价后判断出公司利润空间，用于个人谈判或对外透露。建议配置是成本价、采购价、利润率字段对运营和客服默认隐藏，财务和老板可见；如果 ERP 支持字段级权限，把这三类字段单独设为敏感字段。审计动作是定期检查字段权限配置有没有被改动。
风险表现是员工离职后账号仍可用，或账号停用了但关联的平台子账号没停。建议配置是建立离职清单制度：ERP 账号、平台子账号、浏览器环境、邮箱、共享文档，一次性全部回收。审计动作是每季度做一次账号盘点，对照在职名单核对。
风险表现是外包拿到超出合同范围的店铺或数据，合作结束后依然能访问。建议配置是外包账号限时授权、限定店铺、禁止导出、强制留痕；合作结束当天停用，不等合同流程走完。审计动作是外包账号单独归类，每月核查活跃状态。具体合同条款建议由法务确认。
风险表现是 ERP 里限制了操作，员工绕到平台后台完成，权限形同虚设。建议配置是把平台子账号权限与 ERP 角色做映射核对，形成"同一岗位两处一致"的规则；比如 ERP 里不能改价，平台子账号也不给改价权限。审计动作是每季度对照平台后台角色与 ERP 角色做一次一致性检查。平台规则变动频繁，执行前建议查最新官方文档。
回到开头那个 27 家店、11 人的团队。数据泄露事件后，他们花了一个多月重做权限体系。我把过程拆出来，因为这里面的取舍很典型。
他们做的第一件事是把所有账号列出来，对每个人标出：能登录哪些平台、能进 ERP 哪些模块、能看到哪些店铺、有没有导出权限。做完之后发现：11 个人的团队有 19 个 ERP 账号（有人开了多个），其中 7 个拥有导出权限，3 个账号已经没人用了但还在。这轮盘点本身就是一次风险暴露，很多问题平时看不见。
第二步是定义角色。他们最后收敛到六类角色：管理员、运营主管、运营、客服、财务、仓管。关键是不再按人授权，而是先定义角色模板，再把人挂到角色上。这个改动让后续所有调整的效率提升了一个量级，新人入职配权限从半小时缩短到几分钟。
第三步是收口高风险动作。他们把批量改价、批量导出、退款审批、采购下单四类动作从普通角色移除，只保留主管级以上。这一步短期内确实增加了审批量，运营有抱怨，但因为同时给主管开了移动端审批，实际平均等待时间控制在 15 分钟内，没有真正堵住业务。
他们之前的问题是操作分散在多个平台后台，权限自然就散。后来把订单、库存、采购、财务这些动作尽量收拢到统一 ERP 工作台里做，因为权限只有在一个统一入口里才能被统一管理。这类场景里，我会推荐他们重点看数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）这类面向跨境电商多店经营的 ERP 产品，因为它的核心逻辑就是围绕多平台、多店铺做统一管理，权限和角色是建立在"店铺范围 + 岗位角色"之上的，比较贴近前面讲的五层模型的第四、第五层。
要说明的是，我不认为任何一款 ERP 能替你解决权限设计问题。系统提供的是能力，能不能按店铺分权、能不能隐藏成本字段、能不能记录导出行为。真正决定安全的是你有没有用这些能力、有没有定期维护。数跨境这类工具的价值在于让你有能力把权限收口，但收不收、收到什么程度，还是靠管理判断。
最后一步是让权限管理变成周期性动作，而不是一次性工程。他们定了三个节奏：每月一次账号活跃核查、每季度一次权限全盘点、人员变动即时报备。这三个动作加起来每季度花不到一天时间，但能保证体系不倒退。很多团队做权限是一次性的，做完就烂掉，就是因为缺了这个节奏。
前面讲的是通用框架，实际执行时我的建议会按团队规模和形态分化。下面按四种典型情况分别给动作，你可以对号入座。
不要上复杂权限，会拖慢效率。只做三件事：老板账号开二次验证、运营账号隐藏成本和利润字段、平台子账号与 ERP 账号一一对应不共用。当前阶段的核心矛盾是效率，不是风险控制。等团队到 8 人以上再系统化。
这是最需要行动的阶段。建议动作按优先级排列：
这五步做完，基本能覆盖 80% 的高频风险。注意顺序不要反，先做角色再做动作，否则会反复返工。
核心是"限时、限量、留痕"三个词。限时是账号带有效期，合作结束自动失效；限量是店铺范围和数据字段都按合同最小化；留痕是所有操作可追溯且禁止导出。另外建议外包账号单独归类管理，每月检查一次活跃状态，避免合作结束后还留着访问能力。
不要一上来就大改，容易把业务搞停。我的做法是先做一次"权限快照"：把当前每个人、每个账号的权限导出成一张表，标出超配项。然后按风险等级分三批收口：先收导出和财务字段，再收批量操作，最后收菜单权限。每批之间留一两周观察业务是否受影响，避免一次性收紧引发团队反弹。
权限管理最难的从来不是"知道该怎么做"，而是"知道该收到什么程度"。我把几个常见的取舍点摆出来，供你判断。
加审批一定降低效率，问题是降低多少、换来什么。我的经验标准是：看这个动作的错误后果能不能自动止损。比如改价出错可以当天发现并改回，可以不加审批但加二次确认；退款出错钱直接出去了，加审批；采购下单出错影响库存和资金，加审批；导出数据出去就收不回来，加审批或直接禁止。判断依据是"可逆性"，不是金额大小。
藏太多会导致运营看不到必要信息，影响判断。我的建议是区分"判断必需"和"知情不必要"两类。运营判断是否需要补货需要看库存和销量，这是必需；运营不需要知道采购价和利润率，这是知情不必要。财务需要成本价做核算，这是必需；财务不需要改价权限，这是不必要。
这是我被问得最多的问题。我的回答是：把权限管理和信任分开谈，把它定位成流程，而不是监控。跟团队沟通时不要讲"防你们"，要讲"流程要求"，就像财务报销要有发票一样，是制度不是猜忌。同时尽量让权限配置对本人透明，让人知道自己能做什么、不能做什么，比暗地里限制更少引发对立。
如果现有 ERP 连字段级权限和操作日志都没有，那权限管理无从谈起，这时值得考虑换。如果现有系统只是配置没配好，那问题在管理不在工具，换系统解决不了。判断标准很简单：列出你在意的 5 个权限能力，看现有系统能否支持。支持 4 个以上就别换，支持不到 3 个就该认真评估。
写到这里，我想把最核心的判断再说一遍：多店经营的难点不是把店开多，而是把账号、数据、操作、责任链同时管住。店铺数量增长是线性的，但权限复杂度是组合式增长的。你在 5 家店时靠记忆能管住，到 30 家店时靠记忆必然出事。权限管理不是 IT 后台的一个小功能，而是决定你能不能不失控地扩张的基础设施。
如果你只想记住三件事，我建议是这三条：第一，按角色授权，不按个人授权，这是所有规模化权限管理的前提。第二，成本、利润、客户信息默认隐藏，导出默认禁止，这三类数据一旦出去就收不回来。第三，操作日志至少保留 12 个月，能不能追责决定了权限体系是真是假。
下一步的具体动作，我建议按这个顺序走：先做一次账号和权限盘点，把现在有多少账号、谁有什么权限列成一张表；然后定义角色模板，用角色替代个人授权；再把四类高风险动作收口到主管级；最后建立月度核查和季度审计的节奏。想先看系统能力的话，可以到数跨境官网（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;
_unit=gys）看看它的多店与角色权限设计，对照前面讲的五层模型，判断哪些能力你现在用得上、哪些可以等团队再大一点再说。
最后提醒一句：涉及平台子账号规则、数据合规和合同条款的部分，各平台政策变动频繁，发文执行前建议查各平台最新官方文档，涉及数据出境的场景请让法务或合规确认。工具能给你能力，但怎么用、用到什么程度，判断权始终在你手里。
我自己带过六七个店铺的团队，配权限时特别纠结：全开吧怕出事，全关吧运营天天来找我抱怨。也看过不少ERP把权限列了几十项，但真到用的时候不知道哪几项必须收紧、哪几项可以放开。
先按“动钱、动数据出境、动客户信息”三类收紧，其余按菜单级放开就够。具体分四层来看：店铺范围（能进哪几个店、哪个站点）、菜单功能（能不能进财务、采购、广告模块）、字段（成本价、采购价、利润、客户手机邮箱这类字段能不能看见）、按钮（改价、批量改库存、退款、提现、批量刊登、导出报表）。
判断依据很简单，只要一个操作会让钱变动、让数据离开系统、让客户信息可见，就要做到字段级或按钮级；纯查看类报表做到菜单级即可。多数越权事故集中在价格改动、利润字段和批量导出这三处，先把这三处锁死，比把几十个菜单全细分一遍有效得多。
反过来说，如果每个操作都挂审批，运营处理一单要点三次确认，扩张期团队会被流程拖死，所以细度要跟着风险走，不要跟着功能清单走。
我一直以为ERP里禁掉的功能就是禁掉了，直到有次发现某个客服居然还能在平台后台直接下载订单报表。后来才意识到这是两套完全不同的权限体系，谁也没管住谁。
因为至少有三层权限在各自为政：平台官方后台的子账号权限、ERP内部的业务权限、以及浏览器环境和IP这一层。任何一层留着口子，另外两层配得再细也没用。
可执行的做法是建一张“权限对照表”：横轴列出高风险操作（改价、退款、提现、修改收款账户、批量刊登、下载报表、管理用户），纵轴列出每一层（平台后台、ERP、环境），逐项确认这个操作在哪一层被卡住。
经验上，平台后台侧优先收回提现、收款账户和用户管理这三类，因为这几项一旦被动手，损失是直接的资金和账号安全；ERP侧则管订单、库存、采购、刊登这些日常业务动作。验证方式不要只看设置页，用测试子账号实际登一次平台后台，逐项点进去确认，每季度做一次复查。
各平台的子账号规则调整比较频繁，具体条目要以平台官方文档的最新版本为准。
我们是小团队，一共五个人，大家互相都认识，老板也在群里天天盯着。我总觉得搞角色分级、审批流这套是大公司才需要的东西，小团队做这个纯属给自己找麻烦。
小团队不需要复杂角色分级，但三件事必须做，一件都不能省。第一，一人一账号，绝不允许共用；共用账号一旦出事，日志里根本分不清是谁操作，追责和复盘都做不了。第二，把成本、利润、客户联系方式这三类字段默认对客服和外包不可见，这跟团队大小无关，是数据底线。第三，任何人离职，当天禁用账号。
什么时候开始上角色模板和审批流？给个可操作的判断门槛：团队超过七八个人，或者出现跨平台、跨站点的分工，或者有人同时具备“改价”和“审批退款”两个权限，或者外包能看到全部店铺数据，满足任意一条，就该做分级了。低于这个门槛时，重点放在账号独立和关键操作留痕上，比硬套一套角色矩阵划算得多。
之前有个运营离职，过了快两个月我才发现他的ERP账号还能登，平台后台的子账号也没关。那段时间我特别慌，因为不知道他有没有下载过什么东西，也查不出个所以然。
把“账号在哪”先列成一张清单，漏的根源基本都是清单不全。至少包括：各平台后台子账号、ERP账号、公司邮箱、浏览器环境或店铺登录环境、云盘和共享文档、以及跟收款相关的任何入口。
离职或外包结束当天做五步：禁用而不是直接删除（删除会丢日志）、把负责的店铺和待办转交出去、改掉所有共享密码、导出这个人最近30到90天的操作日志、重点看导出和下载记录。外包和代运营一律用限时账号，到期自动失效，别指望人工记得去关。
日常审计的口径也要改一改，只看“登录了没有”意义不大，真正有用的是查“导出了什么、改了什么价、动没动收款信息”，导出记录比登录记录更能反映风险。账号清单建议每月导出一次，跟在职人员名单逐条核对，日志保留时长按各自平台规则和合规要求确定，涉及跨境数据和个人信息的部分建议让法务确认后再定标准。
读者评论
我们团队15人管20多家店，看完最有共鸣的是“平台子账号和ERP权限要两头一起管”。之前一直以为ERP设了权限就安全，结果运营还能从平台后台直接改价，等于白设。回去就核对两边的权限映射。
权限颗粒度跟着风险金额走这个判断很实用。我们之前把权限做到按钮级，结果一单售后要走三次审批，效率掉一半，最后主管自己把审批关了。现在只盯价格、退款、导出这几类高风险动作，反而管住了。
文章提到权限问题有滞后性，这点太真实。去年一个客服离职后客户被挖走，查日志发现只保留30天早就过期了，根本追不到人。建议选ERP时把操作日志保留时长和导出记录当成硬指标问清楚。
五层权限模型里第二层“按角色授权不按个人授权”最值得抄。我们以前每次有人转岗就手动改一遍，漏配过好几次。后来改成角色模板，新人进来套模板，离职直接停用账号，交接清晰多了。