客户小程序
服务浏览、服务对象、预约支付、订单跟踪、次卡、租赁与评价。
助浴服务连锁经营平台 · 重构方案
把「算不清、时间乱、不好用」从结构上解决掉
这不是一次界面翻新，而是围绕预约履约、资金次卡和多门店经营，重新搭建可持续扩展的业务底座。
01 · EXECUTIVE SUMMARY
执行摘要
现有系统已经把业务跑通，但核心模型无法继续支撑准确核算、稳定履约和合作伙伴扩张。本次重构的重点，是让混乱在数据结构上不再发生。
账可追每笔收付只追加、不覆盖，次卡销售与核销分开核算。
时间清下单、计划、改期、实际服务四类时间各自独立。
流程短建档与下单拆开，首次预约只填写完成交易所需的信息。
产品判断：重做核心业务底座，承接可核验的数据；不沿用现有页面和旧数据模型，也不承诺还原旧系统从未记录的财务事实。
本期首先交付什么
- 客户、服务对象、员工、订单、服务项目、派单与服务执行的主流程。
- 统一资金流水、次卡核销、成本原始数据与基础经营报表。
- 合作伙伴隔离、门店归属、角色权限等 SaaS 结构底座。
- 数据盘点、迁移演练、逐项对账与一次性切换方案。
02 · PRODUCT BLUEPRINT
产品蓝图
产品由四个使用端和六类公共能力组成，通过三条业务主线连接。合作伙伴是数据隔离边界，门店是订单与经营数据的归属单位。
员工端
岗位工作台、排班接单、组队履约、服务日志、轨迹里程和个人统计。
门店后台
服务定价、客户员工、订单调度、次卡合同、成本台账和经营报表。
平台后台
合作伙伴、城市门店、品牌模板、聚合分析、审计和数据治理，按阶段建设。
边界原则：合作伙伴之间强隔离；同一合作伙伴内的门店通过角色范围控制可见性。两者不可混用，否则会堵住跨店调度。
03 · CORE JOURNEYS
三条核心业务主线
① 预约与履约
选服务 → 选择或建立服务对象 → 预约支付 → 派单组队 → 上门服务 → 服务记录 → 评价。
② 资金与次卡
收款退款 → 资金流水 → 售卡核销 → 收入确认 → 现金流、营业额与待履约负债。
③ 多门店经营
平台 → 合作伙伴 → 门店 → 跨店调度或核销 → 成本归属 → 聚合经营分析。
预约与履约的关键改变
- 客户只看“安排中、已确认、服务中、已完成”等结果，不暴露内部拒接和重新派单过程。
- 派单员工作台按“是否需要介入”组织，而不是堆叠十几个状态标签。
- 主技师负责开始、完成、费用调整与服务记录，助理只查看和协作。
资金与次卡的关键改变
卖卡收到的钱先进入待履约负债，实际核销一次才确认一次收入。订单实付款由流水计算，不再通过覆盖字段丢失历史。
完整核心流程
2核心链路
2.1 进入小程序：一个入口，三种身份
同一个小程序，用手机号自动识别你是客户、技师还是派单员。
矢量版：09-身份识别与入口.svg
说明
- 员工岗位变更后，下次进入自动按新岗位显示对应工作台
- 后台修改员工手机号，不影响已建立的微信绑定关系
2.2 下单：把"建档"和"下单"拆开
现在的问题：第一次下单要填身份证、填详细地址、填一整套健康资料，流程长、放弃率高。
新流程：下单只要最少必填，其余资料在服务前补全。
矢量版：02-下单流程.svg
三处关键简化
| 原来 | 现在 | 说明 |
|---|---|---|
| 必填身份证号 | 取消 | 身份证降为档案里的选填项 |
| 手动输入省市区 + 详细地址 | 地址簿授权 / 地图选点 | 不再手打长地址 |
| 与被服务人关系需理解后填写 | 勾选 | 父亲 / 母亲 / 祖父母 / 配偶 / 本人 / 其他 |
取消身份证带来的三个连带处理（原来身份证承担了三件事）：
| 原用途 | 新做法 |
|---|---|
| 计算年龄和性别 | 下单时选年龄段 + 性别，一次点击 |
| 判断这位老人是否已添加过 | 按"姓名 + 关系"组合判重，并提示"是否为同一位"由用户确认 |
| 黑名单跨客户联动 | 按"姓名 + 联系电话"联动并人工复核；档案里填了身份证的，仍按身份证精确联动 |
2.3 派单与接单：两种模式，门店自主配置
现有系统只有人工派单——派单员要在几十个技师里比对排班、技能、位置。单店勉强够用，多门店之后派单员必然成为瓶颈。
因此提供两种模式，由门店自行配置，也可按服务品类分别设置：
矢量版：03-派单双模式.svg
为什么抢单要做成两段式
助浴是 1 主 + N 助的协同作业，不是滴滴那样一单一人。如果直接放开全员抢单会出三个问题：
- 谁当主技师？主技师要开始/完成订单、现场调整费用、对整单负责，不能谁手快谁当
- 抢到一半怎么办？3 人门槛的单抢到 2 人就卡住，而客户已经预约了几天后的时间
- 搭档配合——助浴要抬人、搬浴缸，老搭档和临时凑的三人服务质量差别很大
所以：先定主技师，再由主技师组队或开放助理位，并且必须有兜底——距服务时间不足设定时限仍未组齐，自动转人工派单并通知派单员，避免订单静悄悄卡到服务当天。
三条重要规则
- 只有改期会清空已指派技师。改地址、改附加项、加备注都不影响派单结果——这是现有系统里容易搞混、导致重复派单的地方
- 最少成单人数按服务项目配置，并且可以关闭。泡浴需要 3 人（搬浴缸、扶老人、备水），单独上门理发 1 人就够。关闭后，指派的技师接单即成单
- 抢单模式下仍受全部硬性约束：只有会做该品类、该时段空闲、未请假、当日单量未满的技师才能看到并抢这一单
2.4 服务执行与完成
矢量版：04-服务执行与完成.svg
说明
- 只有主技师能点开始和完成，其他技师只能查看
- 服务时长 = 点击完成的时间 - 点击开始的时间，自动进入统计
- 现场追加的每一笔费用都留痕（谁加的、什么时候、加了多少、为什么）
2.5 钱怎么走：三本账各归各的
现在的问题：一笔订单从 425 元补到 655 元、再退 100 元，系统里最后只剩一个数字 555。问"11 月微信实收多少"答不出来，跟微信后台也对不上账。
新做法：每一笔钱的进出都是一条独立记录，永不修改。
矢量版：05-资金流转三本账.svg
为什么要分三本账——以卖一张 10 次泡浴卡 2000 元为例：
| 现金流 | 营业额（收入） | 待履约负债 | |
|---|---|---|---|
| 卖卡当天 | +2000 | 0 | +2000 |
| 第 1 次上门核销 | 0 | +200 | -200 |
| 第 2 次上门核销 | 0 | +200 | -200 |
卖卡收到的钱不是赚到的钱，是欠客户的 10 次服务。 如果按现在的做法把 2000 直接记成当月营业额，就会出现：卖卡那个月营业额虚高 2000，之后 10 次上门服务的月份营业额是 0——技师干了活，报表上一分钱收入都没有。
押金同理：收进来是负债，退还时冲掉，不能算营业额。
这套做法还带来两个直接好处：
- 能和微信后台自动对账——每笔收付一一对应
- 任意历史时点都能还原——因为没有任何记录被改过
2.6 次卡的一生
矢量版：07-次卡生命周期.svg
卡种设计
卡是"某个服务项目的 N 次预付"，所以卡种跟着服务项目走：
| 卡种 | 可抵扣 | 说明 |
|---|---|---|
| 泡浴次卡 | 泡浴 | 原深度助浴项目对应泡浴 |
| 淋浴次卡 | 淋浴 | |
| 擦浴次卡 | 擦浴 | |
| （将来）理发次卡 | 上门理发 | 加新卡种只是加一条配置，不需要改程序 |
现有的"速通卡"不再保留，重新设计。存量未核销的次数如何处理需要业务决策（见第 8 章“决策中心”）。
2.7 车辆里程自动计算
目标是自动算、不用手工填。
矢量版：08-车辆里程自动计算.svg
员工端保留 App 与小程序两种形态，里程记录以 App 为主：
| 员工 App | 员工小程序 | |
|---|---|---|
| 完整功能（接单、服务、服务记录） | ✅ | ✅ |
| 切后台继续定位 | ✅ 稳定 | ⚠️ 可能被系统回收 |
| 完全退出后继续定位 | ✅ 可被位置事件唤起 | ❌ 做不到 |
| 地理围栏自动结束行程 | ✅ | ❌ |
| 适用 | 跑车的技师，日常主力 | 临时替班、不跑车的技师 |
为什么 App 能解决而小程序不能：iOS 可申请「始终允许」定位并注册后台模式，即便 App 被系统终止，位置显著变化事件也能将其唤起；Android 用前台服务 + 常驻通知，是业界稳定做法。小程序没有对应能力。
里程精度分三级，每条行程都标记来源：
| 级别 | 来源 | 精度 | 说明 |
|---|---|---|---|
| 1 | App 轨迹纠偏 | 最高 | 基本无断点，反映实际绕路 |
| 2 | 小程序轨迹纠偏 | 中 | 切后台可采集，长途可能中断 |
| 3 | 路径规划估算 | 较低 | 只取起终点，绕路不准 |
报表中区分统计，不让三种精度的数据混算。 同时保留管理员手工修正入口，修正后标记来源并留痕。
App 顺带解决一个体验问题：用地理围栏在技师到达客户地址时自动结束行程。「忘记点结束」是这类记录最常见的数据缺失原因。
采用 App 需要一并解决的四件事（不是技术问题，但不解决就落不了地）：
- 分发：App Store 上架或企业内部分发，需要长期维护签名证书
- 权限：iOS「始终允许」会被系统反复提醒，员工随时可能关闭，需管理制度兜底
- 耗电：因此设计为只在「出发」到「结束」之间采集，不做全天候定位
- 员工知情同意：位置记录属员工关系事项，需写入员工手册或劳动合同附件
「只在行程期间采集」这个设计本身就是最好的说辞——不是全天候监控，只是记录这趟车的里程，而且里程是用来给技师报油费的。
2.8 不同角色看到的订单状态
一个订单只有一套真实状态，但四个角色看到的是四种不同的呈现。
现有系统的问题是所有人共用同一套状态标签，导致：客户能看到"已拒绝-待指派"这种内部调度过程（引发焦虑和投诉），而技师却看不到"还差几个人才能开工"这种他真正需要的信息。
2.8.1 底层状态模型
系统内部只维护这四个维度，各角色的显示都是它的投影：
| 维度 | 取值 | 说明 |
|---|---|---|
| 主状态 | 待支付 → 待安排 → 已确认 → 服务中 → 已完成 / 已取消 | 只有 6 个 |
| 安排情况 | 未开始 / 抢单中 / 组队中 / 已指派待响应 / 部分响应 / 存在拒接或弃单 / 兜底待介入 / 已组齐 | 由技师响应记录实时算出，不单独存 |
| 支付情况 | 未付 / 已付 / 待补差 / 待退款 / 已退款 | 由资金流水实时算出，不单独存 |
| 评价情况 | 未评价 / 已评价 |
这样设计的好处：新增派单模式（比如抢单）只是增加"安排情况"的取值，主状态一个字不用改；"待评价"不再占用状态位，统计"已完成订单数"永远不会漏。
2.8.2 客户视角：只看结果，不看过程
左半为客户视角，右半为技师视角。矢量版：10-客户与技师状态机.svg
关键设计：客户看不到派单过程。
技师拒接、抢单没人抢、需要重新指派——这些在客户端一律显示为"安排中"。
理由：这是内部调度过程，对客户没有任何可行动性，暴露出去只会产生"为什么没人愿意接我的单"这种焦虑和投诉。
但隐藏过程就要给确定性补偿："安排中"必须附带一个承诺，例如"我们将在服务开始前 4 小时为您确认服务人员"。让客户知道什么时候能等到确定答复，而不是干等。
客户能看到的信息，按状态递进：
| 客户状态 | 能看到什么 |
|---|---|
| 待支付 | 订单内容、金额 |
| 安排中 | 服务对象、时间、地址、金额 + 确认时间承诺 |
| 已确认 | 增加：服务人员姓名与照片（老人会关心谁来） |
| 服务中 | 增加：实际开始时间；现场追加的费用及说明 |
| 已完成 | 增加：服务时长、服务记录、评价入口 |
| 已取消 | 增加：取消时间、取消原因、退款金额 |
2.8.3 技师视角：只看"我和这单的关系"
技师不关心订单全局状态，只关心这单跟我什么关系、我该干什么（状态流见 2.8.2 的右半部分）。
技师侧特有的两个设计
1. 待服务状态必须显示组队进度
技师最需要知道的是"这单人齐了没有"——3 人的泡浴单只到了 2 个人，他到现场也开不了工。所以待服务状态下要显示：
已组齐 3/3 或 还差 1 人（助理位）
抢单模式下更要显示，因为组队是动态的。
2. 主技师与助理看到的操作不同
| 主技师 | 助理 | |
|---|---|---|
| 开始 / 完成订单 | ✅ | ❌ |
| 调整费用 | ✅ | ❌ |
| 填写服务记录 | ✅ | ❌ |
| 组队邀请搭档 | ✅ | ❌ |
| 查看订单详情、客户信息、健康档案 | ✅ | ✅ |
| 查看上门地址与导航 | ✅ | ✅ |
助理端要明确标出"你是助理，本单由 XXX 负责"，避免到现场互相等。
技师看不到的：客户的完整支付情况、其他技师的拒接原因、订单的利润与成本。
技师需要看到的钱：只有"需要向客户代收多少现金"这一项。
2.8.4 派单员视角：按"要不要我管"组织
派单员需要最细的粒度，因为他要判断哪些单需要干预：
| 派单员看到 | 需要动作 |
|---|---|
| 待指派 | ✅ 去指派 |
| 抢单中 | ⏳ 观察 |
| 组队中（主技师已定，助理未满） | ⏳ 观察 |
| 待接单 / 部分响应 | ⏳ 观察 |
| 存在拒接或弃单 | 🔴 需介入 |
| 兜底待介入（超时未组齐） | 🔴 需介入 |
| 已确认 / 服务中 / 已完成 / 已取消 | 查看 |
派单工作台不按状态分组，按"是否需要介入"排序：
| 分组 | 包含 | 含义 |
|---|---|---|
| 需要我处理 | 待指派 + 有人拒接 + 兜底超时 + 临近服务时间仍未组齐 | 上班第一眼就看这一栏 |
| 进行中 | 抢单中 / 组队中 / 待接单 | 观察即可 |
| 已安排 | 已确认 / 服务中 | |
| 已结束 | 已完成 / 已取消 |
这比现有系统按状态标签平铺要有效得多——派单员上班第一眼看到的应该是"今天有 5 单需要我处理"，而不是十几个状态标签。
2.8.5 管理者视角
派单员能看到的全部，另加：支付与退款明细、订单成本、评价、订单变更全流水。
2.8.6 状态映射对照表
矢量版：06-角色状态映射.svg
| 底层状态 | 客户看到 | 技师看到 | 派单员看到 |
|---|---|---|---|
| 待支付 | 待支付 | 不可见 | 待支付 |
| 待安排 · 未开始 | 安排中 | 不可见 | 待指派 |
| 待安排 · 抢单中 | 安排中 | 可抢 | 抢单中 |
| 待安排 · 组队中 | 安排中 | 待服务（还差 N 人） | 组队中 |
| 待安排 · 已指派待响应 | 安排中 | 待接单 | 待接单 |
| 待安排 · 部分响应 | 安排中 | 待接单 / 待服务 | 部分响应 |
| 待安排 · 存在拒接或弃单 | 安排中 | 拒接者不可见 | 🔴 需介入 |
| 待安排 · 兜底待介入 | 安排中 | 不可见 | 🔴 需介入 |
| 已确认 | 已确认 | 待服务（已组齐） | 已确认 |
| 服务中 | 服务中 | 服务中 | 服务中 |
| 已完成 · 未评价 | 待评价 | 已完成 | 已完成 |
| 已完成 · 已评价 | 已完成 | 已完成（可看评分） | 已完成 |
| 已取消 | 已取消 | 已取消 | 已取消 |
这张表就是"客户不看过程、技师只看自己、派单员看全局"三条原则的落地。
04 · KEY PRODUCT DESIGN
关键产品设计
一个入口，按身份显示工作台
同一个微信入口识别客户、技师和派单员；员工岗位变化后自动切换工作台，微信绑定不依赖可修改的手机号。
建档与下单拆开
身份证改为档案选填；地址通过地址簿或地图选择；关系改为勾选。服务前必须补全的健康资料进入履约检查，而不是堵在首次下单前。
人工派单与开放抢单并存
人工派单由系统推荐人选；抢单采用“先确定主技师、再组助理”的两段式，并设置临近服务时间的人工兜底。
服务执行与状态投影
订单内部只维护主状态、安排情况、支付情况和评价情况。客户、技师、派单员和管理者看到各自可行动的状态。
同城多加盟商：先筛店，再锁定履约门店
系统按上门地址、服务项目、营业状态、可约时段和人员能力，从同城全部合作伙伴的公开服务索引中筛选门店。多家可服务时展示距离、最早时段、价格、评分和次卡适用情况，由用户确认。
确认后订单锁定合作伙伴与服务门店，进入该门店派单池；只允许同一合作伙伴内部跨店调度，不同合作伙伴之间不得直接调人或转单。
订单归属原则：城市负责地理筛选，合作伙伴负责数据与结算隔离，门店负责接单与履约归属。每笔订单必须明确锁定一家门店。
里程自动计算
跑车技师以 App 记录行程，小程序和起终点估算作为降级路径；每条记录标记数据来源，管理员修正必须留痕。
完整功能需求
3功能设计
3.1 服务项目体系（本次重要调整）
现状：只有一个"深度助浴"项目，理发和修脚只能作为附加项。
新设计：所有服务统一建模，一个项目可以有两种角色、两套价格。
| 服务项目 | 可单独下单 | 单独价 | 可作附加项 | 附加价 | 建议人力 |
|---|---|---|---|---|---|
| 泡浴（原深度助浴） | ✅ | 待定 | ❌ | 主 1 + 助 2 | |
| 淋浴 | ✅ | 待定 | ❌ | 待定 | |
| 擦浴 | ✅ | 待定 | ❌ | 待定 | |
| 上门理发 | ✅ | 与附加价不同 | ✅ | 25 元 | 1 人 |
| 上门修脚 | ✅ | 180 元 | ✅ | 180 元（同价） | 1 人 |
| 剪指甲 | ❌ | ✅ | 10 元 | ||
| 刮胡子 | ❌ | ✅ | 10 元 |
理发两个价不同、修脚两个价相同——差别在于单独上门要单独承担一次上门成本，而修脚本来就是"专业修脚师傅单独上门"的性质。
每个服务项目可配置：
- 价格（单独价 / 附加价）、服务介绍、图片、是否首页展示、上下架
- 默认时长——用于排班和时段占用，泡浴占的时段比擦浴长
- 人力配置——主技师 1 名 + 助理 N 名
- 最少成单人数——开关 + 数值，关闭时接单即成单
- 技师品类要求——派单时只显示能做该品类的技师
- 可选的附加收费项
技师侧对应增加"可服务品类"标签（泡浴 / 淋浴 / 擦浴 / 理发 / 修脚 …），由门店在员工资料里勾选。派单时系统只显示能做该品类的技师，避免派错人。
3.2 客户与服务对象
- 客户：微信授权的下单人（监护人、家属）
- 服务对象：接受服务的老人，一个客户下可以有多位
服务对象档案包含：
- 基本信息：姓名、与客户关系、性别、年龄段、身份证号（选填）
- 健康信息：失能失智程度、身体外伤、插管情况、其他基础病、浴前不适事项
- 服务信息：助浴频率、体重区间、上门地址（可多个）、楼层与有无电梯、热水器类型
- 关键档案：家庭情况、监护人、居住情况、兴趣话题、需求与注意事项（可由 AI 从服务录音中自动生成草稿，见 3.12）
地址独立管理：一位老人可以有多个上门地址。下单时地址会被"拍快照"存进订单，之后修改档案地址不会影响历史订单——这是现有系统容易出错的地方。
黑名单：客户和服务对象都可加入黑名单。服务对象被拉黑后，在其他客户名下的同一位老人也自动拉黑。
3.3 下单与支付
见 2.2 流程图。补充规则：
时段与容量：每天的可预约时段和每个时段的接单上限由门店配置，不再写死。取消订单释放名额。
押金（新增）
- 触发：选择线下支付，且为首次下单客户，或客户被标记为需押金
- 金额：200 元，门店可配
- 记账：计入负债，不算营业额
- 退还：订单正常完成后自动原路退还
- 与空单费的关系：客户爽约时押金转为空单费，不重复收取（待确认，见第 8 章“决策中心”）
取消规则
| 场景 | 规则 |
|---|---|
| 服务日期之前 | 全额退款 |
| 服务当天，距开始 2 小时以上 | 收 200 元空单费，其余退还 |
| 服务当天，距开始 2 小时以内 | 客户端不可自助取消，转人工处理 |
| 后台代客户下的单 | 客户端一律不可取消 |
3.4 合同：电子合同改为纸质扫描件
取消第三方电子合同服务（签署主体与实名认证人不匹配、使用成本高），改为上传纸质合同签署照片或扫描件。
- 支持多张图片、记录合同编号与签署日期
- 上传方：技师上门时拍照上传，或客户自助上传
- 建议规则：首单允许先下单，服务前补传；未补传则订单不可置为已完成（待确认，见第 8 章“决策中心”）
- 存量电子合同数据导出留档
3.5 派单调度
见 2.3 流程图。
3.5.1 智能撮合评分
无论人工派单（用于推荐排序）还是开放抢单（用于抢单资格过滤），底层是同一套匹配逻辑：
硬性条件（不满足直接排除）
| 条件 | 说明 |
|---|---|
| 会做该服务品类 | 按技师的"可服务品类"标签匹配 |
| 该时段空闲 | 需包含通勤时间——上一单结束不等于立刻可接下一单 |
| 未请假、在职 | |
| 当日单量未满 | 按门店配置的每人每日上限 |
排序权重（满足硬性条件后按分数排序）
| 因子 | 说明 |
|---|---|
| 地理距离 | 就近优先 |
| 岗位星级与订单要求匹配 | 主技师位要求更高 |
| 是否服务过这位老人 | 显著加权。养老服务里"熟人上门"对老人是真实价值 |
| 负载均衡 | 避免旱涝不均 |
| 技师信誉分 | 见 3.5.3 |
就近派单有额外收益：直接减少行驶里程，而里程和油费本来就要计入成本台账。派单优化和成本控制是同一件事。
3.5.2 派单模式配置
| 配置项 | 说明 |
|---|---|
| 默认派单模式 | 人工派单 / 开放抢单 |
| 按服务品类覆盖 | 例如泡浴走人工派单、单独上门理发走抢单 |
| 参与抢单的技师范围 | 全部 / 仅兼职 / 仅指定人员 |
| 抢单窗口 | 订单提前多久进入抢单池 |
| 兜底时限 | 距服务时间不足 N 小时仍未组齐，自动转人工 |
| 助理位补齐方式 | 主技师组队邀请 / 开放抢单 / 两者都允许 |
3.5.3 用工类型与弃单处理
技师分全职雇员和兼职按单两类，这是员工档案的必填字段，因为弃单处理必须按用工类型分流：
| 全职雇员 | 兼职按单 | |
|---|---|---|
| 默认派单方式 | 人工派单为主 | 可参与抢单 |
| 弃单处理 | 信誉分 + 绩效评价，不涉及费用 | 按合作协议处理，可约定费用 |
| 依据 | 雇员是被安排工作，不是自愿接单，罚款缺乏依据 | 自愿接单关系，协议可约定 |
信誉分机制
- 记录接单率、弃单率、准时率、客户评分
- 弃单按后果分级，而不是简单数次数：
| 情形 | 处理 |
|---|---|
| 提前充足时间放弃，订单仍能补齐 | 记录，不处罚 |
| 临近服务时间放弃 | 扣信誉分 |
| 放弃导致整单人数不足做不成 | 重罚。一个助理弃单可能让等了几天的老人白等 |
- 分级处理：首次提醒 → 多次限制抢单权限（如 7 天内只走人工派单）→ 计入绩效评价
- 正向激励优先：高信誉技师可提前 N 分钟看到抢单池，等于优先挑单权。激励比处罚更有效，且对劳动关系更安全
3.5.4 其他
- 派单工作台按计划服务时间排序，默认显示待派订单
- 候选技师展示：头像、姓名、岗位星级、可服务品类、当日单量进度、该时段是否空闲、距服务地址距离、信誉分
- 跨门店调人：同一个合作伙伴名下有多家门店时，可切换到"跨店找人"
- 技师日历：可查看单个技师的排班，也可查看全店当日所有技师的排单情况
- 请假管理：支持按时间段请假、跨天请假自动按天拆分，请假时段不可派单也不进抢单池
3.6 服务执行与服务记录
见 2.4 流程图。服务记录字段：
| 分类 | 记录项 |
|---|---|
| 用水量（L） | 初接、泡完澡、加水、洗头、洗完头 |
| 水温（℃） | 储水桶（开始 / 泡完澡 / 搓完澡）、浴槽（开始 / 泡完澡 / 搓完澡） |
| 时间管理 | 备完水、泡完澡、洗完头、搓完澡、冲洗完、整理完 |
| 分项耗时 | 助浴项目开始/结束、理发项目开始/结束 |
| 其他 | 是否接水管、特记事项 |
客户可在订单里查看已完成服务的服务记录。
3.7 次卡
见 2.6 流程图。需要业务确认的细则见第 8 章“决策中心”：绑定对象、有效期、能否转让、退卡规则、抵扣范围。
3.8 车辆管理
- 车辆档案：车牌、车型、百公里油耗、所属门店、状态
- 行程记录：由员工 App 自动采集轨迹并计算里程与油费（见 2.7），小程序端降级支持
- 维修保养记录、违章记录
- 报表：按车辆 / 按司机 / 按月统计里程、油费、单均里程，并按里程来源分级区分统计
3.9 工作餐
- 登记：日期、就餐人、金额、是否有发票、备注
- 可见范围调整：技师只能看到与自己相关的餐费；店长和管理者可看全店
- 自动进入成本台账
3.10 成本台账与结算
结算目前在线下进行、按技师服务次数计算。本方案不预设结算算法，但把结算需要的原始数据全部采集齐：
| 成本项 | 采集方式 |
|---|---|
| 技师人工 | 订单完成时按岗位档位自动生成 |
| 服务时长 | 实际开始到实际完成，自动记录 |
| 工作餐 | 登记时自动生成 |
| 车辆油费 | 行程结束时自动计算生成 |
| 耗材 | 待确认是否需要（见第 8 章“决策中心”） |
这样将来无论采用按次、按时长、按毛利分成还是几种方式组合，都能直接算出来，不需要再改系统。
3.11 经营报表（新增模块）
现有系统没有任何报表，这是"费用统计混乱"的另一半原因。新增：
| 报表 | 回答什么问题 |
|---|---|
| 经营总览 | 订单量、营业额、客单价、完成率、取消率 |
| 现金流 | 这个月进了多少钱、退了多少 |
| 收入确认 | 这个月真正赚了多少（服务收入 + 次卡核销） |
| 待履约负债 | 还欠客户多少次服务、多少押金没退 |
| 次卡分析 | 售卡、核销、退卡、剩余次数、卡种结构 |
| 技师分析 | 服务单数、服务时长、评分、拒单率 |
| 成本分析 | 人工、工作餐、油费、耗材 |
| 车辆分析 | 里程、油费、单均里程 |
每张报表都支持按门店、按时间段筛选，可导出。
3.12 AI 能力
定位：优先做成帮技师减负的工具。
五项能力对技师的意义并不一致——"自动生成服务记录"是帮他省事，"识别违规操作"是监督他。而这五项共用同一份录音。如果技师认定这是监督工具，录音覆盖率就上不去，前四项的价值也跟着落空。
因此设计上做如下安排：
| 能力 | 本方案设计 |
|---|---|
| 现场语音收录 | 技师在订单里手动开启，不做静默录音。给技师的理由：录了就不用手填服务记录 |
| 自动生成每单服务记录 | AI 生成草稿，技师核对后提交。服务记录涉及责任认定，必须有人确认 |
| 自动生成客户关键信息档案 | 从录音中抽取家庭情况、居住情况、兴趣话题等，填入客户档案（现有系统这些字段是人工填的） |
| 识别现场危险要素 | 做成对技师的提示（地面湿滑、老人身体异常），是保护他而不是查他 |
| 识别助浴师违规操作 | 本期不做实时告警，只做事后抽检打标；规则提前公开，结果仅管理者可见，作为培训依据 |
| 识别客户商业需求 | AI 给建议，由技师或客服确认后才写入客户档案 |
录音管理
- 原始录音保存 90 天后归档（转冷存储）
- 原始录音仅管理者可听，每次调听留审计记录
- 转写文本长期保留
上线前必须完成的两件事（不是技术问题，但不做完不能上线）：
- 老人及家属的知情同意——录音会采集健康状况、家庭情况等敏感个人信息，需在服务协议中增加条款，上门时技师再口头告知一次
- 员工的知情同意——持续录音涉及对员工的记录，需写入员工手册或劳动合同附件
建议先做一次现场实测：浴室水汽噪音大、老人常有方言、家中网络条件差，转写准确率需要用真实场景验证后再确定后续投入。
3.13 可依优品
这四项需求实际上是两个不同的生意，客户群、结算方式、履约流程都不同，方案中拆成两个模块设计。
A. 供货平台（面向合作伙伴 / 同行机构）
- 助浴设备销售、供应链耗材销售
- 特点：客户数量少、单价高、可走对公结算
- 功能：商品目录、订货单、审核、发货、对账
- 不需要购物车、营销活动、在线支付这些 C 端电商功能，做得很轻
B. 康复器具租赁（面向老人家庭）
- 轮椅、护理床、助行器等
- 本质是器具台账与周转管理，不是商城：
矢量版：11-器具租赁周转.svg
- 每一台器具有独立编号，可追踪当前在谁手上、租了多久、消毒和维修记录
- 押金与租金分开记账（押金是负债）
3.14 多门店与合作伙伴体系
xlsx 提出"授权其他城市合作伙伴或加盟商使用管理系统"。方案设计如下：
组织结构——城市、合作伙伴、门店是三个不同维度，不是上下级：
| 作用 | |
|---|---|
| 城市 | 地理维度，用于品牌配置和区域分析 |
| 合作伙伴 | 所有权与结算主体，数据隔离的边界 |
| 门店 | 实际经营单位，订单归属这里 |
- 不同合作伙伴之间的客户、订单、技师完全隔离，互相看不到
- 同一个合作伙伴可以开多家门店，门店之间数据互通，技师可以跨门店调度
- 总部可以看到各门店的经营分析报表；合作伙伴看不到总部和彼此的数据
- 同一个城市可以有多个合作伙伴
3.14.1 同城多加盟商下的选店与履约归属
核心原则：城市只负责地理筛选，合作伙伴负责数据与结算隔离，门店负责接单与履约归属。每笔订单最终必须明确锁定一家服务门店。
| 步骤 | 系统处理 | 用户看到什么 |
|---|---|---|
| 1. 提交服务条件 | 用户选择服务项目、服务对象、上门地址和期望时间。 | 保持一次下单入口，不要求用户先理解加盟商层级。 |
| 2. 筛选候选门店 | 平台从同城全部合作伙伴的公开服务索引中，按服务范围、服务品类、营业状态、可预约时段和最低人员配置筛选。 | 无可服务门店时提示调整地址或时间，并可登记服务意向。 |
| 3. 推荐并确认 | 只有一家时默认推荐；有多家时按距离、最早可约时间、价格、服务能力与评价排序。 | 门店卡片展示门店名称、距离或服务范围、最早时段、价格、评分及次卡是否可用，由用户确认。 |
| 4. 锁定订单归属 | 用户确认后锁定合作伙伴和门店，并读取该门店的价格、时段和次卡规则。 | 订单页明确展示“本单服务门店”，价格或权益变化不得静默切换。 |
| 5. 门店履约 | 订单进入已锁定门店的派单池；人员不足时，只允许同一合作伙伴内部跨店调度。 | 客户只关注服务安排结果，不暴露内部调度过程。 |
公共服务索引：平台只汇总门店名称、服务范围、服务项目、营业状态、可约能力、公开价格与评价等可用于匹配的信息，不开放合作伙伴的客户、订单、员工和经营数据。
- 订单创建时冻结
partner_id、store_id、服务地址快照、服务项目与价格快照、选店方式及路由规则版本，保证后续可追溯。 - 订单收入与经营归属服务门店；跨店支援技师保留原所属门店，人工与分成成本按决策中心第 45 项确定的规则拆分。
- 不同合作伙伴之间不得跨店调人或直接转单。原门店不能履约时，须征得用户同意，重新选择并确认另一家门店。
- 老客户可优先推荐上次服务门店，但必须重新校验地址、服务项目、时段和次卡适用范围；任一条件不满足即重新筛选。
为什么必须让用户确认：同城不同合作伙伴可能存在价格、服务承诺和次卡权益差异，系统可以推荐，但不能在用户无感知的情况下替用户决定履约主体。
品牌配置三级生效：平台默认 → 城市覆盖 → 门店覆盖。这样既能统一"可依"品牌，也能给未授权品牌的合作伙伴单独配置图片和文案（对应 xlsx 中"未授权品牌加盟时切割用"）。
关于实施节奏的建议：目前合作伙伴还处于规划阶段，尚无签约方。建议数据结构在本期一次做到位（成本很低），平台后台、品牌配置、跨门店报表等功能在第一个合作伙伴确定后再上线（工作量较大）。这样随时可以推进加盟，又不必现在为不确定的计划付全部成本。
现有系统的教训值得一提：整套代码里没有任何"门店"的概念，所以现在想支持多门店，等于所有数据表重建。这个坑不宜再踩第二次。
3.15 消息通知
| 触发时机 | 通知对象 |
|---|---|
| 客户下单 | 派单员 |
| 派单完成 | 被指派技师 |
| 技师拒接 | 派单员 |
| 新订单进入抢单池 | 符合条件的技师（高信誉技师提前推送） |
| 主技师组队邀请 | 被邀请的助理 |
| 抢单单已组齐 | 该单全体技师 |
| 距兜底时限仍未组齐 | 派单员 |
| 技师弃单 | 派单员 + 同单其他技师 |
| 客户取消订单 | 派单员 + 已指派技师 |
| 距服务时间 2 小时 / 1 小时 | 相关技师 |
| 助浴频率到期前一天 | 派单员 |
| 当天订单改地址或改附加项 | 主技师 |
| 次卡即将过期 | 客户 |
| 器具租期即将到期 | 客户 + 门店 |
3.16 角色与权限矩阵
岗位与权限分离：岗位（星级、实习生、派单员、店长）决定派单能力与结算档位；权限由角色决定。岗位调整不会自动改变系统权限。
| 功能 | 客户 | 助理技师 | 主技师 | 派单员 | 店长 | 合作伙伴管理者 | 平台 |
|---|---|---|---|---|---|---|---|
| 下单 / 取消 / 评价 | ✅ | ||||||
| 查看本人订单 | ✅ | ✅ | ✅ | ||||
| 接单 / 拒接 / 抢单 | ✅ | ✅ | |||||
| 开始 / 完成订单 | ❌ | ✅ | |||||
| 现场调整费用 | ❌ | ✅ | |||||
| 填写服务记录 | ❌ | ✅ | |||||
| 组队邀请搭档 | ❌ | ✅ | |||||
| 查看全店订单 | ✅ | ✅ | ✅ | ✅ | |||
| 指派 / 改期 / 改址 | ✅ | ✅ | ✅ | ||||
| 跨门店调人 | ⚙️ | ✅ | ✅ | ||||
| 后台代客户下单 | ✅ | ✅ | |||||
| 后台取消订单与退款 | ✅ | ✅ | |||||
| 客户与服务对象管理 | ✅ | ✅ | |||||
| 员工管理 / 排班 / 培训 | ⚙️ | ✅ | |||||
| 服务项目与定价 | ⚙️ | ✅ | ⚙️ | ||||
| 次卡商品配置 | ✅ | ⚙️ | |||||
| 车辆与行程管理 | ✅ | ✅ | |||||
| 工作餐（本人） | ✅ | ✅ | ✅ | ✅ | ✅ | ||
| 工作餐（全店） | ❌ | ❌ | ✅ | ✅ | |||
| 成本台账与经营报表 | ✅ | ✅ | |||||
| 调听服务录音 | ❌ | ❌ | ❌ | ✅ | ✅ | ||
| 角色权限配置 | ✅ | ||||||
| 合作伙伴开通 / 停用 | ✅ | ||||||
| 品牌配置 | ⚙️ | ✅ | |||||
| 跨门店经营分析 | ✅ | ✅ |
✅ 有权限 ❌ 明确无权限 ⚙️ 可配置（由上级角色授予） 空白 不适用
两层机制不可混用：
- 租户隔离（合作伙伴之间）——框架层强制过滤，越界即数据泄漏事故
- 数据可见性（同一合作伙伴内的门店之间）——角色的门店范围，只是看得多看得少
若某个合作伙伴希望 A 店店长看不到 B 店，用角色的门店范围收窄即可，不要再加一层租户——那样会把技师跨店调度堵死。
05 · PHASING & SCOPE
分期与范围
本期核心
主数据、下单履约、资金次卡、组织权限、迁移对账和基础报表。
条件性模块
员工 App、自动里程、AI 日志草稿等，需先完成分发、知情同意或现场实测。
分期建设
完整平台后台、可依优品电商、合作伙伴分成闭环、AI 深度识别。
阶段 1
打底座
组织、身份、服务项目、客户、订单、时间、资金流水。
组织、身份、服务项目、客户、订单、时间、资金流水。
阶段 2
跑通履约
支付、派单组队、服务执行、次卡、通知与基础报表。
支付、派单组队、服务执行、次卡、通知与基础报表。
阶段 3
迁移上线
数据演练、余额对账、在途订单处理、停服切换和上线核验。
数据演练、余额对账、在途订单处理、停服切换和上线核验。
阶段 4
按条件扩展
App 里程、AI、优品、平台运营与分成结算。
App 里程、AI、优品、平台运营与分成结算。
完整实施节奏与变化清单
5实施节奏建议
按依赖关系排序——后面每一块都依赖前面的数据基础。
| 阶段 | 内容 | 完成后能看到什么 |
|---|---|---|
| 一、基础 | 数据结构重建、组织与权限、资金流水、订单模型 | 内部里程碑，暂无可见功能 |
| 二、主流程 | 下单（简化版）、派单、服务执行、服务记录、评价、取消退款、押金、纸质合同 | 业务可以在新系统上跑通 |
| 三、经营 | 次卡新体系、成本台账、经营报表、工作餐、服务时长统计 | 账能算清楚了，报表可用 |
| 四、车辆与员工 App | 员工 App 打包与分发、行程记录、里程自动计算、油费成本 | 车辆成本可见，技师报油费有依据 |
| 五、数据迁移与切换 | 迁移演练、对账、正式切换 | 正式上线 |
| 六、AI | 先做现场实测与合规准备，再上线录音与服务记录草稿 | 技师填表时间减少 |
| 七、可依优品 | 供货平台 + 器具租赁 | 新业务线 |
| 八、合作伙伴体系 | 平台后台、品牌配置、跨门店报表 | 具备对外授权能力 |
说明
- 阶段一到五是主线，建议连续完成
- 阶段六、七、八可以根据业务优先级调整顺序，也可以与主线并行
- 阶段八建议在第一个合作伙伴确定后启动（数据结构在阶段一已经做好，随时可以启动）
- 各阶段具体工期需要在第 7 章的问题确认后给出——其中线上数据量级直接影响迁移工作量
6本方案带来的变化一览
| xlsx 需求 | 本方案的对应设计 |
|---|---|
| 授权其他城市合作伙伴使用系统 | 3.14 多门店与合作伙伴体系 |
| 添加城市选项、各城市可编辑页面图文 | 3.14 品牌配置三级生效 |
| 助浴师服务现场语音收录 | 3.12 技师手动开启录音 |
| 自动生成客户关键信息档案 | 3.12 抽取后填入客户档案 |
| 自动识别现场危险与违规操作 | 3.12 危险要素做提示；违规识别做事后抽检 |
| 自动识别客户商业需求 | 3.12 AI 建议 + 人工确认 |
| 自动生成每一单服务日志 | 3.12 生成草稿，技师确认后提交 |
| 可依助浴设备销售 / 供应链产品 | 3.13-A 供货平台 |
| 康复器具租赁 | 3.13-B 器具租赁与周转 |
| 增加车辆里程计算管理 | 2.7 + 3.8 员工 App 自动采集轨迹，计算里程与油费 |
| 费用统计混乱 | 2.5 资金流水三本账 + 3.11 报表模块 |
| 下单时间混乱 | 时间字段拆分，各记各的 |
| 订单时间调整后排序混乱 | 同上，各列表明确排序规则 |
| 取消电子合同改纸质扫描件 | 3.4 |
| 删除下单人身份证输入 | 2.2 |
| 删除下单人地址输入 | 2.2 地址簿 / 地图选点 |
| 增加与被服务人关系勾选 | 2.2 |
| 增加押金支付选项 | 3.3 |
| 工作餐只显示与自己相关 | 3.9 |
| 取消速通卡 | 2.6 重新设计卡体系 |
| 增加擦浴、淋浴、泡浴次卡 | 3.1 服务品类拆分 + 2.6 卡种跟随品类 |
| 次卡费用统计混乱 | 2.5 三本账 + 3.11 次卡分析报表 |
| 增加服务时长统计 | 2.4 自动记录 + 3.11 技师分析 |
全部 24 条需求均已在方案中设计。
方案额外建议纳入的三项（xlsx 未提出）
| 新增 | 理由 |
|---|---|
| 经营报表模块（3.11） | "费用统计混乱"的根因有一半是系统里根本没有报表，目前全靠导 Excel 人工算。不补这一块，改了数据结构也仍然看不到数 |
| 员工 App（2.7） | 微信小程序在完全退出后无法持续定位，里程记录必然有断点。员工端增加 App 形态后里程才能真正做到自动、准确；小程序保留为轻量入口 |
| 智能撮合与抢单模式（2.3 / 3.5） | 现有的纯人工派单在单店可行，多门店后派单员会成为瓶颈——每单要人工比对几十个技师的排班、技能、位置。提供"人工派单（含智能推荐）"与"开放抢单"两种模式由门店自选，是规模化的前提 |
06 · DATA MIGRATION
数据迁移与上线
数据承接不是导库，而是一次 ETL、结构翻转和业务对账。次卡余额、未完成订单和历史金额是风险最高的三类数据。
交付表述：在完成数据盘点、迁移演练和逐项对账后，承接客户、服务对象、员工、订单及可核验的次卡余额。切换采用约定停服窗口；历史财务数据以可还原范围为边界，不承诺重建现有系统未记录的流水事实。
- 先盘点：确认数据量级、线上真实状态分布、次卡种类和余额口径。
- 再演练：至少完成一次全量迁移演练，输出数量、金额、余额和异常清单。
- 后切换：在业务低谷停服，旧系统处理完在途订单，新系统只接切换后的新交易。
- 再核验：逐类核对客户数、订单数、次卡剩余次数和资金汇总。
完整数据承接规则
4现有数据如何承接
数据按盘点、演练和对账结果承接，切换采用约定停服窗口。
| 数据 | 处理方式 |
|---|---|
| 客户、服务对象、员工 | 完整迁移 |
| 历史订单、服务记录、评价 | 完整迁移，可查询 |
| 次卡余额 | 逐张核对后迁移，剩余次数一次不差 |
| 原"深度助浴"项目 | 映射为泡浴 |
| 速通卡 | 不再保留，存量未核销次数的处理方式需业务决策 |
| 电子合同 | 导出留档，新系统不再产生 |
两点需要提前知晓：
- 切换需要一个停服窗口。建议选周一凌晨等业务低谷时段，切换前把在途订单在旧系统跑完，切换当天只接新单。
- 历史财务报表与新系统会有出入。现有系统没有完整的资金流水记录，历史数据只能从订单金额反推，无法 100% 还原每一笔的发生时间和渠道。切换后的数据完全准确，切换前的历史区间建议以原有账目为准。
07 · SUCCESS & RISK
成功标准、风险与责任边界
账务可解释
任一订单都能还原收款、补差、退款、核销和押金变化，并与微信或线下记录对账。
履约可控制
派单员能第一眼看到需要介入的订单，临近服务时间未组齐时自动兜底。
迁移可验收
迁移前后关键对象数量一致，次卡余额逐张核对，异常有明确处理结论。
合规可追溯
位置、录音、敏感健康信息均有知情同意、最小化采集、权限和审计记录。
客户方前置责任
提供真实业务规则、线上数据量级、迁移窗口、法务与员工关系文件，并对 13 项开发前置决策给出明确结论。
完整验收、风险与合规要求
7怎么算做成了
重构不是把功能重写一遍就算成功。以下指标建议在上线后 1–3 个月内验证：
| 目标 | 衡量指标 | 现状 | 期望 |
|---|---|---|---|
| 账能算清 | 资金流水与微信支付后台的对账差异笔数 | 无法对账（系统里一笔订单只有一个数字） | 0 笔 |
| 次卡余额与流水重算的差异张数 | 无流水，无法校验 | 0 张 | |
| 出一张月度经营报表所需时间 | 导 Excel 后人工算，按小时计 | 系统直接出，秒级 | |
| 下单更顺 | 新客首单的流程完成率 | 需填身份证 + 详细地址 + 完整健康档案 | 提升（具体基线上线前测一次） |
| 平均下单耗时 | 同上 | 明显缩短 | |
| 派单更快 | 单均派单耗时 | 人工比对几十个技师 | 显著下降 |
| 需人工介入的订单占比 | 全部人工 | 抢单模式下 低于 20% | |
| 兜底转人工的订单占比 | — | 低于 5%（高于此说明抢单池人手不足） | |
| 成本可见 | 有里程记录的行程占比 | 手工填写，覆盖不全 | 90% 以上（App 用户） |
| 里程数据来自 App 轨迹的占比 | — | 越高越准 | |
| 技师减负 | 服务记录平均填写耗时 | 手填用水量、水温、8 个时间点 | AI 草稿上线后明显下降 |
| 数据不丢 | 迁移后客户 / 订单 / 次卡的对账通过率 | — | 100% |
建议在开发启动前，先把「现状」那一列的基线数据测一遍——没有基线就无法证明改进。
8风险与应对
| 风险 | 影响 | 应对 |
|---|---|---|
| 次卡余额迁移出错 | 客户投诉、资金纠纷，最难挽回 | 逐张对账 + 至少两轮全量演练 + 切换后旧系统保留只读一段时间 |
| 一次性切换没有回滚余地 | 业务中断 | 数据库快照级回滚方案 + 选业务低谷日 + 在途订单在旧系统跑完 |
| 抢单模式订单无人接 | 客户干等，体验受损 | 兜底自动转人工 + 派单员告警 + 兜底率纳入监控指标 |
| App 定位权限被员工关闭 | 里程数据缺失 | 三级降级机制 + 权限状态可监控 + 管理制度配合 |
| AI 合规未就绪 | 功能做完了不能上线 | 法务前置，先做 POC 不上生产；合规完成前不投入正式开发 |
| 合作伙伴数据越权 | 严重数据事故 | 框架层强制租户过滤（缺上下文即失败）+ 上线前越权测试 + 跨租户查询全量审计 |
| 历史财务数据对不上 | 客户质疑系统可靠性 | 提前书面说明并取得确认（确认清单第 29 条），不等上线后再解释 |
| 小程序发版按冷启动生效 | 短期内新旧版本并存 | 后端保留一版兼容接口，或加强制更新提示 |
| 服务品类拆分后价格未定 | 阻塞开发 | 确认清单第 1、2 条，标为最高优先级 |
9安全、合规与技术底线
9.1 敏感个人信息
本系统涉及四类敏感信息，处理原则是最小化采集 + 加密存储 + 访问留痕：
| 类别 | 内容 | 处理 |
|---|---|---|
| 健康信息 | 失能程度、插管、基础病、外伤 | 独立存储、加密，仅服务相关角色可见 |
| 身份信息 | 身份证号（降为选填） | 加密存储，列表页脱敏展示 |
| 服务录音 | 现场语音 | 保存 90 天后归档；仅管理者可听；每次调听留审计记录 |
| 位置轨迹 | 技师行程位置 | 仅在「出发」到「结束」之间采集，不做全天候 |
后两类还需要明示知情同意：录音需老人及家属同意（服务协议条款 + 上门口头告知），录音与位置记录均需员工同意（写入员工手册或劳动合同附件）。这两件事不完成，对应功能不能上线。
9.2 四类审计日志
| 日志 | 记录什么 | 用途 |
|---|---|---|
| 订单变更流 | 谁在什么时间把什么改成了什么 | 纠纷追溯 |
| 资金流水 | 每一笔钱的进出，只增不改 | 对账与财务追溯 |
| 录音调听记录 | 谁在什么时间听了哪段录音 | 保护老人隐私与员工权益 |
| 跨租户查询记录 | 总部何时查看了哪家合作伙伴的什么数据 | 合作关系中的信任凭证 |
9.3 技术底线
| 项 | 要求 | 为什么 |
|---|---|---|
| 金额存储 | 一律定点小数，不用浮点 | 浮点做钱必然累积误差，长期对不平 |
| 支付回调 | 幂等键唯一索引，重复投递数据库直接拒绝 | 微信回调会重试，靠应用层判断不可靠 |
| 时段库存 | 缓存扣减 + 数据库唯一约束兜底 | 并发下单不能超卖 |
| 租户过滤 | 框架层强制，缺租户上下文直接失败 | 不能靠开发人员每次记得写条件 |
| 冗余金额字段 | 可存，但必须配定时对账任务，不一致即告警 | 冗余是缓存不是真相，真相在流水 |
| 报表聚合 | 异步计算，不阻塞业务 | 避免报表拖垮下单和派单 |
08 · DECISION CENTER
决策中心
50 项确认中，13 项会影响系统结构、合规前置或开发启动。其余事项可以在对应模块进入设计前逐步确认。
开发前置决策
已决策事项自动计入进度；本页不把浏览器勾选当作正式业务确认。
已决策事项自动计入进度；本页不把浏览器勾选当作正式业务确认。
0 / 13
10.1 服务与定价
1. 泡浴 / 淋浴 / 擦浴的基础参数
新增擦浴、淋浴两个品类后，需要各自确定：
| 泡浴（原深度助浴） | 淋浴 | 擦浴 | |
|---|---|---|---|
| 价格 | 现价 | ？ | ？ |
| 预计服务时长 | ？ | ？ | ？ |
| 需要几名技师（主 + 助） | 建议 1 主 + 2 助 | ？ | ？ |
| 最少几人接单才能成单 | 建议 3 人 | ？ | ？ |
为什么要问时长：时长决定这单占用技师多长时间，影响排班和同一时段能接几单。泡浴要搬浴缸、备水，明显比擦浴长。
备注
2. 上门理发单独下单的价格
上门修脚单独下单和作为附加项都是 180 元（本来就是师傅单独跑一趟）。
上门理发作为附加项是 25 元，单独上门时定价是多少？
单独上门需要单独承担一次上门成本，所以两个价格不同是合理的。
备注
3. 服务品类与技师的匹配
建议：给每位技师标注"可服务品类"（泡浴 / 淋浴 / 擦浴 / 理发 / 修脚），派单时系统只显示能做该品类的技师。
请确认：认可 不需要，所有技师都能做所有品类
备注
4. 还有没有其他要上线的服务品类？
除泡浴、淋浴、擦浴、上门理发、上门修脚外，是否还有计划中的服务（如足疗、陪诊、居家护理等）？
备注
10.2 次卡
5. 次卡的基础规则
| 问题 | 我们的建议 | 请确认 |
|---|---|---|
| 卡绑定给谁 | 绑定到下单客户，其名下所有老人都可使用 | 认可 绑定到指定老人 |
| 有效期 | 建议设置有效期（如 1 年），到期前推送提醒 | 设置，期限 ____ 永久有效 |
| 能否转让给他人 | 建议不可转让 | 认可 允许转让 |
| 能否抵扣附加项 | 建议只抵扣主服务，理发修脚等附加项另付 | 认可 附加项也可抵扣 |
| 退卡规则 | 建议按剩余次数原价退款 | 认可 其他规则：____ |
| 过期未用完 | 建议作废，但可申请延期一次 | 认可 自动顺延 直接作废 |
备注
6. 存量"速通卡"如何处理
新系统不再保留速通卡。现有已售出、未核销完的速通卡，处理方式：
A. 折算成对应的新卡种建议，客户无感
B. 保留核销至用完，但不再销售
C. 按剩余次数退款
选 A 需要明确折算规则（一次速通卡 = 一次哪种卡）。
备注
10.3 下单与收费
7. 押金与空单费是什么关系
- 新增的押金：线下支付客户首次下单需付 200 元
- 现有的空单费：服务当天距开始 2 小时以上取消，收 200 元
两个金额相同，我们的理解是同一笔钱——押金正常完成后退还，客户爽约则转为空单费。
认可，是同一笔钱建议
是两笔钱，客户当天取消需另付空单费
备注
8. 押金的适用范围
仅线下支付客户的首次下单建议
所有首次下单客户，无论支付方式
由门店对特定客户单独标记
其他：____
备注
9. 押金多久退还
订单完成后立即自动退还建议
订单完成后 ____ 天退还
由门店手动确认后退还
备注
10. 纸质合同是否为下单的强制前置
取消电子合同后，改为上传纸质合同扫描件。
A. 首单可先下单，服务前由技师补传；未补传则订单不可完成建议，不影响转化
B. 必须先上传合同才能下单（与现有电子合同流程一致）
C. 合同非必需
备注
11. 合同由谁上传
技师上门时拍照上传建议
客户自助上传
两者都支持
备注
10.4 成本与结算
12. 耗材是否计入成本
一次上门会消耗一次性垫子、洗浴用品等。目前系统中没有耗材记录。
需要计入，登记方式：技师按单登记 门店按月汇总 按服务品类定额估算
不需要计入
备注
13. 除以下项目外，还有哪些成本？
已规划采集：技师人工、服务时长、工作餐、车辆油费、耗材。
是否还有其他？（如场地租金、设备折旧、平台服务费等）
备注
14. 是否需要系统出结算单
目前结算在线下进行、按技师服务次数计算。
A. 系统出结算报表，人工确认后线下发放建议
B. 继续纯线下计算，系统只提供原始数据
C. 系统内完成结算全流程
备注
10.5 AI 能力
15. AI 的定位
五项 AI 能力共用同一份现场录音。其中"自动生成服务日志"是帮技师减负，"识别违规操作"是对技师的监督。
我们的建议是减负优先：
- 录音由技师手动开启，不做静默录音
- AI 生成服务日志草稿，技师核对后提交（涉及责任认定，须有人确认）
- 危险要素识别做成对技师的提示（也是保护技师）
- 违规识别本期不做实时告警，只做事后抽检打标，规则提前公开，结果仅管理者可见，作为培训依据
- 商机识别由 AI 给建议，人工确认后才写入客户档案
理由：如果技师认定这是监督工具，会有各种方式让录音失败（忘记开、放包里录不清、"没传上去"）。录音收不上来，其余四项能力的价值也一起落空。先让技师尝到甜头（省下填表时间），数据才收得上来。
认可上述定位
违规识别需要实时告警（需重新设计）
其他意见：____
备注
16. 知情同意（AI 上线前置条件）
以下两项不是技术问题，但不完成就不能上线：
（1）老人及家属侧
录音会采集健康状况、家庭情况等敏感个人信息，需取得明示同意。
建议：在服务协议中增加条款 + 上门时技师口头告知一次。
认可，由客户方法务出具条款
由我方起草，客户方审核
其他：____
（2）员工侧
持续录音涉及对员工的工作记录，需员工知情同意。
建议：写入员工手册或劳动合同附件，入职时签署。
认可，由客户方人事处理
其他：____
备注
17. 录音保存与调听
已确认：保存 90 天后归档，仅管理者可听，每次调听留审计记录。
补充需确认：归档后保留多久？ 敏感个人信息通常需要设定保留上限。
归档后保留 ____ 年后销毁 长期保留（需法务确认）
备注
18. 是否先做现场实测
浴室水汽噪音大、老人常有方言、家中网络条件差，转写准确率需要真实场景验证。
先录 3–5 个真实服务现场做实测，再确定后续投入建议
直接进入开发
备注
10.6 可依优品
19. 设备和供应链产品卖给谁
卖给合作伙伴 / 同行养老机构（B2B）（我们的理解）
卖给老人家庭（C 端）
两者都有
如果是 B2B，功能可以做得很轻——订货单 + 对公结算即可，不需要购物车、营销活动、在线支付这些 C 端电商功能。
备注
20. 是否有实物库存和发货
自己囤货、自己发货（需要库存管理）
厂家直发（不需要库存）
客户自提
备注
21. 租赁的康复器具是否为自有资产
自有，需要按台管理（每台有编号、状态、消毒记录、维修记录）建议
从第三方调货，不需要台账
备注
22. 租赁面向谁
仅现有助浴客户
对外开放
两者都有
备注
10.7 合作伙伴与多门店
23. 合作伙伴目前处于什么阶段
仅为规划，尚无明确意向方
已有意向方，预计 ____ 前落地
已签约，需在 ____ 前上线
建议：如果尚无明确意向方，数据结构在本期一次做到位（成本很低），平台后台、品牌配置、跨门店报表等功能等第一个合作伙伴确定后再上线（工作量较大）。这样随时可以推进加盟，但不必现在为不确定的计划付全部成本。
现有系统的教训：整套代码里没有"门店"概念，所以现在想支持多门店等于所有数据表重建。这个代价不宜再付第二次。
备注
24. 合作伙伴的合作方式（若已有意向方）
一次性授权费 按订单抽成 年费 组合方式：____
影响是否需要在系统内做分账与加盟金结算。
备注
25. 服务项目和价格由谁定
总部统一制定，各门店不可改（报表口径最清晰）
总部定项目目录，门店在区间内自主定价建议，兼顾灵活性
门店完全自主定价（跨门店收入无法横向对比）
备注
10.8 迁移与上线
26. 线上现有数据量级
迁移工作量评估的前提，请提供大致数字：
| 数据 | 数量 |
|---|---|
| 客户数 | |
| 服务对象（老人）数 | |
| 历史订单总数 | |
| 已售出、未核销完的次卡张数 | |
| 未核销的剩余总次数 | |
| 在职员工数 | |
| 已签合同数 |
次卡两项尤其重要——余额迁移需要逐张核对，量级直接决定这项工作的耗时。
备注
27. 可接受的停服窗口
切换当天需要停服进行数据迁移与核对。
周一凌晨 2–6 点建议，业务低谷
其他时段：____
可接受的最长停服时间：____ 小时
备注
28. 是否有期望的上线时间点
无硬性时间要求，按依赖关系推进
需在 ____ 前上线，原因：____
如有硬性时间点，实施顺序需要倒排。
备注
29. 关于历史财务数据的说明（需知悉）
现有系统没有完整的资金流水记录，历史金额只能从订单反推，无法 100% 还原每笔款项的发生时间和渠道。
因此：切换后的数据完全准确，切换前的历史财务报表建议以原有账目为准，新系统不重现历史统计口径。
已知悉并认可
备注
10.9 派单模式与用工
30. 派单模式（方案新增建议）
现有系统只有人工派单——派单员要在几十个技师里逐个比对排班、技能、位置。单店可行，多门店后派单员会成为瓶颈。
方案提供两种模式，由门店自主配置，也可按服务品类分别设置：
- 人工派单：系统按评分给出推荐人选排序，派单员一键确认或调整（比现在快很多，责任仍在人）
- 开放抢单：订单进入抢单池，符合条件的技师自行抢单
认可两种模式并存、门店自配建议 只做人工派单 只做抢单
备注
31. 抢单模式的组队规则
助浴是 1 主 + N 助的协同作业，不能像滴滴那样谁抢到算谁。方案设计为两段式：
- 主技师位先进入抢单池，先抢到者成为主技师
- 助理位由主技师组队邀请老搭档，或开放抢单
- 兜底：距服务时间不足设定时限仍未组齐，自动转人工派单并通知派单员
认可 助理位不允许主技师邀请，一律开放抢单 其他：____
兜底时限设为多久？ 24 小时 12 小时 其他：____
备注
32. 技师用工类型
方案中"用工类型"是员工档案的必填字段，因为弃单处理必须按它分流。
目前和未来的用工构成：
目前全部是全职雇员，未来可能引入兼职
目前已有兼职
其他：____
备注
33. 弃单处理规则
| 全职雇员 | 兼职按单 | |
|---|---|---|
| 建议处理方式 | 信誉分 + 绩效评价，不涉及费用 | 按合作协议处理，可约定费用 |
| 依据 | 雇员是被安排工作而非自愿接单，罚款缺乏依据 | 自愿接单关系，协议可约定 |
弃单按后果分级，而不是简单数次数：
| 情形 | 建议处理 |
|---|---|
| 提前充足时间放弃，订单仍能补齐 | 记录，不处罚 |
| 临近服务时间放弃 | 扣信誉分 |
| 放弃导致整单人数不足做不成 | 重罚 |
认可上述分级 其他意见：____
正向激励：建议高信誉技师提前 N 分钟看到抢单池（优先挑单权）。激励通常比处罚有效，且对劳动关系更安全。
认可 不需要
备注
34. 撮合排序中"熟人优先"的权重
方案建议把"是否服务过这位老人"作为一个显著的加权因子——养老服务中老人往往希望固定的技师上门。
认可，熟人优先建议 不需要，按就近和负载均衡即可
顺带说明：就近派单会直接减少行驶里程和油费，而里程成本本来就要进成本台账。派单优化和成本控制其实是同一件事。
备注
35. 客户是否应该看到派单过程
技师拒接、抢单没人抢、需要重新指派——这些内部调度过程，客户端是否显示？
一律显示为"安排中"，客户看不到派单过程建议
照实显示，客户能看到"技师已拒接，正在重新安排"
推荐隐藏的理由：这些过程对客户没有任何可行动性，暴露出去只会产生"为什么没人愿意接我的单"的焦虑和投诉。
但隐藏就要给确定性补偿——"安排中"必须附带承诺，例如"我们将在服务开始前 ____ 小时为您确认服务人员"。
请确认这个承诺时限填多久？ ____ 小时
备注
36. 客户在"已确认"后能否看到服务人员
方案建议：订单确认后，客户可以看到即将上门的技师姓名和照片。
认可建议，老人和家属会关心谁来上门
不显示，只显示"已安排 X 名服务人员"
备注
10.10 员工端 App 与位置记录
37. 员工端 App 的分发方式
员工端保留 App 与小程序两种形态，里程记录以 App 为主（微信小程序在完全退出后无法持续定位，做不到准确里程）。
App 如何发给员工？
企业内部分发（不上架应用商店，员工扫码或从内网下载）
上架应用商店（iOS App Store + 安卓各商店）
两者都要
内部分发更快、不用过审核，但 iOS 需要企业开发者账号或 MDM，且证书需要长期维护（过期会导致全员打不开 App）。上架审核对后台定位类应用会要求说明用途，工具类一般能过，但周期更长。
备注
38. 员工位置记录的知情同意
App 会在行程期间记录技师位置。这属于员工关系事项，不解决就不能上线。
写入员工手册，入职时签署建议
单独签署位置记录告知书
由客户方人事统一处理
其他：____
建议向员工这样解释：不是全天候监控，只在点击「出发」到「结束」之间记录，而且里程是用来给你报油费的。这个说法能站得住，也是我们把采集范围限定在行程期间的原因。
备注
39. 是否所有技师都需要装 App
跑车的技师必须装，其他人可继续用小程序建议
全体员工统一装 App
自愿，不强制
若选自愿不强制，会出现同一批订单里程数据精度不一致的情况——方案已支持按来源分级统计，但报表解读时需注意。
备注
40. 技师未装 App 或关闭定位权限时怎么办
自动降级为起终点估算，并标记数据来源建议，至少有数据
不允许记录行程，必须补装
允许手工填写里程，但需管理员审核
备注
10.11 合作伙伴、门店与分成
这一组是目前最不清晰、也最容易在合作后产生纠纷的部分。分成规则本身可以待定，但它依赖的原始数据必须现在就采集齐，否则将来无论用什么规则都算不出来。
41. 平台与合作伙伴的分成方式
一次性授权费（买断系统使用权）
按经营额抽成建议，与合作伙伴利益一致
SaaS 年费 / 月费
组合：基础年费 + 低比例抽成
尚未确定
若选抽成或组合，必须继续回答“分成计算基数”。
备注
42. 分成的计算基数是什么
这是最容易产生分歧的一条，需要逐项明确：
| 项目 | 计入分成基数？ | 我们的建议 |
|---|---|---|
| 服务订单收入 | 是 否 | 计入 |
| 次卡销售款 | 是 否 | 不计入（这是预收款，不是收入） |
| 次卡核销确认的收入 | 是 否 | 计入（服务真正发生时才算） |
| 附加收费项（理发、修脚等） | 是 否 | 计入 |
| 现场追加费用（停车费、远程费等） | 是 否 | 建议不计入——这是成本转嫁给客户，不是经营所得 |
| 空单费 / 违约金 | 是 否 | 建议不计入 |
| 押金 | 是 否 | 不计入（是负债） |
| 器具租赁租金 | 是 否 | 待定 |
| 可依优品商品销售 | 是 否 | 待定 |
基数口径三选一：
按营业额（收入确认口径）建议
按现金流（实收金额）
按毛利（收入减成本）
为什么推荐按收入确认口径：如果按现金流算，卖卡当月分成会暴涨、之后用卡的几个月分成为零，双方对账时都会觉得不合理。按收入确认则每次服务发生时才计入，曲线平滑，也和技师的实际工作量对得上。
按毛利分成最公平但也最复杂——需要双方对每一项成本口径达成一致，且成本数据必须完全透明，实施难度高。
备注
43. 退款与坏账由谁承担
订单退款后，已计提的分成如何处理？
从下期分成中冲回建议，简单可执行
不冲回，由合作伙伴自行承担
双方按比例分担
备注
44. 分成的结算周期与流程
周期：按月 按周 按季 其他：____
流程建议（按 Zenoti 等成熟系统的做法）：
系统自动出账 → 双方在系统内确认 → 线下打款 → 系统标记已结清。
状态可追踪：处理中 / 已结清 / 已冲正 / 已豁免。
认可 只需出报表，结算全线下
备注
45. 技师跨门店调度时，人工成本算哪个门店
同一合作伙伴名下多店时，技师被从 A 店调去支援 B 店的订单：
算接收店（B 店）——谁受益谁承担建议
算派出店（A 店）——按员工归属计
两店按比例分摊
不做门店级分摊，成本只算到合作伙伴层（最简单，见第 42 条）
备注
46. 门店级盈亏核算是否要做
一期只做门店级收入统计，成本算到合作伙伴层建议，省下大量复杂度
完整做门店级盈亏，成本全部分摊到门店
若选完整门店级盈亏，则技师人工、工作餐、车辆油费、耗材都必须逐项分摊到门店，第 41 条也必须有明确答案。
备注
47. 次卡跨门店核销如何处理
同一合作伙伴名下多店时，客户在 A 店买的卡能否在 B 店用？
可以，且不需要清分（同一个老板的钱，只做内部核算口径）建议
可以，但需要门店间清分
不可以，卡只能在购买门店使用
将来若开放跨合作伙伴核销（A 加盟商卖卡、B 加盟商服务），则必须做清分——卖卡方要付钱给服务方。方案已在数据上预留了「售出门店」与「核销门店」两个字段，将来开启不需要改结构。
备注
48. 供货平台（B2B）的结算方式
合作伙伴从平台采购设备和耗材：
先款后货，对公转账
账期结算（月结）
从分成中直接抵扣
其他：____
备注
49. 合作伙伴的数据权属
数据归平台所有，合作伙伴仅有使用权
数据归合作伙伴所有，平台仅有聚合统计权
共有
影响两件事：合作终止时数据如何处理；合作伙伴是否有权导出自己的全量数据。建议在合作协议中明确，系统按协议实现导出能力。
备注
50. 总部查看合作伙伴数据是否需要授权
架构默认可见（平台方提供系统，理应可见）
需合作伙伴授权后可见（类似 ServiceTitan 的邀请–接受机制）
无论选哪个，我们都建议保留审计日志，记录总部何时查看了哪家合作伙伴的什么数据。这在出现争议时是保护双方的证据。
备注
10.12 优先级说明
| 标记 | 含义 | 条目 |
|---|---|---|
| 🔴 | 影响系统结构，需在开发前确认 | 1、5、7、10、15、16、26、30、32、37、38、42、45 |
| ⏱ | 影响工期评估 | 6、23、26、28 |
| 其他 | 可在对应模块开发前确认 | 余下条目 |
建议优先确认 🔴 标记的 13 条，其余可在后续沟通中逐步明确。
关于分成规则的一点说明
第十一节的分成规则可以先不定，不影响开发启动。但有一件事必须现在做：把分成和成本要用到的原始数据全部采集齐。
方案已经按这个思路设计——每一笔钱都进资金流水并标明门店、渠道、收入类目；每一项成本都进成本台账并标明门店、员工、订单。这样将来无论采用哪种分成方式（按营业额 / 现金流 / 毛利，或几种组合），都能直接从历史数据回溯计算，不需要改系统、也不会出现"当初没记所以算不出来"的情况。
反过来，如果现在不采集，将来定了规则也补不回历史数据——这正是现有系统在费用统计上遇到的问题。
09 · FULL REVIEW APPENDICES
详细附录
核心流程、功能规则、数据迁移、风险与合规内容均已进入正文。附录仅保留术语、版本记录和配套文档；如表述冲突，以前文九章的结论为准。
展开术语表、版本记录与配套文档
附录 A · 术语表
沟通中容易混淆的概念，统一如下：
| 术语 | 含义 |
|---|---|
| 客户 | 微信授权下单的人，通常是老人的监护人或家属 |
| 服务对象 | 实际接受服务的老人。一个客户名下可有多位 |
| 技师 / 助浴师 | 上门提供服务的员工，按星级分档 |
| 主技师 | 一单中负责开始、完成、调整费用、填写服务记录的人，对整单负责 |
| 助理 | 同单中的协作技师，只读，不能操作订单 |
| 派单员 | 负责把订单安排给技师的员工 |
| 门店 | 实际经营单位，订单归属于门店 |
| 合作伙伴 | 被授权使用系统的加盟方，是数据隔离的边界。一个合作伙伴可有多家门店 |
| 次卡 | 某个服务项目的 N 次预付卡 |
| 核销 | 用次卡抵扣一次服务，此时才确认收入 |
| 附加收费项 | 挂在主服务上一起做的项目（理发、剪指甲等） |
| 现场收费项 | 服务过程中按实际情况追加的费用（停车费、远程费、爬楼费等） |
| 资金流水 | 每一笔钱进出的独立记录，只增不改，是全系统唯一的账目真相 |
| 三本账 | 现金流（进了多少钱）/ 营业额（赚了多少）/ 待履约负债（欠客户多少） |
| 成本台账 | 技师人工、工作餐、车辆油费、耗材等成本的原始记录 |
| 抢单池 | 开放抢单模式下，符合条件的技师可见并可抢的订单集合 |
| 兜底时限 | 距服务时间不足此时限仍未组齐人手，自动转人工派单 |
| 信誉分 | 技师的接单率、弃单率、准时率、评分的综合，影响抢单优先权 |
| 最少成单人数 | 该服务项目至少几人接单才算安排成功，按项目配置且可关闭 |
附录 B · 版本记录
| 版本 | 日期 | 主要变更 |
|---|---|---|
| v1.0 | 2026-07-28 | 首版：四端蓝图、核心链路、功能设计、数据承接、实施节奏 |
| v1.1 | 2026-07-28 | 派单增加抢单模式与信誉分；补充四角色状态映射 |
| v1.2 | 2026-07-28 | 员工端增加 App 形态，里程精度分三级；补充权限矩阵、成功衡量、风险应对、安全合规、术语表 |
| v1.3 | 2026-07-28 | 50 条待确认事项全文并入第 10 章，本文档自包含 |
配套文档
- 《可依助浴 · 重构项目待确认事项清单》 —— 与第 10 章内容一致的独立文件，便于单独发给客户填写
- 流程图源文件 ——
diagrams/目录下 11 张图，含 SVG 矢量版，可直接用于 PPT 与打印