小型连锁的多门店设置：分店、员工与客户

多门店设置中常见的问题

小型连锁的多门店设置通常从一个简单的想法开始：一个系统给所有人用。当每个分店使用相同的界面、相同的列表和相同的按钮，但职责并不相同时，就会出现问题。

最常见的失败是可见性混杂。A 店的前台员工会看到 B 店的预约、笔记或发票；或者某位经理试图修复本地问题，却不小心更改了影响所有分店的全局设置。起初看起来方便，但很快就变成噪音和风险。

“每个门店只看到它应该看到的”原则很简单：员工只应看到与其岗位和门店相关的客户、订单、排班、库存和报表。如果有人同时在两个门店工作，他们应能看到两个门店的数据；如果某人是区域管理员，则应能看到全部数据，但那必须是你有意授权的结果。

当你不做任何限制（或依赖非正式规则）时，会出现几个可预测的问题：

• 员工因列表中包含其他门店记录而编辑错记录。
• 客户详情、笔记或付款状态在分店间泄露。
• 报表看起来错误，因为合并了不同门店的数据却没有清晰的过滤条件。
• 支援团队整天在回答“我为什么会看到这个？”和“我找不到它”的问题上卡住。

目标不是把一切都上锁，而是有意识地决定哪些数据共享、哪些数据隔离。许多连锁希望共享客户数据库（以便回头客任何门店都能识别），同时把本店数据如本地排班、内部笔记和员工绩效保留为门店专有。

如果你使用无代码构建器，最好在构建界面和工作流之前决定这些规则。否则你会在大家已经使用系统后才去修补权限问题。

需要先定义的核心要素

在构建屏幕、表单或报表之前，先就几个基本点达成一致，多门店设置会更稳健。跳过这些会让权限变得混乱，数据也会难以信任。

先为你的构件命名。大多数小型连锁需要分店（门店）、用户（员工账号）、角色（岗位类型）、客户（共享身份）和交易（订单、预约、工单、退货）。

接着决定哪些记录是全局的，哪些是门店拥有的。全局记录在公司内共享，例如客户档案、产品目录或公司定价规则。门店拥有的记录属于单个分店，例如日常现金报表、本地排班或门店库存盘点。

权限需要两个维度，而不是一个：

• 范围：一个人可以看到哪个门店或哪些门店。
• 操作：他们对可见记录可以做什么。

读取和编辑权限应分开。区域经理可能能读取所有门店的数据，但只能编辑自己门店的员工名册。前台员工可以读取客户档案，但只能为本店创建和编辑预约。

最后，决定报表如何工作。大多数团队既需要用于日常管理的门店绩效报表，也需要供业主与财务使用的跨门店汇总。早点统一这些规则，这样你不会构建出把数据混在一起令人困惑的报表。

如何在不受限的情况下建模分店

多门店设置从一个决定开始：在你的业务中，“分店”是什么意思？对一些团队来说是顾客光顾的零售门店；对另一些则是诊所、仓库或必须独立运作的加盟单元。

从明确定义开始

为分店选择一个明确含义并在数据模型中坚持它。如果以后需要部门或服务区域，应把它们作为独立概念加入，而不是把这些职责塞进分店记录里。

给每个分店一个稳定且永不更改的标识符，即便门店名称改变也不影响。短编码（如“NYC-01”）通常比用地址或名称作为主键更容易管理。

存储日常工作依赖的信息：分店代码与展示名、地址、时区（对营业时间、预约与报表至关重要）、营业时间（必要时含节假日覆盖规则）以及状态（例如启用、临时关闭或归档）。

然后决定员工与分店的关联方式。有些企业严格规定一人一店，另一些则让员工在门店间轮换。任一方法都可行，但会影响工单分配与记录过滤方式。

一个实用办法是把员工—门店分配建模为单独关系，以便支持一对多场景，而无需以后大幅重构。

让扩张成为非事件

把新增门店视为数据而非特殊情况。一个简单测试是：“我们能在不改动逻辑的情况下加入第7家门店吗？”理想状态下，新增门店只需创建新的分店记录、设置时区和营业时间，并分配员工。如果你发现需要修改很多规则，说明模型耦合得太紧。

员工访问：角色、范围与权限

清晰的权限设置始于一个理念：把“能做什么”（角色）与“能看到什么”（范围）分开。如果混在一起，你会不知不觉地给予“顺手”的权限，最终演变为过度共享。

多数小型连锁可以保持角色设置简单：业主、区域经理、门店经理、员工和支持。为每个角色定义默认权限并保持简单。针对每个领域（客户、预约或订单、库存、笔记、报表），明确“查看”“创建”“编辑”是什么意思，并标注哪些操作永远不应作为默认权限（例如导出或管理类变更）。

一个防止混乱的清单：

• 查看记录
• 创建新记录
• 编辑现有记录
• 导出或下载数据
• 管理操作（管理用户、更改规则、删除）

范围是锁定的第二部分。大多数团队只需要三种范围：仅本店、被分配的若干门店，或所有门店。门店经理可能有编辑权限但仅限本店；区域经理可能能查看若干门店，但只能编辑人事与排班。

