宁波连锁门店多店小程序：一套后台如何管理各分店权限与数据

开三家店和开一家店，小程序后台的设计思路完全不同。单店小程序只要管好商品和订单就行，多店小程序第一件要定的事是：谁有权限看什么、改什么、导出什么。这件事没提前想清楚，上线后店长互相看到对方营业额、店员误改别店价格的情况几乎一定会出现。

先定角色，再谈功能

多店小程序的后台通常至少有三层角色：总部运营、门店店长、普通店员。每层的权限边界要在需求阶段就写进清单，而不是等开发完再补。

• 总部运营：全部门店的商品、订单、会员、优惠券、数据报表，重点是能跨店对比和统一改价。
• 门店店长：只看本店订单、本店核销、本店库存和本店员工业绩，可以改本店营业状态和接单开关。
• 普通店员：只做核销、接单、简单查询，不涉及价格和库存修改。

这里最容易漏的是「店长能不能看到别店数据」这个开关。有的系统默认店长可以看全部门店，结果门店之间互相摸底，总部反而不好管理。建议初期默认只看本店，跨店数据权限单独申请。

数据隔离怎么做才算干净

多店小程序的数据隔离，落地时主要看三个层面：订单归属、会员归属、商品与价格归属。

1. 订单归属：用户扫码进的是哪家店，订单就落在哪家店，退款和核销都归该店处理。要确认系统是否支持按门店筛选订单，而不是混在一个列表里。
2. 会员归属：连锁品牌常见做法是会员全品牌通用、积分通用，但消费记录按门店拆分。也有品牌做会员归属门店，这取决于你是想做统一会员还是门店私域，两种模式的后台结构不一样，要在合同前明确。
3. 商品与价格：总部统一建商品库，门店可以选择上架哪些、是否可以单独调价。如果门店有独立定价权，后台要支持门店级价格，否则店长会绕过系统手动改价。

需要注意的是，数据隔离不是越细越好。隔离层级越多，后台操作步骤越多，店长培训成本越高。比如一家做社区团购的连锁，如果每个团长都要独立看数据，后台角色就会变得很复杂，通常建议按区域或按门店两级管理，不要一层层往下切。

多店场景里常见的三个权限坑

从实际项目看，多店小程序上线后反馈最多的问题集中在权限上，而不是功能本身。

• 核销权限没分店：店员在A店核销了B店的券，财务对账时找不到责任人。后台要支持核销记录带门店字段。
• 店长能改总部商品：商品库权限没锁死，店长改了全连锁共用的商品名称或价格，影响所有门店。总部商品和门店商品要分开管理。
• 数据导出不设限：店长可以导出全部会员手机号，这在连锁体系里是明显的管理漏洞。导出权限建议只开放给总部或区域负责人。

这些问题不涉及多高深的技术，但需要在需求清单里逐条写清楚，并在验收时逐条测试。合同里只写「支持多门店管理」是不够的。

多店权限对开发预算的影响

多店小程序的预算差异，主要不在页面数量，而在后台角色和数据结构的复杂度。具体来说：

• 角色数量：三层角色和五层角色的后台，开发工作量差别明显，测试用例也要成倍增加。
• 数据隔离层级：门店级、区域级、总部级三层隔离，比单纯门店级要多做不少筛选和校验逻辑。
• 对接系统：如果已有收银系统或ERP，多店数据要同步，接口对接会拉长工期。
• 报表需求：跨店对比报表、门店排行、员工业绩统计，这些通常不在基础版里，要单独确认。

所以问价格之前，先把门店数量、角色层级、是否需要区域管理、有没有现成系统要对接这四件事列出来，报价才有可比性。同样叫多店小程序，需求差一倍，价格差一倍也正常。

落地建议：先跑通一间店再加第二间

多店小程序不建议一上来就全部门店同时上线。更稳妥的做法是：

1. 先选一家门店做试点，把总部和店长的权限流程跑一遍，确认订单归属、核销记录、数据查看都符合预期。
2. 试点两周后整理权限清单，把店长日常真正会用到的操作列出来，删掉那些「设计了但没人用」的权限，后台越简单越容易推下去。
3. 第二家店上线时重点测试跨店场景，比如会员在A店办卡、在B店消费，积分和记录是否正确落到对应门店。
4. 全部上线后固定一份权限变更流程，谁申请、谁审批、谁操作，避免店长离职后账号还挂在后台。

连锁多店小程序的核心不是功能多，而是权限边界清楚、数据归属明确、后台操作足够简单。把这三件事在开发前定下来，后面的运维会省很多事。