系统建设方案

水汇 AI 经营管理助手

接入现有收银、会员与预约系统,按模块逐步开发

项目内容
提报对象深圳高端汤泉综合体决策层
方案范围八大模块、三个使用端、四项底层支撑能力
一期范围经营看板、会员运营、口碑与客诉管理
编制日期2026 年 10 月 22 日
版本V1.0

本方案所载测算值均基于公开行业基准推演,用于说明方法与量级,不构成经营承诺。

执行摘要与方案概述

致深圳高端汤泉综合体决策层:本方案把「水汇 AI 经营管理助手」拆解为八个可独立交付的系统模块、三个使用端、四项底层支撑能力,并给出一期范围、验收闭环与分期建议。

方案的核心定位是一句话——AI 负责分析、预测与生成建议,金额计算、核销与预约仍以原业务系统为准。这是一套站在原系统之上的分析与调度层,不替换收银,不重建预约。

全案遵循三条原则。第一,AI 只做分析与生成,所有涉及资金与库存的动作回写原系统执行。第二,模块化渐进开发,八个模块可单独上线、单独验收、单独产生价值。第三,先查原系统再定开发范围,把已经具备的功能直接对接而非重做一遍。

三条贯穿全案的原则

P1 AI 只做分析与生成:金额计算、优惠核销、预约与叫号一律以原业务系统为准。AI 负责数据读取与分析、异常识别与预测、文案与建议生成;AI 的输出必须经人工确认后,再回写原系统执行。不触碰资金与库存安全边界,责任清晰,不会被质疑系统算错了钱。

P2 模块化渐进开发:八个模块相互独立,可单独上线、单独验收、单独产生价值;一期不做的模块不影响已上线模块运行。避免大而全的一次性投入,每期投入都能看到对应回报。

P3 先查原系统,再定开发范围:预约、叫号、核销、排班、库存等属于成熟常规软件功能,开发前必须逐项核查现有系统是否已具备;已具备的直接对接,不重复开发。直接减少开发量与预算,同时降低与原系统运维团队的内部摩擦。

P3 是全案最省钱的一条。核查清单见第四章,逐项走完即可推导出模块 5、6、7 的实际开发范围与投入。最容易踩的坑,是把「AI 平台」做成另一套收银或预约系统。结果是门店两套数据打架,员工要记两套流程,账目对不上。AI 经营管理助手的定位是站在原系统之上的分析与调度层,不是替代层。

一、整体架构

五层结构:最底层是数据与权限,中间是 AI 助手本体,上面是三个使用端,最顶端是原业务系统——原系统始终是数据的唯一权威来源。

(一)五层结构

图 1 整体架构与数据流向
原业务系统 唯一权威 · 只读 收银系统 消费流水 · 金额计算 · 优惠核销 会员系统 档案 · 储值 · 次卡 · 积分 预约系统 预约 · 排期 · 叫号 AI 经营管理助手 分析与调度层 01 AI 经营看板 一期 02 AI 会员运营 一期 03 AI 咨询导购 后续 04 AI 口碑客诉 一期 05 智能预约排队 后续 06 AI 排班备餐 后续 07 AI 能耗分析 后续 08 AI 员工培训 待定 AI 生成 → 人工确认 → 原系统执行 使用端 三端分工 管理后台 老板 · 店长 · 运营(PC 优先) 员工工作端 技师 · 前台 · 保洁(手机优先) 顾客服务端 咨询 · 预约 · 排队(小程序) 数据读取 确认后回写 分析建议 人工反馈 底层支撑 贯穿全平台 建议一期建设 统一数据接口 账号权限 操作日志 知识库管理

实线为系统自动取数与推送建议,虚线为人工确认后的回写与反馈。原业务系统始终是唯一数据权威,AI 不直接改账、不直接核销、不直接改预约。