在需要之前规划好例外。临时访问应自动到期，而不是依赖有人事后记得收回。培训账号应使用假数据或受限沙箱。承包商应获得最小范围，并默认不允许导出。

在不泄露的前提下共享客户

共享客户数据库常常是多门店设置的核心，但也是在门店间泄露数据的最快方式。决定什么是真正的“一个客户，处处通用”，什么应保留为本地信息。

共享数据通常包括客户档案（姓名、联系方式）、忠诚度等级和一些偏好设置（如“不接电话”或“偏好电子邮件”）。这些信息能让任何门店识别并一致地服务该客户。

与门店相关的数据应和门店绑定：到店记录、购买、预约、服务笔记以及像“仅限 A 店的 VIP”或“下周需跟进”的本地标签。把这些保留为本地数据可以减少噪音，防止员工看到不必要的详情。

设定清晰的查看规则

最简单的策略是：人人都能找到客户，但并非人人都能看到所有信息。

前台员工可能看到档案详情与联系方式，以及其所在门店的到店记录；经理可能看到跨店总览（例如历史消费总额）但看不到其他门店的详细笔记；总部或客服角色在必要时可查看完整历史以处理升级问题；营销人员能访问是否同意接收消息与分群信息，但不能看到私人服务笔记。

这样可让共享客户数据库发挥作用，同时不变成共享日记。

从设计上保护敏感字段

敏感数据（私人笔记、文件、投诉、医疗或法律细节）应与一般笔记分开，并放在更严格的权限后面。如果你存储文档，要明确谁能上传、谁能查看，以及查看是否限定为同一门店。

示例：客户在 A 店做发型，在 B 店购买产品。B 店的员工应能看到忠诚度与“对香精过敏”等偏好，但不应看到 A 店的详细投诉记录。

简单易行的数据分离模式

关键决策是按标签分离数据还是物理拆分数据。大多数小型连锁可以用一个数据库并配合明确规则保持简单。

模式一：一个数据库，所有记录含 BranchID

这是常见选择。订单、预约、库存盘点与员工操作都放在同一张表里，但每行包含 BranchID（或 LocationID）。这种方式支持共享客户、跨店报表和员工跨店覆盖。

模式二：每店独立数据库

这看起来“更安全”，但会增加日常成本。迁移要做多次，报表更难做，共享客户则成同步问题。

实用规则：

• 如果你需要共享客户、共享报表和灵活的员工覆盖，使用一个数据库并加 BranchID。
• 只有在法律或合同要求隔离时才采用独立数据库。

无论选择哪种模式，都要把门店过滤做成自动的。不要依赖每个界面或报表去记住过滤条件。把门店作为用户会话的一部分，在一个地方统一强制执行，这样每个列表和动作默认都有作用域限制。

另外为全局项与本地覆盖做准备。把定义放在全局（目录项、服务模板、定价规则），在需要时再添加可选的门店覆盖字段（门店特价、库存阈值、营业时间）。这样能避免为每个门店复制整套目录。

尽早添加审计轨迹。你需要回答“谁在何时哪里改了这个？”至少记录用户 ID、分店 ID、时间戳、动作（创建、更新、删除）以及敏感字段的前后值。

逐步操作：建立分店、权限与可见性规则

目标很直接：人们只看到他们需要完成工作的内容，其余不可见。最简单的方法是先决定什么是门店专有、什么是共享，以及员工如何在界面间流转。

实用设置步骤

在动手改数据库或应用构建器之前，先在纸上或简单表格里做规划。

1. 列出你存储的每种数据项（预约、订单、库存、员工笔记、客户档案），并标注每项为全局（共享）还是门店拥有。
2. 用通俗语言定义角色（前台、技师、门店经理、总部）。为每个角色写明门店范围：单一门店、被分配门店或所有门店。
3. 为共享客户设定规则：哪些字段跨店可见、哪些为本地。决定谁可以编辑共享字段。
4. 为员工与经理设计不同的界面和报表。员工视图应默认为“我的门店”。经理视图可包含筛选与对比功能。
5. 用不同门店的测试账号进行验证。做真实任务（创建预约、退款、更新客户、查看报表），确认系统阻止不该发生的操作。

别跳过测试。大多数权限问题只会在用真实角色快速完成日常工作时暴露出来。

常见错误与避免方法

大多数多门店问题不是重大失败，而是默认设置的小漏洞：悄悄泄露数据或阻碍员工工作。假定每个界面、报表和导出都需要门店规则。

报表与导出是常见漏网之鱼。团队在界面上小心地按门店过滤，然后导出“全部客户”或“上月销售”时不小心包含了其他门店的数据。把导出当作独立功能来对待，给予其专门的过滤与测试。如果某位员工在应用里看不到某条记录，他们也不应该能通过导出把它带走。

另一个问题是经理角色悄悄变成管理员。这通常在按界面归类权限而不是按风险归类时发生。经理可能需要处理退款、班次编辑或客户笔记，但不应该能创建用户、变更权限或设置分店。把“管理运营”与“管理系统”明确分开。

