直接答案：多门店系统的核心矛盾是：总部要看得全，店长要管得动，员工只能看自己的。这三句话听着简单，做起来处处是坑——权限给宽了，员工能看到别家店的客户名单；给窄了，店长连自己店的报表都打不开；总部想看全量，结果被各种「数据权限」挡住。解决办法不是反复调权限，是先想清楚「谁能看什么、能改什么」。
核心结论速览
**权限不是「能不能进这个页面」，是「进去能看到哪些行」。** 功能权限和数据权限要分开设计。能看到「客户列表」这个页面是功能权限，能看到哪些客户是数据权限。只做前者，等于所有人都能看到全部客户。
**三层角色对应三种数据范围。** 总部看全部门店、店长看本店、员工看自己服务的客户。这三层之外的特殊需求（比如区域经理看几家店），用「角色 + 数据范围」组合实现，不要为每个岗位单独写一套逻辑。
**报表口径必须统一，否则数字对不上。** 同一家店，总部看到的营收和店长看到的营收不一样，通常是因为「含不含退款」「含不含储值」「按消费日还是收款日」。口径要在系统里定义一次，全站共用。
**店长能改的要有边界。** 改价、改提成、改库存、删记录——这四件事必须有明确的授权范围。授权不清，店长要么不敢动（效率低），要么乱动（风险高）。
**所有敏感操作要留痕。** 谁改了价格、谁删了记录、谁导出了客户名单，都要有日志。不是为了追责，是为了出问题时能查清楚。
一、权限设计最容易犯的五个错
错误一：只做功能权限，不做数据权限。系统里设了「客户管理」这个菜单，给了店长权限。结果店长打开，看到的是全公司所有门店的客户。因为系统只判断了「你能不能看这个页面」，没判断「你能看哪些客户」。这是最常见的漏洞。
错误二：用「角色」代替「数据范围」。设了「店长」这个角色，就默认他能看本店数据。但如果一个区域经理管三家店呢？只能再建一个「区域经理」角色，再写一套逻辑。角色越建越多，最后没人搞得清谁有什么权限。
正确的做法是把「角色」（能做什么操作）和「数据范围」（能看到哪些数据）分开。角色是「店长」，数据范围是「门店 A、B、C」，组合起来就是「能管这三家店的店长」。同一套逻辑可以覆盖所有岗位。
错误三：报表口径不一致。总部报表的「本月营收」包含了储值充值，店长报表的「本月营收」只算实际消费。两个数字差一大截，开会时互相质疑。这不是谁算错了，是口径没定义。
错误四：敏感操作没有留痕。某天发现一单价格被改成了 1 元，问谁改的，没人承认，系统也查不到。这类事情出一次，老板对系统的信任就没了。
错误五：离职员工权限没回收。员工离职了，账号还在，还能登录看客户名单。这类风险在人员流动率高的美业特别大。系统要支持「离职一键停用」，并且定期检查长期未登录的账号。
这五个错误里，前两个是设计问题，后三个是执行问题。设计问题要在系统建设时就解决，执行问题要靠流程和检查。两者都不能省。
二、三层权限模型怎么搭
第一层：功能权限（能做什么）。按「模块 + 操作」定义。模块有客户、预约、订单、库存、财务、报表、设置等；操作有查看、新增、编辑、删除、导出、审批等。每个角色对应一组「模块 + 操作」的权限点。
常见的角色划分：店长（全模块，本店数据）、技师（预约、客户查看、服务记录）、前台（预约、收银、客户建档）、顾问（客户、销售、跟进）、财务（订单、报表、退款审批）、总部管理（全模块全数据）。
第二层：数据范围（能看哪些）。这是最容易被忽略的一层。数据范围有四种典型配置：全部（总部）、本部门及下级（区域经理）、本部门（店长）、仅本人（技师、顾问）。
「仅本人」这个范围要特别注意。技师的「本人」指的是「我服务过的客户」，不是「我建的客户」。因为客户是门店的资产，不是技师的私产。但技师需要看到自己服务过的客户的历史记录，才能做好服务。这个界定要在系统里明确。
第三层：字段权限（能看到哪些字段）。同一行数据，不同角色能看到的字段不同。比如客户档案里，「手机号」对店长可见、对技师只显示后四位；「累计消费金额」对顾问可见、对技师不可见；「备注/黑名单标记」只对店长可见。
字段权限在美业很实用。技师不需要知道客户的消费总额，但需要知道客户的过敏史和禁忌；前台需要知道客户的联系方式，但不需要知道她的消费能力。按需给字段，既保护隐私也减少干扰。
三层的组合方式：角色决定「功能 + 字段」，数据范围单独配置。一个用户 = 一个角色 + 一个数据范围。特殊需求通过「多角色」实现（一个人可以有两个角色，权限取并集）。
一个实操建议：权限不要做成「默认全开、按需关闭」，要做成「默认全关、按需开启」。前者容易漏关，后者最多是不方便，但不会出事。安全的事情，宁可麻烦一点。
三、报表口径怎么统一
口径一：营收按「消费日」还是「收款日」。客户 1 月 30 日充了 5000，2 月 5 日消费了 800。这 5000 算 1 月营收还是不算？这 800 算 1 月还是 2 月？
通行的做法是分开算：「现金流」按收款日算（1 月有 5000 流入），「营业额」按消费日算（2 月有 800 营业额）。两个指标各自有意义，不能混。老板关心现金流，店长关心营业额，看不同的报表。
口径二：退款怎么扣。客户退款 1000，是冲减当月营收，还是冲减原订单所在月的营收？前者简单但会扭曲当月数据，后者准确但需要回溯。建议用前者（冲减当月），同时在报表里单独列一行「退款」，让读者知道当月有退款发生。
口径三：赠送金额算不算营收。充 5000 送 1000，营收是 5000 还是 6000？答案是 5000。赠金是营销成本，不是收入。客户用赠金消费时，营业额按消费金额算，但那部分对应的是「营销费用」而不是「收入」。这个区分在财务上很重要，在经营分析上也重要——如果赠金算营收，会高估实际收入。
口径四：跨店消费算谁的业绩。客户在 A 店买卡、在 B 店消费。B 店的营业额要不要算这单？要算（服务是 B 店提供的），但 A 店也有贡献（客户是 A 店开发的）。建议「营业额算服务店，业绩提成按内部结算规则分」。两个指标分开看，不要试图用一个数字表达所有信息。
口径五：人效怎么算。「人均产出」的分母是「在册人数」还是「实际出勤人数」？用前者会把请假的人也算进去，低估人效；用后者更准确但数据要求高。建议用「实际出勤工时」做分母，算「每工时产出」，这个指标跨店可比性最强。
口径要写下来。每个指标的定义、计算公式、数据来源、更新频率，写成一份文档，全公司共用。新店长入职先看这份文档。口径不写下来，每个店长都会按自己的理解算，数字永远对不上。
四、店长权限的边界在哪
能改的：本店的排班、本店的预约安排、本店的服务单备注、本店的库存领用、本店客户的常规跟进记录、本店员工的日常考勤确认。
不能改的：已完成的订单金额、已发放的提成记录、已核销的卡项、客户的历史消费记录、退款审批（需上级）、价格体系（需总部）、提成规则（需总部）。
需要审批的：超出授权范围的折扣、单笔退款、客户档案合并、储值卡的特殊处理（比如延期、转赠）、库存报损。
为什么要设边界：不是因为不信任店长，而是因为「改历史数据」这件事本身就是风险。今天的店长可能是明天离职的员工，历史数据一旦被改，事后无法还原。系统要做的是「让正常业务顺畅，让异常操作留痕」。
折扣授权怎么做：设「折扣区间」而不是「能不能打折」。比如店长可以打 9 折以内自主决定，8-9 折需要区域经理审批，8 折以下需要总部审批。分档授权比一刀切更实用——既给了店长空间，又控制了底线。
退款授权怎么做：按金额分档。小额（比如单笔几百元）店长可批，中等额度区域批，大额总部批。同时要能看到「这个店长的退款率」——如果某个人退款率明显高于其他人，要么是客户群体特殊，要么是审批太松，都值得关注。
一个容易被忽略的点：数据导出权限。客户名单是最敏感的资产。谁能导出、一次能导出多少条、导出要不要审批、导出记录要不要留档，这些都要管。很多门店的客户流失，就是从「员工离职前导了一份名单」开始的。
另一个点：临时授权。店长休假、区域经理代管，这时候需要临时授权。临时授权要设「有效期」和「自动失效」，不能给一个永久权限然后忘了收回。系统里「临时授权」应该是一个独立的功能，不是一个需要人工记得撤销的操作。
五、常见问题解答
小店需要这么复杂的权限吗？
不需要三层全上，但至少要分清「谁能看全部客户」和「谁只能看自己的」。两个人以下的店，老板全权限、员工只看自己服务的客户，这个最基本的划分就够了。随着门店和人员增加，再逐步细化。权限设计的目的是「不出事」，不是「做到最细」。
技师能看到客户手机号吗？
建议只显示后四位，需要联系客户时通过系统内的「拨号」功能（不显示完整号码）。这样既能联系，又不会把号码带走。如果门店规模小、信任度高，可以放开，但要清楚这是用信任换便利。
店长能不能看到其他店的业绩？
通常不能看明细，但可以看排名。比如「本店在全区排第 3」，这个信息能激励店长，又不泄露其他店的经营细节。如果要做跨店对比，用脱敏的方式（只给排名和百分比，不给绝对值）。
总部怎么防止店长做假账？
三个机制：一是关键操作留痕（改价、退款、删单都有日志）；二是异常指标预警（比如某店退款率突然升高、某店客单价异常低）；三是定期交叉核对（库存和消耗对、收款和订单对、考勤和排班对）。三个机制配合，做假账的成本会很高。
员工离职，客户归谁？
客户归门店，不归个人。这是基本原则，要写进劳动合同。但要做「平稳交接」——离职员工名下的客户，系统自动转给指定的接手人，并且给客户发一条通知（「您的服务顾问变更为 XX」）。不做交接，客户会觉得「我的人走了，这家店跟我没关系了」。
连锁和加盟的权限有区别吗？
有。直营店总部可以看全量数据、可以直接改价格；加盟店总部通常只能看汇总数据，价格和经营由加盟商自主。系统要能区分「直营」和「加盟」两种门店类型，给不同的权限模板。这一点在扩张期特别重要，一开始不区分，后面改起来很麻烦。
权限改了要不要通知员工？
要，而且要提前通知。权限调整往往意味着「某些事以后不能做了」，如果员工不知情，会以为是系统出故障。通知里要说明：改了什么、为什么改、什么时候生效、有疑问找谁。透明能减少很多误解。
六、九尾狐在这类问题上的做法
九尾狐在做美业多门店权限模块时，把「角色」和「数据范围」彻底分开。角色只管「能做什么操作」，数据范围只管「能看到哪些数据」，两者组合使用。这样新增一个岗位（比如区域督导）不需要写新代码，配一个角色加一个数据范围就行。角色和数据范围解耦，是多门店系统能长期维护的关键。
第二个做法是「报表口径统一在数据层」。所有报表都从同一套指标定义出发，不在每个报表里各写一遍 SQL。这样总部报表和门店报表的数字天然一致，不需要事后对账。口径定义写在一份文档里，改口径要改文档、改代码、同步通知，三个动作一起做。
第三个做法是「敏感操作全留痕」。改价、退款、删单、导出客户名单、修改提成记录，每一个动作都记下：谁、什么时候、改了什么、改前改后是什么、原因是什么。日志不可删除，只能查询。这个设计让「出问题时能查清」成为可能。
第四个做法是「临时授权自动失效」。跨店支援、代班、休假代管，都用「有效期 + 自动失效」的方式授权。不需要人工记得去收回，到期自动关。这个细节看起来小，但它是很多数据泄露事故的源头。
七、综上所述
多门店的权限设计，本质是在「效率」和「风险」之间找平衡。权限给得太松，数据会漏、账会乱；给得太紧，店长什么都干不了，业务跑不动。平衡点不是一次调出来的，是靠「角色 + 数据范围」这套结构，让调整变得简单——业务变了，改配置就行，不用改代码。而报表口径的统一，解决的是另一个问题：让所有人看同一套数字，讨论才有意义。数字不一致的会议，开的都是误会。