表 1 整体架构分层
层次 组成 定位与数据流向
原业务系统 收银系统(消费流水、金额计算、优惠核销、会员余额)
会员系统(会员档案、储值、次卡、权益、积分)
预约系统(项目预约、房间与服务人员排期、叫号)
唯一数据权威。AI 只读,不改账
AI 经营管理助手 模块 1 经营看板 · 2 会员运营 · 3 咨询导购 · 4 口碑客诉 · 5 预约排队 · 6 排班备餐 · 7 能耗分析 · 8 员工培训 分析与调度层。向下读数据、向上出建议,建议回写原系统需人工确认
管理后台 老板 · 店长 · 运营 查看数据、审批活动、处理任务。PC 端优先
员工工作端 技师 · 前台 · 餐饮 · 保洁 查询、接单、反馈、培训。手机网页或现有工作平台优先
顾客服务端 到店与潜在顾客 咨询、套餐介绍、预约、排队查询。按需接入小程序
底层支撑能力 统一数据接口 · 账号权限 · 操作日志 · 知识库管理 全平台共用,不产生可见功能但决定八个模块能否被放心铺开

数据流向为:原业务系统经统一数据接口向下供给数据,AI 助手产出分析结果与建议,经三端分流至不同角色;建议需回写原系统执行的,一律先经人工确认。

(二)三个使用端的分工

同一个 AI 能力,在不同端上的形态与深度完全不同。按谁最需要、谁用得最多来分配。

表 2 三端分工
端 使用者 承载功能 形态优先级 不做什么
管理后台 老板、店长、运营 查看数据与经营分析、审批会员活动、处理客诉整改与派单、调整 AI 建议、配置规则与阈值、查看操作日志 PC 端优先,兼顾移动查看 不在此端直接改账、改预约
员工工作端 技师、前台、餐饮、保洁、保安 查询排班预约套餐活动、接单与反馈、上报问题与报损、参与培训与测验 优先手机网页,或直接嵌入现有工作平台 不新增一套独立登录习惯,尽量复用现有账号
顾客服务端 到店顾客与潜在顾客 咨询问答、套餐介绍与推荐、预约入口、排队与余位查询、活动参与 按需接入小程序,公众号亦可 不在此端做核销与支付,导向原系统

员工端选手机网页或现有工作平台而非独立 App,是为了避免一线员工多装一个应用、也多记一套密码。

二、八大模块总览

每个模块独立可交付。下表为总览视图,具体到功能点的开发清单见第五章第三节。

图 2 八大模块分期矩阵
一期 · 建议立即启动 看板 → 会员 → 客诉:三块共用同一套数据底座,边际成本最低,闭环最短 后续 · 视核查结论与投入产出决定 依赖原系统现状。模块 5 须先核查再定范围;模块 7 须先具备分区计量 待定 · 二期验收后评估 培训类需求在前两期数据跑顺后再做,避免空转 1 AI 经营看板 老板及时了解客流、收入和经营异常 数据导入 · 分时客流与收入 · 自动日报 异常提醒 · AI 经营分析 管理后台 依赖流水/预约 2 AI 会员运营 提升老客复购,带动平日消费 会员分组 · 流失提醒 · 回访文案生成 活动审批 · 优惠核销及效果追踪 后台+员工 依赖会员档案 4 AI 口碑与客诉管理 及时发现卫生、餐饮、排队等服务问题 评价投诉导入 · 自动分类 · 整改派单 超时提醒 · 回复草稿 后台+员工 依赖评价平台 3 AI 咨询导购 减少前台重复咨询 帮助顾客选择套餐 门店知识库 · 智能问答 套餐推荐 · 预约入口 转人工 · 可接入小程序 顾客端为主 依赖套餐/知识库 5 智能预约与排队 减少按摩、餐饮及其他 项目的等待 预约管理 · 排期 排队叫号 · 余位查询 AI 预测繁忙时段 先核查再定范围 依赖原系统 6 AI 排班与备餐辅助 缓解忙时缺人、闲时人多 及餐饮浪费 客流预测 · 排班建议 备餐建议 · 人工调整 报损记录及效果比较 管理后台 依赖客流/排班 7 AI 能耗分析 发现异常用水用电 辅助节能 水电气数据接入 分区能耗看板 异常预警 · 节能建议 需硬件计量 管理后台 8 AI 员工培训助手 帮助新人熟悉服务流程和门店规则 员工知识库 · 岗位问答 · 情景模拟 · 培训测验 · 制度版本管理 员工端 依赖制度文档