当你把所有东西都放进一套全局字段时，共享客户也会变得混乱。如果把仅限门店的笔记（如“在这里总是要求折扣”）写进全局笔记，就会造成过度共享。把共享客户事实与门店专有笔记分开存储。

缺乏审计轨迹会导致推诿与返工。当两个门店同时修改同一客户时，你需要能看到“谁在何时做了什么”。即便是简单的 created_by、updated_by 和时间戳也很有帮助。

最后，考虑会在门店间轮值的员工。如果你通过“移动”员工的方式来处理而不是赋予多门店访问，排班与可见性会出现问题。

早期需要纳入的实用修复项：

• 为每种数据类型写明规则：全局（共享）还是门店专有。
• 先按动作定义角色，再添加门店范围（单店或多店）。
• 在每个列表、报表与导出中内置门店过滤。
• 把门店笔记与共享客户数据分开存储。
• 记录变更（用户 + 时间）以追踪客户和订单改动。

上线前的快速检查

在向所有门店开放访问前，用测试账号模拟一天的工作。为每个门店至少创建一位员工账号，再创建一位区域经理。然后做日常操作：预约、下单、更新客户、跑报表。

用下面的清单捕捉最容易引起混淆的问题：

• 以门店员工身份登录，确认他们只能看到本店的订单、预约与任务。搜索、筛选与最近项不应暴露其他门店。
• 以管理多家门店的经理身份登录。他们应能查看多个门店，但编辑能力应限于被分配的门店。
• 在两个不同门店打开同一客户档案。姓名和联系方式应在各处一致，更新不应造成重复记录。
• 在管理或报表视图切换活动门店并比较总数。抽查几天：当你切换门店数字应随之变化，全部门店视图应等于各门店之和。
• 禁用某个员工账号并确认访问立即被撤销（含应用访问和任何管理或 API 路径）。

然后测试一个边缘情形：客户在 A 店购买，然后打电话到 C 店寻求支持。C 店的员工应能看到共享客户档案，但看不到 A 店的内部笔记或受限记录。

示例场景：一个客户，三家门店

想象一家有三家分店的小型沙龙：市中心、河畔和商场。他们共享一个客户名单，客户可以在任意门店预约，但每家门店保留自己的排班、员工和日常笔记。

Maya（市中心前台）打开系统。她只能看到市中心的日历、市中心员工和当日预约。她可以在全公司范围内搜索客户，但只看到基本档案信息：姓名、电话、过敏信息和忠诚度。她看不到河畔店的日程、员工绩效或私人笔记。

Alex（业主）登录后能看到三家门店的日历、按门店的营收报表，并能管理员工角色。Alex 也能批准大额折扣等例外。

Jordan 通常在市中心就诊，但本周在商场临时预约了剪发。商场签到时能看到 Jordan 的核心档案和服务历史（做了什么、何时、由谁完成）。服务完成后，商场把新服务记录到 Jordan 的历史中。市中心之后也能看到，以避免重复提问或推荐错误的后续服务。

结账时会出现一个棘手情形。Jordan 因等待时间长要求 30% 折扣。商场前台可以录入折扣请求，但不能直接超过 10% 的折扣。该请求会发给 Alex 审批。Alex 批准后收据更新，审计日志记录谁提出请求、谁批准。

敏感笔记处理方式不同。如果美发师添加私人笔记如“客户正经历医疗问题，做头皮护理需额外小心”，只有美发师和业主能看到。前台员工只看到较安全的标识如“需要特殊处理”，而看不到详细内容。

使此流程可行的是一组清晰的规则：排班与员工为门店范围、共享客户的基础信息、受限的敏感笔记以及折扣的审批限制。

下一步：将规则写下来、测试访问，再开始构建

只有当你的规则被记录并像功能一样被测试，多门店设置才能保持整洁。把“谁能看什么”的决定写成简短句子。

目标是 10 到 15 条简短声明，覆盖日常场景：预约、客户档案、支付、退款、笔记和报表。例如：

• 员工只能查看本店的客户与订单。
• 客户的联系方式对所有门店可见，但笔记为门店专有。
• 经理可查看门店报表；只有业主能查看全公司汇总。
• 退款需经理批准并且必须在同一门店完成。
• 只有总部能编辑价格表与全局设置。

决定哪些界面和报表必须始终默认使用门店范围。如果某个界面可以显示所有门店，把它设为显式筛选而非默认。一个好的测试是：收银员会不会在不经意间打开另一家门店的日营业报表？如果有可能，就收紧默认设置。

用真实角色而非管理员账号测试。创建三种测试用户（收银、经理、总部）并按照真实流程走一遍：客户先在 A 店打电话、下周到 B 店就诊、然后在 C 店要求退款。确认各方只看到他们需要看到的信息。

安排月度权限检查以防止权限漂移：新增角色、岗位变动、新门店和报表访问权限的逐步扩张。

如果你正在构建自定义内部工具，AppMaster (appmaster.io) 可以帮你在同一平台上为分店、角色和业务规则建模，然后在需求变化时重新生成干净的代码，从而在你扩张时保持权限规则一致。