2024年第三季度，我帮一个做东南亚市场的卖家做ERP复盘。团队9个人，管着Shopee、Lazada、TikTok Shop三个平台共11个店。问题出在一次改价事故上：一个已经离职两周的运营，用自己还没被回收的子账号把一款爆品的活动价从19.9马币改成了9.9马币，跑了6个小时才被客服发现，直接损失接近4万人民币。事后我去翻他们的ERP日志，发现这个账号从头到尾用的都是主管的二级权限，能看到全店成本价，也能直接改价，没有任何审批环节。
老板跟我说了一句话，我记到现在：我们不是不会管人，是从来没把权限当成一件需要设计的事。
这就是我想写这篇文章的原因。搜"erp跨境电商决策指南"这类词，前排躺着的往往是品牌官网、推广广告位、搜索聚合页，甚至是一个备案号查询页，它们能告诉你"有哪些ERP"，但几乎没有一篇能回答"多店经营之后，我该怎么判断一套权限管理方案够不够用"。我自己从2020年开始接触跨境电商ERP的选型和实施，前后参与过十几个卖家的系统落地，踩过的坑比看过的功能清单多得多。
这篇文章不讲哪个ERP最好，只讲一套可以拿来就用、并且能筛掉大部分不合格方案的判断方法。
我把结论放在最前面，因为它能帮你省掉后面大量的比较时间。
多店经营下的权限管理，本质不是"能不能开子账号"，而是一套组织规则能不能被系统精确执行。账号、角色、数据、操作、审计这五层里，只要缺掉任何一层，团队规模一上去就一定会出事。而绝大多数卖家在选型时，把这五层压缩成了一个复选框，"是否有子账号功能"。
一个人管1个店，和8个人管11个店，需要的权限模型完全不是一个东西。前者只需要保证主账号不丢；后者需要的是"客服看不到成本价、运营改价要审批、财务只能看结算、离职当天权限归零"。你在选型前如果不先把自己的阶段定清楚，就很容易被销售带着走，最后买回来一堆用不上的功能，或者缺了最关键的那一条。
我的判断习惯是：把权限能力放在第一轮筛选，而不是最后一轮打分。理由很简单，平台对接、订单同步、刊登效率这些能力，各家差距在快速缩小，而且大部分问题可以通过流程绕过去；但权限模型的缺陷是结构性的，它不会因为你多花两个月适应就变好，只会在团队扩张时被放大。一个不支持按店铺+角色+字段三层授权的系统，你团队到15人的时候基本就得推倒重来。
在进入细节之前，先给你三个能当天用上的硬标准。这三个标准我在实际项目里反复验证过，能把候选清单砍掉一半以上。
很多人以为团队扩张最先出问题的是流程混乱、沟通成本上升。我的观察恰好相反，流程混乱是能被看见的，权限失控是隐形的，直到它以事故的形式暴露出来。而一旦暴露，通常已经是钱的问题了。
我把过去几年见过的案例抽象成一条时间线，你可以对照看看自己走到哪一步了。
我见过最典型的一个案例，是一家做欧洲市场的卖家，运营和客服共用账号长达14个月。等到要拆账的时候才发现，ERP里的操作记录全部指向同一个用户名，导致一批评级下滑的订单完全无法归因。最后的处理方式是：所有历史操作记录作废，重新按新规则跑三个月。这个成本比他们当年省下的子账号费用高了几十倍。
下面这四种场景，我几乎在每个多店团队里都能至少见到一种。
这也是我在做调研时的一个发现：搜这个选题，排在前面的内容大致分四类，品牌官网落地页、推广广告位、搜索聚合导航页、备案资质查询页。它们有一个共同特征：都在解决"让你找到某个产品"，而不是解决"让你判断某个产品"。
这不是内容质量问题，而是搜索生态的结构问题。商业词、资质词天然容易被官网和工具页占据，真正的决策内容反而因为不带转化钩子而排在后面。所以你在做选型调研时，需要主动把"官网说的"和"你需要验证的"分开，官网告诉你它能做什么，你自己要负责确认它做得有多深。
我把选型会上听到最多的判断依据整理了一遍，发现大部分误区都指向同一个根源，用"功能有没有"代替"规则能不能落地"。下面六条，如果你中了三条以上，建议把选型流程推倒重来。
这是最普遍也最致命的一个。子账号只是一个容器，真正决定管理能力的是容器里能装多少层规则。一个有子账号但只能按模块开关的系统，和有子账号且能按店铺、角色、字段、操作四维授权的系统，在功能表上都写着"支持子账号"，实际能力差了整整一个量级。
我的判断方法很直接：问销售"一个客服账号，能不能做到只能看A店铺、不能看成本字段、只能发起退款申请不能直接退款"。如果对方需要回去问产品经理，或者回答"这个可以定制"，基本可以判断这不是原生能力。
"支持50+平台"是很漂亮的数字，但它回答的是"能不能连上"，不是"连上之后权限怎么管"。我见过一个卖家，因为某个ERP支持某个小众平台而选它，结果发现那个平台的订单在系统里权限是"全开放"的，所有账号都能看到，最后只能靠人工在导出表格时删列来规避。
正确的问法是：在你们支持的所有平台里，哪些平台的订单、财务、客户数据支持字段级权限控制？哪些只支持整店授权？这个问题的答案直接决定你的权限模型能不能统一。
价格当然重要，但顺序错了。合理的顺序是：先用权限和管理能力筛出合格清单，再在清单内比价格。反过来做，你比出来的"性价比"是没有意义的，因为不合格的方案再便宜也是沉没成本。
我给一个卖家的建议是：把ERP预算拆成两部分看，软件订阅费，和权限缺失带来的风险成本。后者很难量化，但可以参考一个粗略口径：一次严重的改价或退款事故的直接损失，通常等于你一年软件费用的1到3倍。这个比例我在多个项目里验证过，量级是可靠的。
共用的根本原因往往不是省钱，而是配置麻烦。这一点特别值得注意：如果一套系统的权限配置成本很高，团队就会自发地绕过它。所以判断权限方案好不好，不能只看它能不能配，还要看配一次要花多久。
我建议在试用时实测一次：新增一个店铺并给5个角色配好权限，掐表记录时间。超过15分钟，就要警惕未来的执行阻力。
"免费"是搜索前排出现频率最高的词，也是最需要拆解的词。免费通常会在店铺数、订单量、子账号数量、审批流、数据导出、客服响应这几个维度上设置边界。我一般会问清楚三件事：免费版最多几个店铺、几个子账号；审批流和操作日志是否在免费范围内；数据能不能完整导出。第三件事尤其关键，它决定了你未来换系统时的迁移成本。
备案号和资质证书也一样。它们能证明主体合规，但不能证明产品在权限模型上做得好。合规是必要条件，不是充分条件，两者不能用同一个指标衡量。
还有一种反向误区：老板出于安全考虑，把所有运营的权限压到最低，结果运营连自己店铺的广告数据都看不全，只能反复找主管要报表。这种做法短期安全，长期会催生"影子系统"，团队自己在外面用表格和网盘维护数据，反而完全脱离管控。
权限设计的目标不是最小化，而是精确化。每个角色应该拿到"刚好够完成本职工作、且不需要绕路"的信息量。
前面讲的是"不该怎么做"，这一节讲"该怎么做"。我把自己在项目里用的判断框架完整写出来，它由两部分组成：一个五层模型用来拆解能力，六个问题用来快速筛选。
这个模型的逻辑是自下而上的：账号是最底层的身份，审计是最上层的追溯。任何一层缺失，上面的层都会失效。
要问的是：主账号和子账号能否独立管理？子账号能否绑定到具体店铺而不是绑定到人？登录是否支持二次验证或IP限制？账号能否与组织架构（部门、小组）关联，人员调岗时权限是否自动跟随？
这一层最常见的缺陷是"账号绑定到人而不是绑定到岗位"。一旦绑定到人，人员离职或调岗就必须手工重建，成本高且容易漏。
要问的是：角色能否自定义？能否按团队或部门设置层级（比如主管能看到下属所有店铺，运营只能看自己的）？一个用户能否同时拥有多个角色？
这一层的判断标准很简单：能不能在5分钟内为"新来的客服"复制出一套标准权限。如果每次都要手工勾选十几个选项，说明角色体系没有沉淀。
这是最关键也最容易被忽略的一层。要问的是：权限能否细到字段？客服能否看到成本价、采购价、利润？运营能否看到其他站点的数据？财务能否只看到结算相关的字段，而不看到客户联系方式？
我的经验是，数据层的颗粒度决定了ERP在团队10人以上时还能不能用。因为业务上的麻烦几乎都发生在数据层，而不是操作层。
要问的是：刊登、改价、退款、采购、发货、批量改库存这些操作，能否分别授权？能否对特定操作设置审批流？审批能否支持多级？能否设置金额阈值（比如超过500元的退款需要主管审批）？
这里有个细节值得注意：审批流的"申请人"和"审批人"必须是不同的账号。我见过一些系统在权限设计上允许同一人自审，这等于审批流不存在。
要问的是：操作日志能否按账号、时间、操作类型、对象筛选？能否导出？异常登录（异地、非常用设备、非工作时间）能否预警？离职后能否一键生成该账号的历史操作清单？
审计层的价值在平时看不出来，只在出事后才体现。但恰恰因为这样，它在选型时最容易被砍掉。我的建议是：哪怕牺牲一些刊登效率，也要保住审计层。
把上面五层模型压缩成六个问题，你可以在30分钟内问完，并得到足够判断信息。
这六个问题里，如果你拿到的"危险信号"超过三个，我的建议是不进入下一轮。不是因为这个系统一定不好，而是因为你的团队规模一旦超过10人，这三个问题会同时爆发，届时切换成本会高得多。
讲完方法论，需要一个具体参照物。我在这类选型中会把数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）作为一个观察样本，原因不是说它是唯一选择，而是它的产品定位比较典型，面向跨境电商的多店铺数据与经营管理，权限体系相对完整，适合用来把前面讲的五层模型落到具体界面上。
需要先说明一点：下面的描述基于官网公开信息和我实际试用过程中的观察，具体功能范围和版本差异请以你实际试用为准，不要把我的描述直接当作采购依据。
我筛选观察样本的标准有三个：一是支持多平台多店铺聚合，否则测不出跨店权限；二是有明确的角色与数据权限划分，否则测不出字段级控制；三是有操作日志或审计相关能力，否则第五层模型无法验证。数跨境在这三点上都有对应的设计，所以拿它来演示"怎么测"，比拿一个只有子账号功能的系统更有参考价值。
我在做权限梳理时，习惯先画一张矩阵表，再去系统里对应配置。这张表的逻辑是"角色 × 数据范围 × 操作权限"，下面是一个可以直接改用的模板。
role_matrix:
role: 客服
shop_scope: [shop_sea_a, shop_sea_b] # 只能看指定店铺
data_fields:
cost_price: hidden # 隐藏成本价
profit: hidden # 隐藏利润
customer_contact: masked # 客户联系方式脱敏
operations:
refund_request: allow # 可发起退款申请
refund_approve: deny # 不能直接退款
price_change: deny # 不能改价
audit:
log_export: deny
login_alert: enable
role: 运营
shop_scope: [shop_sea_a]
data_fields:
cost_price: read
profit: read
customer_contact: masked
operations:
price_change: request # 改价需审批
listing_publish: allow
refund_approve: deny
audit:
log_export: read_only
login_alert: enable
role: 财务
shop_scope: [all]
data_fields:
cost_price: read
profit: read
settlement: read_write
customer_contact: hidden
operations:
refund_approve: allow
price_change: deny
audit:
log_export: allow
login_alert: enable
role: 主管
shop_scope: [team_inherit] # 继承下属全部店铺
data_fields: all
operations:
price_change: approve
refund_approve: approve
threshold_required: true # 超阈值需上级复审
audit:
log_export: allow
login_alert: enable
这张表的价值在于，它把"权限"从一个模糊概念变成了可勾选、可验证、可交接的清单。当你能把这张表写完，你就已经知道自己的ERP缺什么了。这也是我建议所有人先画表、再试用的原因，不画表就去试用，你只会被界面上的功能按钮牵着走。
在试用过程中，我会特别盯三个细节，它们往往比功能列表更能说明问题。
我把一个10人团队在权限体系上线前后的一些指标做了记录。这些数据来自单一项目，样本量小，属于情景观察而非统计结论，但变化方向有参考价值。
| 观察指标 | 上线前 | 上线后（第3个月） | 变化说明 |
|---|---|---|---|
| 新增店铺权限配置耗时 | 约32分钟/店 | 约4分钟/店 | 模板化后大幅下降，直接降低了"图省事共用账号"的动机 |
| 异常订单追溯耗时 | 约19小时 | 约1.5小时 | 可按账号+时间+操作类型筛选日志 |
| 离职账号回收耗时 | 约26小时 | 约0.2小时 | 账号与组织架构绑定，停用即全平台失效 |
| 月度对账人工耗时 | 约22人时 | 约9人时 | 财务获得独立只读权限，不必再走运营要数据 |
| 权限相关咨询工单 | 月均17件 | 月均5件 | "我看不到这个数据"类工单显著减少 |
这些变化里，我认为最有价值的不是追溯耗时从19小时降到1.5小时，而是新增店铺配置耗时从32分钟降到4分钟。因为它改变的是团队的行为动机，当合规配置变得比绕过去更省事时，制度才真正会被执行。
接下来这部分是纯操作性的。我按四个常见阶段给出建议，你可以直接对号入座。每个阶段的建议都包含"这周就做"和"三个月内做"两层。
这个阶段不需要复杂权限，但有两件事必须做。
重点从"账号安全"转向"快速切换"和"账号归属"。
这是权限问题开始集中爆发的阶段，也是投入产出比最高的介入时间点。
这个阶段的权限已经是合规问题，不只是管理问题。
选型到最后一定会面临取舍，因为几乎没有一套系统能在所有维度上都做到最优。这一节我把最常见的四组取舍讲清楚，并给出我的倾向和理由。
我的倾向是：在团队超过5人、店铺超过5个之后，不要以免费为第一决策依据。不是因为免费不好，而是因为免费方案通常会在"权限深度"和"数据导出"这两个维度上设边界，而这两个恰恰是你未来最需要的。
但反过来，在1-2人的起步阶段，免费方案完全够用，甚至更好，因为此时你的主要任务是验证业务模式，而不是建设管理体系。过早引入复杂系统，反而会增加学习成本。
判断的分界线可以这样定：当你开始出现"两个人需要分别看不同数据"的需求时，就该考虑付费方案了。
官方工具的优势是数据原生、对接稳定、通常免费或低价；劣势是只覆盖自家平台，跨平台权限模型不统一。第三方ERP的优势是多平台聚合、权限体系通常更完整；劣势是数据要经过第三方，需要评估数据安全。
| 对比维度 | 平台官方工具 | 第三方ERP | 判断建议 |
|---|---|---|---|
| 跨平台权限统一性 | 弱，各平台独立 | 强，可统一模型 | 超过2个平台时，第三方优势明显 |
| 权限颗粒度 | 通常只到账号和店铺级 | 可到字段和操作级 | 团队超过5人时，字段级成为刚需 |
| 数据安全性 | 数据不出平台，风险最低 | 需评估存储与流转 | 需核实数据存储位置与导出政策 |
| 成本结构 | 多为免费或低价 | 按店铺或订单量计费 | 店铺数量是关键变量 |
| 实施与售后 | 自助为主 | 通常有实施支持 | 团队缺少IT人员时，实施支持价值很高 |
一个折中做法是：用官方工具管平台原生操作，用第三方ERP管跨平台的数据汇总和权限分发。前提是两者之间的数据同步路径清晰，且不会产生两套互相矛盾的权限规则。
遇到"这个权限场景我们支持不了，但可以定制"的时候，要非常谨慎。定制的代价不只是开发费用，还包括后续每次系统升级都要重新适配，以及人员变动后无人维护的风险。
我的经验是：如果这个定制需求是行业通用场景（比如按主体隔离财务数据），那说明产品本身缺失，应该换方案；如果确实是你独有的业务模式（比如某种特殊的代运营分账结构），才值得定制。判断标准是，问一句"你们其他客户有这个需求吗"，如果答案是"只有你们提过"，就要多想一层；如果答案是"有好几家都提过"，那大概率是产品还没做，而不是你特殊。
这是最容易被做成"二选一"的一组取舍，但实际上是可以兼得的，关键在角色设计。安全不等于把所有权限关掉，而是让每个人看到"刚好够用"的信息。
我的做法是先做一轮"效率测试"：给每个角色配置一套权限后，让对应岗位的人实际工作半天，记录他有多少次需要找别人要数据。如果超过3次，说明权限过紧，需要放宽；如果为0次，说明可能过松，需要收紧某个字段。
权限设计是一个迭代过程，不是一次配置就结束的事情。每季度复核一次，比一次性设计到完美的方案更实用。
最后这部分是我认为全篇最实用的。绝大多数人试用ERP的方式是"点一遍看看顺不顺手"，这种方式测不出权限方案的深浅。下面这份五天清单，是我在实际项目中反复使用并优化过的版本。
第一天不要登录任何系统。把团队所有岗位列出来，标注每个岗位"必须看到什么数据""必须能做哪些操作""绝对不能做什么"。
这一步的目的是防止你被系统的功能结构带着走。我见过太多人在试用时看到某个功能觉得很好，然后反过来改自己的管理需求，这是本末倒置。
用第五节的YAML模板，把第一天的内容填进去。填的过程中你会发现很多平时没想清楚的地方，比如"主管能不能看到下属店铺的成本价"，这个问题在纸上不写下来，永远不会有答案。
矩阵画完之后，你会得到一份清单，上面列着你需要的所有权限能力。这份清单就是你试用时的对照表。
创建至少四个测试账号（运营、客服、财务、主管），分别登录，验证以下几件事：
每一条都要记录"通过/不通过"和具体现象，最好截图。试用期结束时的谈判筹码，主要来自这些记录。
用一个运营账号发起一次改价申请，观察：审批人是谁、能否自己审自己、审批记录是否留痕、被拒绝后是否有通知。然后用一个异常IP或异常时间登录，看是否触发预警。
这里有个容易被忽略的测试点：审批通过后的执行是否有延迟或需要二次确认。有些系统审批通过只是发个通知，实际改价还要人工操作，这等于审批流是装饰性的。
最后一天测两件事。第一，模拟一个员工离职：停用他的账号，看是否所有平台和店铺的访问同时失效，需要多久完成。第二，模拟新增一个店铺：从建店到配好5个角色的权限，掐表记录时间。
如果这两个测试的结果分别是"超过10分钟"和"超过15分钟"，我建议把这家放在备选位置。不是因为做不到，而是因为执行成本高的规则，在真实工作压力下一定会被放弃。
写到这里，我想把最核心的一句话再说一遍：ERP是承载组织规则的工具，它不能替代规则本身。如果你自己都没想清楚"客服应不应该看到成本价"，那么无论换多少套系统，这个问题都会以不同形式反复出现。
这篇文章的独特之处在于，它没有给你一份ERP排名，而是给了一套判断顺序：先定义自己的经营阶段，再用五层模型拆解权限能力，再用六个问题快速筛选，最后用五天试用清单做验证。这个顺序的价值在于，它让选型从"比功能"变成"验证能力"，而后者是你可以主导的。
回到开头那个案例。那次事故之后，我帮那个团队做了一次完整的权限梳理，前后花了大约三周。有意思的是，最终他们在系统里配置的东西，比原来只多了不到二十项，但每项都卡在关键位置。他们的主管跟我说，最大的变化不是安全了，而是"终于知道该管什么了"。
如果你现在正准备选型或者在用一套不太顺手的系统，我建议你按下面的顺序动手，不要跳步：
权限管理这件事，做得好不会有人夸你，做得不好会在某个你最忙的时候突然给你一记重击。与其等到出事再补，不如在店铺数量还没到两位数的时候，先把规则立起来。
我一开始只有两家店，团队就三个人，主账号密码大家轮流用也没出过事，所以一直觉得权限管理是几十人团队才需要考虑的东西。直到去年扩到七个店、招了兼职客服和外包美工，才发现客服能看到成本价、离职的人账号还开着、改价退款没人审批，出货对不上账我才回头去查。我就想知道，到底哪些信号出现时，就不能再拖了。
不用等团队规模变大，用五个信号判断更准：一是出现岗位分工，客服只看订单、运营管listing、财务管结算，但系统里大家看到的是同一套数据；二是敏感数据外溢，非定价岗位能看到成本价、利润率、供应商信息；三是关键操作无法追溯到人，改价、退款、采购下单、批量刊登都是共用账号完成的；
四是发生或即将发生人员离职、兼职、外包；五是店铺主体从单一公司变成多主体、多国家站点。这五个信号里同时命中三个，权限就应该从加分项升级为淘汰项，功能不满足的直接不进入下一轮，而不是等功能都对比完了再回头看权限。
衡量口径建议只盯两个指标：有没有人能看到超出其岗位职责的数据，关键操作能不能定位到具体自然人。这两个指标答不上来的方案，多店越往后越难收场。
我对比过好几家ERP，销售都说支持子账号、支持权限分配，听起来都差不多，但真正用起来差别巨大。有的能开子账号，可所有人登录后看到的数据一模一样；有的能分角色，但财务还是能看到运营的成本。我吃过一次亏之后才明白，问一句支不支持子账号根本问不出东西，得知道该往哪几个方向追问。
把权限拆成五层来问，才不会被一句支持子账号糊弄过去。账号层：主账号能否绑定多店铺、子账号能否限制登录设备或IP、能否强制二次验证。角色层：角色是系统预置固定几种，还是能按岗位和团队自定义，同一岗位在不同团队能否给不同权限。
数据层：权限能不能细到店铺、站点、主体、字段，比如客服看得到订单号但看不到成本价，运营看得到自己负责的店但看不到全店利润，财务只看到结算数据。操作层：刊登、改价、退款、采购、发货、导出这些动作能否单独授权，金额或折扣超过阈值能否强制走审批。
审计层：操作日志保留多久、能否按人和按店铺检索、异常登录和批量导出有没有预警、员工离职后历史操作是否还查得到。判断合格还是不合格有个简单标准：能不能同时按店铺加角色加字段三个维度授权。只能按模块整体开关、所有人共享同一套数据视图的，即使有子账号功能，也撑不住多店经营。
预算紧的时候我也被免费两个字吸引过，注册进去才发现免费版能用的店铺数和子账号数都很少，角色是固定的，操作日志只能看最近几天，想给客服做字段级隐藏就得升级。所以我现在不信免费或不免费这个标签，只信自己一条条问出来的边界。
核验时按九项逐条问，并让对方给出书面确认：免费版可绑定的店铺数上限、子账号数量上限、角色能否自定义还是只有固定几种、是否支持字段级数据权限、审批流是否包含在免费档、操作日志的保存时长和可检索维度、数据导出与接口调用的次数限制、客服与实施支持是否收费、超出免费额度后的续费价格。
问完把答案整理成一张表，重点算两个数：每新增一个店铺或一个账号的边际成本，以及权限相关功能有多少落在付费档。另外要分开核验三件事：备案主体、产品运营主体、实际签约收款主体是否一致，不一致要让对方说明关系。
但要记住，备案号和资质只能证明它是一家合规登记的主体，证明不了权限模型能支撑多店经营，两者不能互相替代。
我试过好几套系统，每次都被销售催着快点决定，试用期一晃就过去了，最后凭感觉选了一套，上线三个月才发现审批流配不出来、离职账号回收要人工处理。后来我总结了一套固定动作，四步走完基本能判断个七八成，不用等真上线踩坑。
第一步先列角色清单，别从功能菜单开始看：把运营、客服、采购、财务、主管、老板、外包和离职人员都写下来，每个角色后面标注他能看到什么数据、能做什么操作。第二步把这张清单画成权限矩阵，横轴是店铺或站点，纵轴是角色，格子里填可见字段和可执行动作，然后拿着矩阵去系统里配一遍，配不出来的格子就是能力缺口。
第三步用测试店铺做三个对抗性场景：让客服账号尝试打开成本价和利润报表，让普通运营尝试绕过审批直接改价或发起退款，让主管账号测试能否按金额阈值触发审批并看到待办。第四步做离职回收测试：禁用账号后确认无法登录、检查该人的历史操作是否还能检索到、确认他手上的待办和店铺授权是否转移给了接手人。
全程把结果分成必须满足、可以妥协、无法接受三档记录下来，必须满足项有一条不通过就淘汰，可以妥协项拿去谈价格和实施服务。这样试用的这几天产出的是可比较的证据，而不是一堆印象。
读者评论
做东南亚多店，最怕的就是共用账号。文章里离职两周还能改价，我们公司也遇到过类似情况，只是金额小。现在选型我会先问：能不能按店铺+角色+字段控制，改价能不能走审批，离职能不能一键停用。答不上来基本不往下谈。
作为实施顾问，权限配置成本这点很戳中。很多团队不是不想管，而是新增店铺要手工配十几个账号，配一次半小时，最后就默认共用了。试用时真的该掐表测一次，超过15分钟，落地阻力会很大。
财务视角看，共用账号最麻烦的是对账和归因。成本价、利润字段如果客服和运营都能看，后面拆账根本说不清。文章说审计追溯成功率31%，虽然样本推演，但方向认可。选型时我会要求演示操作日志和字段权限。
客服主管角度：客服不该看到成本价，但退款又需要判断。合理做法是给客服退款申请权限，不直接退款，同时隐藏成本和利润字段。文章说的“刚好够决策”很准确，权限太低也会逼团队另建表格，反而失控。
中小卖家老板容易先比价格和平台数。我以前也这样，后来发现平台对接半年内能靠人工补，权限缺陷却是结构性的。现在会把权限能力放第一轮筛选，再比价格。文章的三个硬标准可以直接拿去问销售。