一期三块先跑通「发现问题—执行行动—核算效果」闭环;模块 5 须先核查原系统、模块 7 须先具备分区计量,满足前置条件前不启动开发。

表 3 八大模块总览
序号 方案模块 可以解决什么 需要开发的系统功能 建议期次
1 AI 经营看板 老板及时了解客流、收入和经营异常 数据导入、分时客流与收入看板、自动日报、异常提醒、AI 经营分析
数据依赖:收银流水、预约、手牌与闸机
一期
2 AI 会员运营 提升老客复购,带动平日消费 会员分组、流失提醒、回访文案生成、活动审批、优惠核销及效果追踪
数据依赖:会员档案与消费流水
一期
3 AI 咨询导购 减少前台重复咨询,帮助顾客选择套餐 门店知识库、智能问答、套餐推荐、预约入口、转人工,可接入小程序
数据依赖:套餐项目数据与门店知识库
后续
4 AI 口碑与客诉管理 及时发现卫生、餐饮、排队等服务问题 评价与投诉导入、问题自动分类、整改派单、超时提醒、回复草稿
数据依赖:评价平台与投诉渠道
一期
5 智能预约与排队 减少按摩、餐饮及其他项目的等待 预约管理、服务人员与场地排期、排队叫号、余位查询、AI 辅助预测繁忙时段
数据依赖:原预约系统
后续,先核查
6 AI 排班与备餐辅助 缓解忙时缺人、闲时人多及餐饮浪费 客流预测、排班建议、备餐建议、人工调整、报损记录及效果比较
数据依赖:历史客流、排班表、库存与销售
后续
7 AI 能耗分析 发现异常用水用电,辅助节能 水电气数据接入、分区能耗看板、异常预警、节能建议,设备控制另做工程评估
数据依赖:水电表读数与分区计量
后续,需硬件配合
8 AI 员工培训助手 帮助新人熟悉服务流程和门店规则 员工知识库、岗位问答、情景模拟、培训测验、制度版本管理
数据依赖:制度文档与培训档案
待定

关于模块 7 的边界需要单独说明:能耗分析只做读数接入、异常识别与节能建议,不下发设备控制指令。任何涉及阀门、泵组、锅炉、冷机的自动控制,都需要单独的工程评估,涉及安全、涉及设备寿命、也涉及责任归属,不属于软件系统的能力范围。

三、底层支撑能力

这部分不产生可见功能,但决定了八个模块能否被放心地铺开。四项均建议在一期建设,不宜延后。

表 4 底层支撑能力
能力 解决什么 关键要求 缺失的后果
统一数据接口 把散在各系统的数据聚到一起,AI 才有一致的输入 与收银、会员、预约系统的接口对接;明确数据同步频率与失败重试机制;数据口径以原系统为准并留存映射说明 各模块数据打架,AI 结论不可信
账号权限 让不同角色只看到该看的数据、能做该做的事 按角色、模块、操作三级授权;敏感字段如手机号与储值余额脱敏;员工仅见本人相关数据 老板看到员工绩效明细,或一线看到全店营收
操作日志 任何一个数字、每一条建议,都能追溯到是谁在何时做的 记录操作人、时间、对象、变更前后值;AI 生成内容单独留档,区分 AI 生成的与人确认的 出现客诉或数据争议时无法定位原因
知识库管理 让门店知识、套餐说明、服务标准成为可复用的结构化资产 门店知识库供咨询导购与培训共用;制度版本管理,新旧版本并存且生效日期可查 咨询导购与培训助手两个模块都无法落地

四、系统职责边界与原系统核查

(一)系统职责边界

这张表是本方案与门店 IT、原系统供应商以及财务之间最重要的对齐依据,建议原样发给对方确认。

表 5 系统职责边界
事项 由谁负责 AI 助手做什么 原因
金额计算 原业务系统 不参与,仅读取结果用于分析 涉及资金准确性,责任不可转移
优惠核销 原业务系统 生成活动方案与优惠券建议,推送至原系统执行 核销涉及库存与账目,AI 不碰
预约与叫号 原业务系统 预测繁忙时段与等待风险,给出加派人手或调整排期建议 预约本身是常规软件功能,先核查是否已具备
数据读取与整合 AI 助手 通过统一数据接口取数、清洗、跨系统关联 AI 的基本功
异常识别与预测 AI 助手 异常提醒、流失预警、客流预测、能耗异常识别、排班与备餐建议 这是 AI 真正的增量价值所在
内容生成 AI 助手 回访文案、客诉回复草稿、培训材料、培训测验题 生成后必须经人工确认再对外发出或执行
建议落地 AI 助手与人协同 AI 出建议,责任人在管理后台确认,推送原系统执行,结果回写用于核算 人机分工明确,责任始终在人
设备控制 工程方 只给建议,不下发控制指令 涉及安全与设备寿命,另做工程评估

全链路的固定动作是:AI 生成,人工确认,原系统执行。这三步出现在每个涉及外发或执行的环节。

(二)原系统功能核查清单

预约、叫号、核销本身属于常规软件功能。先检查原系统有没有,避免把现成功能重新开发一遍,增加成本。下表是执行这条要求的工具,建议在报价前逐项走完。

表 6 原系统功能核查清单
序号 核查功能项 核查方式 若已具备 若不具备
1 预约管理,含项目预约与时段管理
现状预判:很可能有
登录原系统查看是否有预约模块;问运营每天在哪里给客人登记 只做接口对接与繁忙时段预测,不重建 评估自建成本,可与智能排队合并做
2 排期与叫号,含技师与房间排期、排队叫号
现状预判:很可能有
前台是否有叫号屏或手牌机;问技师排班在哪排 对接数据源,AI 只做预测与建议 自建成本高、周期长,建议移至二期并单独评估
3 优惠核销,含券、折扣、次卡核销
现状预判:几乎必有
收银系统是否已支持券与次卡核销 AI 只生成券与活动方案,推送原系统 不补,核销是收银核心能力,应由收银商提供
4 储值与会员余额
现状预判:几乎必有
会员系统是否有储值、余额、次卡管理 只读取余额用于分析 不补,涉及资金安全
5 排班表,含员工班次
现状预判:可能有
问店长目前排班用什么,Excel、排班软件还是靠经验 导入历史排班作为 AI 排班模型的训练输入 本助手提供排班建议模块,生成建议表后人工调整
6 备餐与库存,含食材与报损记录
现状预判:部分有
看是否有库存或盘点系统;问报损怎么登记 对接销售数据做备餐建议 先做轻量报损登记表单即可,不做完整进销存
7 评价与投诉采集
现状预判:大概率没有
门店是否有系统化收集评价的地方,还是靠人工搬运 对接数据做分类与派单 本助手建设导入、自动分类与派单闭环,即模块 4
8 客流统计,含手牌、闸机、客流计数
现状预判:部分有
入口是否有手牌机、闸机或客流计数设备;数据能否导出 直接取数用于分时客流与预测 人工登记或客流计设备补充,属硬件投入单列
9 水电表读数
现状预判:大概率没有
是否有分区计量;能否定期人工抄表 接入读数做分区看板 先人工抄表加表格上传,工程计量另议
10 培训与制度档案
现状预判:大概率没有
问培训记录放在哪、员工怎么学新制度 导入为知识库素材 本助手建设知识库与培训模块,即模块 8

这张表能省下多少:第 1 至 4 项若确认原系统已具备,模块 5 智能预约与排队的开发范围将从完整功能收缩为接口对接加预测建议,工作量大幅下降。一次两小时的系统盘点,可能直接改变一期报价与整体排期。这是整份方案里投入产出比最高的一步。现状预判一列是初筛判断,正式结论以实际核查为准。

五、一期范围与验收闭环

(一)一期三模块

一期只做三个模块:经营看板、会员运营、口碑与客诉管理。理由是这三个模块能最快跑通发现问题、执行行动、核算效果的完整闭环,用真实结果决定后续是否投入排队、排班和能耗系统。

表 7 一期三模块与验收标准
序号 模块 一期交付重点 闭环中的角色 一期验收标准
1 AI 经营看板 数据接入、分时客流与收入看板、自动日报、异常提醒 发现问题:把每天的成本、客流、异常摆在老板面前 日报每日自动生成且老板连续 14 天查看;异常提醒 30 分钟内触达责任人;数据与原系统对账一致
2 AI 会员运营 会员分组、流失提醒、回访文案生成、活动审批、效果追踪 执行行动:把沉睡会员和流失预警变成有负责人、有文案的回访动作 会员分组覆盖全量会员;回访文案由 AI 生成且人工确认后发出;活动效果可按组对比归因
4 AI 口碑与客诉管理 评价与投诉导入、问题自动分类、整改派单、超时提醒、回复草稿 核算效果:把评价变成可派单、可追踪、可验收的整改闭环 评价导入自动分类准确率可接受;每条客诉有责任人与时限;整改超时自动升级;差评响应时长从小时级降到 10 分钟内

三个模块恰好对应闭环的三个环节,形成天然配合而非功能堆砌。

(二)闭环三步

表 8 一期的完整闭环
步骤 名称 内容 承载模块
第一步 发现问题 经营看板自动生成日报,标出客流、成本、评价的异常项;会员运营标出流失风险客群;口碑模块汇总并分类客诉 1 经营看板、2 会员运营、4 口碑客诉
第二步 执行行动 AI 生成回访文案与回复草稿,运营在后台确认后发出;客诉自动派单到具体责任人与时限;异常项进入整改跟踪 2 会员运营、4 口碑客诉、管理后台审批
第三步 核算效果 对比执行前后:沉睡客召回率、复购率、活动核销与投入产出比、客诉响应时长与整改闭环率、评价均分;数据回流优化下一轮建议 1 经营看板、2 效果追踪、4 效果统计

一期的验收方式建议不用功能是否做完验收,而用闭环是否跑通加效果是否可归因验收。具体三件事:日报是否有人看、异常是否有人管;AI 生成的文案是否真的被用起来,看发出量;效果能否按组、按人、按时段对比出差异。跑通这三件,二期的钱才花得明白。

(三)模块功能点清单

表 9 各模块功能点、主用端与数据依赖
模块 功能点 主用端 依赖数据
1 经营看板 数据导入、分时客流与收入看板、自动日报、异常提醒、AI 经营分析 管理后台 收银流水、预约、手牌或客流计数
2 会员运营 会员分组按频次客单偏好沉睡天数、流失提醒、回访文案生成、活动审批、优惠核销及效果追踪 管理后台做策划审批,员工工作端做回访执行 会员档案、消费流水、优惠核销数据
3 咨询导购 门店知识库、智能问答、套餐推荐、预约入口、转人工,可接入小程序 顾客服务端为主,员工工作端可查话术参考 套餐与项目数据、门店知识库
4 口碑客诉 评价与投诉导入、问题自动分类、整改派单、超时提醒、回复草稿 管理后台派单,员工工作端处理 评价平台数据、投诉渠道
5 预约排队 预约管理、服务人员与场地排期、排队叫号、余位查询、AI 辅助预测繁忙时段 顾客服务端与员工工作端 原预约系统,先核查
6 排班备餐 客流预测、排班建议、备餐建议、人工调整、报损记录及效果比较 管理后台由店长调整 历史客流、排班表、库存与销售数据
7 能耗分析 水电气数据接入、分区能耗看板、异常预警、节能建议 管理后台 水电表读数、分区计量
8 员工培训 员工知识库、岗位问答、情景模拟、培训测验、制度版本管理 员工工作端 制度文档、培训档案

六、分期建议

一期范围是既定前提,其余为按依赖与回报排序的建议,最终以一期复盘结果与原系统盘点结论为准。排序依据是共用底层越多越先做、依赖外部越少越先做。

表 10 分期建议
期次 模块 前置条件 排期理由
一期 1 经营看板、2 会员运营、4 口碑与客诉 统一数据接口、账号权限、操作日志 三个模块合计即可跑通完整闭环,效果最容易归因,是后续所有投入的判断依据
二期,建议 3 AI 咨询导购、8 AI 员工培训助手 知识库管理与门店知识整理 两个模块共用同一套知识库,合并做边际成本最低;导购直接减少前台重复咨询,培训直接缩短新人上手周期,回报直观
三期,建议 5 智能预约与排队、6 AI 排班与备餐辅助 第四章第 1、2、5、6 项核查结论 高度依赖原系统盘点结果。若原系统已具备预约与排班能力,则只做对接与 AI 建议;否则自建成本与周期都需重新评估
四期,建议 7 AI 能耗分析 分区计量改造与第四章第 9 项核查结论 软件部分不难,难在硬件计量是否具备;且节能效果需实际改造落地才能兑现,不宜与其他模块同期推进

如果客户想八个模块一次全上,可以接,但要调整验收方式:把八个模块拆成八个独立的验收单元,每个模块单独约定上线时间、单独计费、单独验收。避免变成一个无法分期验收的大项目,否则任何一个模块延期,整个项目都无法结项。

七、落地前三项待办

这份方案要变成能签的合同,缺三样东西。三项都不需要开发,但缺一项,后面所有数字都会被质疑。

表 11 落地前三项待办
序号 待办 责任方 说明 影响
1 原系统功能核查,走完第四章清单 门店 IT 与供应商 逐项确认收银、会员、预约、排班、库存、评价、客流、水电、培训九类功能的现状,输出结论表 直接决定模块 5、6、7 的开发范围与报价
2 数据口径确认 门店财务与运营 明确客流、收入、客单价、复购等指标的计算口径,特别是非营业额收入是否计入 口径不定,看板与投入产出测算全部失去可信度
3 闭环指标基线 门店运营 记录一期上线前的现状值:老客复购率、沉睡会员占比、差评响应时长、评价数与均分 没有基线,效果无法归因,一期验收会变成扯皮

方案承诺与边界声明

本方案不承诺营收增幅,仅承诺可核验的过程指标。

本方案不要求决策层预先理解大模型,全程只需查看经营看板的三张报表。

本方案不介入任何擦边经营,不设计超出监管限额的预付费方案,不生成擦边营销文案,不协助规避监管的表述。相关违规情形一经发现,项目立即终止且不退款。

本方案不推翻现有收银与会员系统,以增量对接方式实施。

本方案中所有金额与占比的测算值,均基于公开行业基准推演,用于说明方法与量级,不构成对门店的经营承诺。正式合作前须以门店实际账单、客流与人力数据进行校准,以双方签署的 ROI 测算确认单为唯一依据。

最后一句提醒:整套系统最容易失败的方式,不是技术做不到,而是建了一套新系统,门店却还在用老系统干活。所以每上线一个模块,都要同步确认谁在什么场景下用它、它替掉了原来哪一步动作。AI 助手是给门店干活的工具,不是给甲方交差的报告。

数据来源说明

行业规模、增速、客群结构、成本占比、流失率、坪效基准等数据引自公开行业报告与媒体报道,包括但不限于:美团行业数据、中国商业联合会沐浴专业行业调研、头豹研究院洗浴行业分析、培哲设计洗浴行业大数据、《中国休闲洗浴产业发展白皮书》,以及锦江酒店、华住集团、麦当劳中国、首旅如家、温德姆等企业公开披露的数字化实践数据。

标的特征描述基于公开报道,实际参数以现场核实为准。方案遵循行业合规底线,不介入任何违规经营设计。