# 客满房管理中台与多端产品蓝图 V6

> 2026 年 10 月 3 日更新：本轮酒店工作台按照“承接经营、增收赋能、降本共享、财务与组织”四层导航重组，多端边界、收入/支出与营销归因以 [非房收入模型与多端边界蓝图](非房收入模型与多端边界蓝图.md) 为准。以下 V6 内容保留为既有功能和原型实现说明；其中“三个业务域”描述早期范围，不再代表整个工作台的一级导航。

版本日期：2026 年 9 月 30 日。本文根据本轮业务说明定义新版 UI；涉及金额、比例、酒店、商户和姓名的页面数据均为演示数据。

第 1—9 节描述目标业务、页面结构与完整系统边界；第 10 节按当前 V6 代码说明本轮已经提供的交互及尚未接入的能力。产品蓝图中的规划操作，不等于原型已经实现真实后台。


## 0. V6 本轮新增功能与评审顺序

本轮围绕“门店每天怎么用、每一步谁负责、门店怎么持续增长”完成 V6。PC 与小程序同一迭代同步实现、联调和验收，不拆成两个长期阶段。

1. **服务商入驻方式**：服务商直接添加酒店/商户，或生成邀请码邀请机构登记；邀请码关联服务商，登记账号归入对应组织。
2. **新机构首页与登录**：首页默认酒店入口；新酒店、商户可用登记用户名与演示口令从登录页进入自己的工作台。
3. **员工账户、当值与操作日志**：酒店 PC 明确员工管理入口；创建员工、岗位、授权与启停，显示真实账号和班次，每次关键业务变更保留操作人、对象和前后值。
4. **岗位权限**：按组织、岗位、数据范围、字段和操作控制 PC 与小程序菜单；技师只看本人任务，前台不看完整财务。
5. **资料完善（P0）**：酒店名称、房量、开业时间、照片、钻级、省市区和项目；商户/服务商机构资料；各类用户本人信息。资料编辑不修改账号授权。
6. **供货目录与门店在售（P0）**：商户维护主商品、库存与履约范围；酒店管理选品、新建本店商品、上下架和授权调价；本店价格不覆盖别店与历史订单。
7. **三来源商机与酒店订单、基础日历（P0）**：酒店共享、服务商上传、趣会议等工具上传的会议/团队商机抢单报价、客户确认和未支付需求转介；协议单位进入资源认领跟进；按日/月查看已确认订单并点击进明细，状态与改期同步。
8. **驿呼百应服务/商品**：房内扫码创建服务和商品订单；商户接单派工，本单技师到店核销与服务，酒店只读经营、核销结果和收益。
9. **收入与个人提成（P0）**：客房单列、非房分账；个人中心展示本人的提成汇总和明细，个人提成与订单分账分别记账。
10. **服务商拓店资源（P1）**：小程序底部添加酒店/商户；资源公海领取、电话联系、酒店情况回填与后续跟进；首页收入前十榜单同周期同口径。
11. **单层推荐增长（P1）**：服务商发展门店、酒店推荐酒店；追踪直接推荐人、登记与首单达标，奖励单独审核，不因注册计奖。
12. **CRM 与高级排期（P1）**：人脉、协议单位公海、有效期；场地容量、资源冲突、人员排班、改期提醒。
13. **伙伴分红（P2）**：伙伴贡献台账、分红规则、批次与审批，独立于订单分账、推荐奖励和酒店跨店甩单。

上述 1–9 是 P0 可接单与收入闭环；10–12 是 P1 渠道增长和运营效率；13 是 P2 伙伴分红协作。实际开发按 [开发计划](开发计划.md) 的 1–14 明细排序。新功能入口见 [V6 产品总览](overview.html#v6-features)。

### V6 入口与权限答案

| 用户关心的操作 | 入口 | 谁可以操作 |
|---|---|---|
| 在售产品、上/下架、调价、新建本店商品 | 酒店 PC → 在售产品；酒店小程序对应产品管理入口 | 当前店长可操作商品调价及在售；前台和财务不开放此权限；服务价由商户维护 |
| 酒店添加员工 | 酒店 PC → 员工管理 | 有团队管理权的店长；新增账号只获得岗位上限内的权限 |
| 谁当值、谁操作过 | 酒店 PC → 当值 / 操作日志 | 本人登记当值；有审计权者查本店日志，保留实际账号责任 |
| 上传会议、团队、协议单位 | 客满房非房收入 → 底部上传（订单中心与分账之间） | 授权酒店员工；协议单位进入资源池认领，会议团队进入商机池抢单报价 |
| 酒店资料 | 酒店 PC / 小程序 → 完善酒店资料 | 当前由店长维护机构资料；名称、房量、开业时间、照片、钻级等；员工编辑本人信息 |
| 本人提成与资料 | 客满房非房收入 → 我的 | 本人只看自己的明细；机构财务汇总单独授权 |
| 服务商新增机构 | 服务商小程序 → 底部添加 | 机构入驻权限；酒店/商户分别登记 |
| 资源公海与跟进 | 服务商 PC / 小程序 → 资源公海 | 授权拓店员工；拨号动作与联系结果分别记录 |
| 推荐奖励 | 酒店/服务商 → 推荐增长；总部 → 营销与推荐 | 直接推荐人看自身进度；总部管理员审核达标奖励 |

## 1. 业务定位与本次调整

平台统一名称为 **客满房非房收入服务平台**。核心产品是连接总部、服务商、酒店门店、商户和一组独立获客小程序的管理中台。

本版采用三个业务域。三者共享组织、产品、订单、权限和账本，但其售卖主体、履约主体、操作按钮和收入归属分别定义。

| 业务域 | 产品范围 | 售卖/承接主体 | 履约主体 | 酒店端能做什么 | 酒店收益展示 |
|---|---|---|---|---|---|
| 酒店大消费 | 会议、团队商机及承接后的订单；协议单位资源后续产生实际订单；保留婚庆、宴会等既有订单 | 承接酒店 | 承接酒店及其资源 | 接单、报价、资源确认、执行、甩单、售后协同 | 酒店营业收入；关联客房收入单列 |
| 到店服务 | 上门按摩等由外部商户提供的服务 | 提供服务的商户 | 商户/被指派技师 | 查看经营、核销、异常、酒店分成；报告现场问题 | 场所/渠道分成 |
| 商品售卖 | 客房用品、饮品零食、旅行应急等商品 | **酒店** | 供货及配送商户 | 查看销售、履约、售后和酒店分成；有授权的店长管理选品 | 商品销售对应的酒店收益 |

商品售卖按本轮明确要求采用“酒店为售卖主体、商户为供货/履约方”。订单详情必须同时展示“售卖酒店”和“供货/履约商户”。售卖主体不意味着酒店前台代替商户接单、备货或配送。商品售后由酒店查看经营情况并协同，实际退换货由对应履约方处理；收款、履约和售后承担方在订单及产品配置中分别记录。

到店服务沿用客人在房间预约服务的场景。“到店”指商户服务人员进入酒店提供服务；产品和服务不是酒店提供。酒店只看到经营及核销结果，无接单、派技师、开始服务、完成服务、修改核销状态按钮。

## 2. 两个独立用户入口与一个工具中心

### 三类统一来源与归因

| 来源 | 谁上传 | 会议 / 团队如何处理 | 协议单位如何处理 |
|---|---|---|---|
| 酒店共享 | 酒店授权员工 | 进入商机池，由匹配酒店抢单、报价 | 进入协议资源池，由酒店认领跟进 |
| 服务商上传 | 服务商授权员工 | 进入同一商机池，服务商跟进推送而不代酒店抢单 | 进入同一协议资源池，服务商保留上传及后续跟进视图 |
| 趣会议等工具上传 | 工具用户或工具导入入口 | 进入同一商机池，酒店报价后客户确认 | 进入同一协议资源池，跟进单位意向而不直接产生收入 |

每条商机固定保留来源类型、具体来源名称、上传机构、上传人、上传时间。页面第三类来源显示“获客工具上传”，旁边显示“趣会议”等具体工具。当前承接/认领酒店是另一个字段；抢单、认领、退回与跨店甩单记录流转事件，不重新写入来源。协议单位资源和未支付预算不进入经营实收、分账或排行榜。

### 趣会议及后续获客工具

趣会议是独立用户小程序，从公域获客，上传会议、团队和协议单位商机。它属于“趣会议等工具上传”来源；另外两类来源是“酒店共享”和“服务商上传”。同一套平台继续接入其他专项获客工具时，保留具体工具名称，统一归入工具来源，不把工具名写成商机类型。

会议 / 团队：酒店共享、服务商上传、工具上传 → 平台校验匹配 → 统一商机池 → 酒店抢单报价 → 客户确认 → 订单支付、资源锁定与履约 → 售后及分账。

协议单位：同样三类来源 → 协议单位资源池 → 酒店认领 → 跟进与合作协议 → 后续实际订单。认领单位资源不等于已有订单或收入。

酒店分享潜在需求时形成“酒店共享”商机；服务商可以上传会议、团队和协议单位商机，供酒店承接。上传机构、上传人、上传时间与来源固定留存。酒店已有订单资源不足时，仍可按规则跨店甩单，客户同意后由目标酒店报价并重新确认承接主体。甩单不改原始来源和上传人，也不删除历史订单。

### 驿呼百应

驿呼百应是放在酒店房间里的独立扫码小程序，负责到店服务和商品售卖。

客人扫码 → 识别酒店/物料点位 → 选择商品或预约服务 → 下单 → 商户接单 → 商品配送或技师到店核销后服务 → 客人确认 → 售后处理 → 达到结算条件后分账。

商品订单展示售卖酒店和履约商户；服务订单展示服务商户和所属酒店场景。二维码只提供酒店/位置上下文，不证明实名入住。酒店页面订阅状态和酒店份额，不控制商户履约。

### 总部工具中心

每个工具保留：工具名称、唯一标识、独立小程序标识、业务域、支持品类、获客渠道、绑定区域、路由规则、门店覆盖、线索量、有效订单量、成交转化、关联客房量。

趣会议与驿呼百应作为已展示的两种工具；后续工具仅预留扩展位，不冒充已上线产品。

## 3. 多端架构与页面数量

B 端有四种组织入口，每种都有 PC 和小程序；C 端有趣会议、驿呼百应两种独立小程序入口。合计 **10 个业务页面**，另设统一登录页和原型总览页。

| 端口 | PC 首页定位 | 小程序首页定位 | 默认数据范围 |
|---|---|---|---|
| 酒店门店 | 酒店非房业务工作台、直接接单、场景经营与收益 | 客满房非房收入：前台待办、接单、经营数据、只读核销 | 本酒店；可切有权门店 |
| 客满房商户 | 商品/服务订单、人员、履约、商品及收入 | 随身份变化的接单/员工/技师工作台 | 本商户；员工进一步收窄 |
| 服务商 | 所辖酒店/商户经营汇总、入驻与员工管理 | 拓店、入驻、员工与运营跟进 | 所辖区域及绑定主体 |
| 客满房超级中台 | 总部经营驾驶舱与六大管理域 | 总部移动看板、权限与财务 | 全平台，按总部角色授权 |
| 趣会议用户 | 不设业务 PC | 提交需求、报价、订单、客户确认 | 本人/授权企业需求 |
| 驿呼百应用户 | 不设业务 PC | 房内商品和服务、订单、售后 | 本人订单及扫码场景 |

产品端是中台的“产品管理域”，不是新增一个没有组织归属的登录身份。酒店选品、商户供货目录、总部产品审核是同一产品在不同身份下的视图。

PC 顶部品牌统一为“客满房非房收入服务平台”，通过“总部中台 / 服务商 / 商户 / 酒店门店”工作空间标识区分身份，不能将企业品牌替换成某一业务模块名。

## 4. 六大管理域：汇总 → 列表 → 单主体详情

所有管理域采用统一导航结构：顶部汇总指标，中间筛选和列表，点击行进入详情抽屉或详情页；明细保留列表筛选条件。指标必须标明时间范围和统计口径。经营交易额、收益、预计分成、可结算金额不能混用。

### 4.1 服务商管理

- 汇总：服务商数、启用数、覆盖城市、绑定酒店数、活跃酒店数、绑定商户数、本期有效成交额、服务收益、待跟进异常。
- 列表：名称、区域、负责人、门店数、商户数、有效订单、服务收益、合作状态、最近跟进。
- 详情页标签：基础资料、团队成员、酒店门店、商户、订单、服务收益、拜访/巡店、合同与日志。
- 操作：新增/邀请、分配区域、绑定主体、设置责任人、查看结算、启停合作。主体归属变更记录有效时间，不改写历史订单归属。

### 4.2 酒店门店管理

- 汇总：签约酒店、上线酒店、活跃门店、大消费订单、到店服务订单、商品订单、非房营业/分成收益、关联客房间夜、待处理异常。
- 列表：门店名称、所属服务商、省/市/区县、店长、已开通非房项目、上线状态、业务订单与收益；支持省→市→区县联动，并与项目、名称、状态组合筛选和重置。
- 详情页标签：门店资料、经营总览、大消费订单、到店服务及核销、商品销售、产品绑定、房间/物料码、员工权限、分账明细、运营记录。
- 操作：审核门店、配置产品、绑定服务商/商户、管理房间点位、查看订单和账本、设置门店角色。前台只见授权业务和本门店。

### 4.3 商户管理

- 汇总：合作商户数、服务型/商品型商户数、在岗技师、待接单、履约中、超时/争议、商户应收、已结算。
- 列表：商户名称、类型、服务区域、绑定酒店、在售产品、接单率、履约准时率、售后量、合作状态。
- 详情页标签：商户资料、门店覆盖、产品、订单、员工/技师、排班、服务范围、收入结算、售后与审计。
- 操作：审核、启停、关联服务范围、设置可履约产品、配置角色。总部和服务商不代商户完成服务。

### 4.4 产品管理

- 汇总：酒店大消费资源数、到店服务产品数、商品 SKU 数、在售/待审/下架数、已覆盖酒店、有效订单与交易额。
- 列表：产品、业务域、分类、售卖主体、供应/履约方、适用酒店、价格版本、库存/时段、分账规则、上下架状态。
- 详情页标签：基础资料、销售/履约主体、规格与价格、库存/资源时段、适用门店、分账规则版本、订单表现、售后规则、修改记录。
- 酒店大消费：场地、餐饮、婚庆和住宿资源可组合报价，住宿科目单列。
- 到店服务：时长、预约时段、服务半径、可派技师、商户接单时限、核销规则。
- 商品：SKU、规格、供货价、售价、库存、配送范围/时效、售后承担和酒店收益规则。
- 操作：新增、审核、选品绑定、上下架、配置价格与分账。规则版本仅影响生效后的订单；历史订单保留快照。

### 4.5 财务分账

- 汇总：支付成功总额、退款、待履约金额、预计各方分成、冻结金额、可结算金额、本期已结算、异常账单。
- 列表按“订单账本/主体账单/结算批次”切换；避免将一张订单的多个科目重复计算为多笔订单。
- 单订单详情：业务域、订单号、来源、售卖/履约主体、酒店、服务商、支付记录、房餐会/商品/服务科目、折扣与退款、各方份额、冻结原因、规则版本、结算记录。
- 单主体详情：期初、本期新增、本期退款/冲正、本期冻结/解冻、本期结算、期末余额，能追溯到订单。
- 状态分开：预计 → 支付确认 → 履约完成 → 售后条件满足 → 可结算 → 审核 → 已结算；退款与争议可冻结并冲正。
- 直接承接酒店大消费收入、酒店场所分成、商品酒店收益分行展示；关联客房收入和间夜单独展示，不混入非房收入。
- 目标财务操作：对账、导出、申请结算、审核、登记结算结果。本轮已提供财务汇总、订单明细与总部 CSV 导出；结算申请、审批和资金划转尚未接入。

### 4.6 权限管理

- 汇总：账户数、已启用数、待邀请数、角色模板数、异常权限申请、最近敏感操作。
- 列表：姓名/账号、所属组织、角色、PC/小程序权限、数据范围、状态、最近登录。
- 详情：账户、组织归属、角色模板、功能权限、数据范围、金额可见性、授权有效期、操作日志。
- 权限维度：组织范围、功能、记录范围、字段、动作、渠道；同一账号 PC 和小程序共享权限配置，终端交互可以不同；岗位职责上限相同。
- 模板可复制并收窄，越权扩展需由有权管理员审批；本人不可提升自身权限。停用员工应同步撤销 PC 和小程序授权。

## 5. 身份与权限矩阵

共有 **12 种 B 端岗位**：总部 3 种、服务商 3 种、酒店 3 种、商户 3 种。权限以“组织 + 身份 + 数据范围 + 动作”决定。UI 隐藏按钮与前端判断用于演示岗位差异，正式后端仍必须逐次校验权限。

| 组织/身份 | PC 主要权限 | 小程序主要权限 | 金额可见性 | 禁止操作 |
|---|---|---|---|---|
| 总部超级管理员 | 全平台配置、主体、工具、角色、审计 | 全局经营、关键异常、审批 | 按授权全量 | 无日志直接篡改历史账本 |
| 总部运营 | 服务商、酒店、商户、产品与订单查询 | 经营数量、主体明细、订单进度 | 默认隐藏财务金额 | 结算、修改分账、代业务方履约 |
| 总部财务 | 账务明细、导出与审计 | 财务汇总与分账明细 | 授权范围财务明细 | 代商户履约、代酒店抢单 |
| 服务商老板 | 辖区组织汇总、经营、团队、服务收益 | 辖区看板、团队待办、收益 | 本服务商收益和授权经营数据 | 跨服务商查看、修改总部规则 |
| 服务商运营员工 | 负责酒店/商户、产品与订单跟进 | 所辖门店、商户、订单进度 | 默认隐藏经营金额与结算 | 酒店抢单、商户接单、资金审批 |
| 服务商财务 | 本服务商账务查询、分账明细 | 本服务商财务汇总与账单 | 本服务商份额 | 代门店接单、代商户履约、查看其他服务商账本 |
| 酒店老板/店长 | 本店经营、直接接单业务、选品、员工、酒店账单 | 店铺经营、关键待办、收益 | 本店数据及本店份额 | 修改商户履约/技师状态 |
| 酒店前台 | 大消费待办及授权核验、到店服务核销结果、商品销售 | 本店接单提醒、订单查询、异常上报 | 按授权显示订单金额；默认不展示完整分账 | 商品/服务接单派工、修改分账规则 |
| 酒店财务 | 本店对账、收益、结算记录、导出 | 收益与账单查询、异常反馈 | 本店财务明细 | 商户派工、总部结算审核 |
| 商户老板 | 本商户经营、订单、产品、人员、结算、角色 | 商户经营、待办、员工、收入 | 本商户收入和结算 | 其他商户/平台完整账本 |
| 商户调度/员工 | 授权订单接单、商品备货配送、技师派工、售后 | 待接单、待配送、待派工、异常 | 订单履约所需金额；默认无老板利润 | 全商户财务、修改分账、配置老板权限 |
| 商户技师 | 本人已派服务任务，可演示切换技师 | 本人任务、服务位置、开始服务、提交完成 | 默认不展示经营金额与分账 | 他人订单、全部客户、商户派单规则 |

技师看到的是商户已经分派给自己的任务；到店核销、开始服务与提交完成分别记录。商户订单“接单”与技师执行任务是两个不同动作，技师不能越过商户接收全量订单。核销凭证绑定订单、技师与状态，不可重复核销；核销不表示付款、服务已完成或收入已结算。

酒店不参与到店服务核销。“经营核销数据”是只读结果；客户在驿呼百应下单后，由该订单的技师到店完成核销，服务后再由客户确认。酒店不存在代核销按钮，授权也不能突破这一业务职责上限。

## 6. PC 登录与工作空间

登录页标题固定为“客满房非房收入服务平台”。入口依次为酒店、商户、服务商、总部中台，默认酒店；酒店小程序名“客满房非房收入”。提供三种方式：

1. **短信 + 密码验证**：手机号、短信验证码、登录密码；验证码有获取/倒计时入口。
2. **用户名 + 密码**：用户名、登录密码。
3. **微信扫码**：扫码区、刷新、扫码后确认状态；已有账号绑定成功后进入对应组织。

登录后若只有一个组织身份，直接进入工作台；有多个时选择工作空间和身份。角色由账号真实授权决定，正式登录页不能通过下拉选择“超级管理员”取得权限。原型可提供明确标注“演示身份”的快捷入口。

PC 与小程序共享组织身份，登录状态和入口分离。微信扫码只是认证方式，不自动授予后台权限。登录异常、设备会话和身份切换保留审计记录。

## 7. 首页与详情页布局建议

### 总部 PC

左侧导航：经营总览、服务商、酒店门店、商户、产品、订单中心、财务分账、获客工具、权限设置、操作日志。

首页上方显示“全平台 / 日期 / 区域 / 业务域”筛选；指标卡分开显示“非房交易额、酒店收益、活跃门店、待办异常”。中部左侧为三业务趋势/占比，右侧为待处理事项；下方放服务商/酒店/商户排行榜，表格行可以进入详情。

### 酒店 PC

工作台首页：待接大消费订单、商品销售、到店服务核销结果和累计非房应计收益。演示订单使用样例日期，不能把累计样例称为今日实际收入。三个清晰标签：酒店大消费、到店服务、商品售卖。

大消费显示接单、报价、资源、执行和甩单。到店服务显示经营与核销数据，商品售卖显示销售与商户配送进度；两者都显示本店分成，隐藏商户内部操作。

### 商户 PC

首页按经营业务切换“到店服务 / 商品供货”，显示待接单、履约中、异常单、商户收入。老板可进入人员、产品、结算；调度主要看派工和备货；技师不得使用老板概览。

### 服务商 PC

首页显示辖区汇总，再下钻到酒店/商户明细；突出门店上线进度、扫码活跃、酒店大消费响应、商户履约异常及服务收益。提供跟进动作，不替代交易双方操作。

### 四个 B 端小程序

- 总部：总览 / 待办 / 组织 / 我的；点指标进入对应明细。
- 服务商：首页 / 订单 / 添加 / 分账 / 我的（按岗位隐去无权项）；添加包含酒店与商户，资源公海从首页和全部功能进入；首页展示同口径的收入前十，员工金额按授权隐藏。
- 商户：工作台 / 订单或任务 / 人员或收入 / 我的；身份切换后页面、数据、按钮一起变化。
- 酒店：首页 / 订单中心 / 上传 / 分账 / 我的；上传包含会议商机、团队商机、协议单位，首页突出三来源商机池和本店非房收益。没有财务权限时对应位置显示权限说明，不暴露金额。

所有列表至少有一处能点开完整明细；仅有汇总数字、无法查看组成数据的卡片不能算“汇总加明细”完成。

## 8. 订单与账本的共同数据模型

```text
组织：总部 → 服务商（辖区）→ 酒店/商户关联关系
账号：用户 → 组织成员 → 角色 → PC/小程序权限 → 数据范围
产品：业务域 → 项目类型 → 售卖主体 → 履约主体 → 适用门店 → 价格/分账版本
订单：初始来源 + 工具 + 渠道 + 扫码点位 + 业务类型
      + 来源酒店 + 承接酒店 + 售卖主体 + 履约商户 + 执行员工/技师
      + 订单状态 + 支付状态 + 售后状态 + 结算状态
账本：订单 → 科目行 → 各方份额 → 冻结/退款/冲正 → 主体账单 → 结算批次
```

最低字段建议：

- `businessDomain`：`hotel_consumption` / `on_site_service` / `goods_retail`。
- `category`：`meeting` / `wedding` / `team` / `banquet` / `agreement` / `massage` / `goods`。
- `source`：原始业务来源，既有记录保留；不被抢单、认领或甩单覆盖。
- `sourceKind`：商机来源分类，对应酒店共享、服务商上传、获客工具上传；具体工具另存 `sourceToolName`，如趣会议。
- `sourceEntityId` / `sourceEntityName`：原始上传机构快照；`sourceEmployeeId` / `sourceEmployeeName`：原始上传人快照；`sourceCreatedAt`：上传时间。后续承接机构与操作员工另记。
- `toolId`：趣会议/驿呼百应/后续获客工具的标识。
- `campaignId`、`channelId`：具体公域活动和渠道，能追溯获客表现。
- `sceneHotelId`、`qrPointId`：酒店场景和房间/公共点位。
- `originHotelId`、`servingHotelId`：原酒店和当前承接酒店。
- `sellerOrgId`、`fulfillerOrgId`：售卖主体和履约主体。
- `serviceProviderId`：订单发生时负责服务商的归属快照。
- `assigneeId`：被授权履约员工/技师。
- `pricingVersion`、`splitRuleVersion`：价格与分账的订单快照。
- `orderStatus`、`paymentStatus`、`afterSalesStatus`、`settlementStatus`：四组分离状态。

## 9. 本轮 UI 验收条件

1. 四个 B 端都有 PC 和小程序入口，总部新增移动端；两个用户小程序保持独立。
2. PC 品牌名称正确，登录页有三种登录方式，演示身份有明确提示。
3. 超级中台具备服务商、酒店门店、商户、产品、财务分账、权限六域，每个都有汇总、列表、明细。
4. 酒店端分开显示大消费、到店服务、商品售卖；只有大消费出现酒店直接接单/报价/甩单。
5. 到店服务明确显示“商户提供服务，酒店获得场景分成”，核销由酒店只读。
6. 商品详情明确显示“酒店售卖、商户供货履约”，不能继续把商户默认写成商品售卖主体。
7. 商户老板/员工/技师切换后，数据范围、菜单和操作发生可见变化；技师仅显示本人任务。
8. 财务汇总可下钻到订单及分账行，预计收益不能显示为已经到账。
9. 趣会议保持独立公域获客；驿呼百应保持酒店扫码商品/服务场景。
10. 酒店甩单保留原来源和原酒店，客户确认后才能更换承接酒店；客房成交及间夜单列。
11. 所有权限和资金功能在原型中注明演示，不能声称已经完成真实鉴权、微信认证、支付或结算。

## 10. 本轮交付与实际交互边界

### 10.1 页面与运行方式

V6 页面集中在 `kemanfang-v2/v6/`，首页登录为 `index.html`，产品总览为 `overview.html`；`login.html` 保留为兼容登录入口。酒店入口名称为“客满房非房收入”。业务页面共 10 个：总部、服务商、酒店、商户各有 PC 和小程序，加上趣会议与驿呼百应两个独立用户小程序原型。

这是无需构建的静态 HTML/CSS/JavaScript 原型，小程序通过手机界面在浏览器中预览，不是可提交微信审核的小程序工程。

### 10.2 本轮已经提供的交互

| 模块 | 当前可操作内容 | 当前边界 |
|---|---|---|
| 总览与登录 | 酒店默认入口、酒店→商户→服务商→中台顺序、三种登录预览；预置和新登记的本地机构/员工账号登录 | 演示口令 `demo`，不是真实认证；短信示例码 `246810` 不发送短信，微信无真实登录二维码 |
| 服务商入驻 | 服务商直接新增酒店或商户，或生成邀请码→登录登记页填资料→建立本地机构与账号；归属邀请服务商 | 同浏览器本地入驻，未接真实审核或短信邀请 |
| 新机构首页 | 新机构在所属服务商和中台列表出现，可用登记用户名回首页登录对应空间 | 不能跨设备同步，不能当作正式账号安全验证 |
| 员工与权限 | 新建员工、选择所属机构/岗位/权限、启停与身份切换；PC/小程序使用同一本地账号和授权配置 | 前端校验体现业务设计，正式接口仍需后端鉴权和会话撤销 |
| 总部超级中台 | 六域汇总、订单与账本明细、导出、岗位矩阵、日志；酒店省市区+项目+名称/状态联动筛选 | 真实合同、结算审批与转账未接入 |
| 商户产品 | 新增、编辑商品/服务、价格、库存、上/下架及所属履约商户，用户端读取对应可售范围 | 无真实并发库存锁和支付扣减，使用演示配置 |
| 酒店直单 | 会议/团队商机按三来源归集，酒店抢单及分项报价；本店已有大消费订单保留履约、日历与受限一次跨店转介 | 录入合同价不代表真实付款；外部客户确认仍需独立证据，酒店不能代客户确认 |
| 酒店运营 | 会议活动日历、人脉档案、协议单位公海、合伙人分红入口及本地记录 | 基础订单日历和区域筛选属 P0；高级资源排期及 CRM 属 P1，伙伴分红属 P2；未发生真实分红支付 |
| 酒店在售 | PC 与小程序查看本店在售、调整商品售价/状态、新建绑定履约商户的本店商品 | 当前店长操作；到店服务价由商户维护；无真实并发库存锁 |
| 员工当值与审计 | 酒店员工入口、当值登记、按实际员工记录业务动作；查看订单/售价等变更快照 | 原型记录业务变更，不把所有浏览点击称为完整生产审计；正式补服务端不可篡改存储 |
| 资料与个人中心 | 酒店名称/房量/开业/照片/钻级；机构负责人资料维护；员工和驿呼百应用户本人资料、酒店个人提成与推广入口 | 照片存在本地；本人资料不改变岗位，示例提成不代表实付 |
| 酒店移动上传 | 底部上传会议/团队商机、协议单位，首页统一商机池与累计非房收入入口 | 协议单位保存为客户资源；本地刷新显示数据，不是真实服务器实时推送 |
| 服务商增长 | 底部添加机构、公海领取/拨号入口/跟进回填、累计应计收入前十 | 拨号不等于已联系；排行含待结算/冻结，按实际服务商数展示 |
| 单层推荐 | 酒店/服务商推荐码与登记归因、首单达标；总部 PC 与小程序同步规则查看/编辑、奖励审核及状态明细 | 规则编辑/审核仅超级管理员；已审核不等于打款；资格失效转冻结；不设置多层抽佣 |
| 商户履约 | 已支付样例接单、派工、备货、配送、技师本人任务、开始服务及提交完成 | 新建未支付订单不能接单；技师不看老板总流水与完整客户池 |
| 趣会议 | 公域需求表单、本人需求、酒店报价确认 | 未支付预算不计 GMV；未实现生产级并发抢单锁 |
| 驿呼百应 | 扫码酒店场景、按门店/商户范围展示商品服务、预约/商品下单、本人订单 | 创建为待支付，不发起微信支付；服务由商户提供，商品酒店售卖、商户履约 |

服务商的邀请入口产生 `login.html?invite=...` 登记页；邀请码绑定服务商和机构类型，校验状态后登记。新机构用户名及员工账号保存为本地演示账号，口令统一 `demo`。不要输入真实凭证。

PC 与小程序在同一业务迭代同步评审和交付，不能把小程序开发推迟到 PC 全部结束之后。本轮新增能力用于验证数据归属、界面和流程，不表示已接通真实生产系统。

### 10.3 已支付、客房与非房收益的代码口径

`data.js` 的汇总只把 `payment === '已支付'` 的订单计入实收交易额及已支付口径的分账收入。用户新建订单一律 `payment='未支付'`、`settlement='unpaid'`，需求参考金额、酒店报价及预计分账不会自动进入实收。

每笔订单区分以下字段：

| 字段 | 含义 | 汇总规则 |
|---|---|---|
| `amount` | 订单总额或未支付需求参考金额 | 只有已支付订单进入实收统计 |
| `roomAmount` / `roomShare` | 酒店大消费中关联客房金额 | 客房单列，不纳入非房交易额；当前示例归属酒店 |
| `hotelNonRoomShare` | 酒店取得的非房部分收益 | 酒店 PC、小程序的非房分账使用本字段 |
| `hotelShare` | 酒店总份额 | 等于 `roomShare + hotelNonRoomShare`，不能直接作为非房收益 |
| `merchantShare` | 实际商户份额 | 服务/商品履约方所得 |
| `providerShare` | 服务商份额 | 订单所属服务商所得 |
| `platformShare` | 平台份额 | 订单金额减去其余各方份额，保持分账合计一致 |

当前分账计算：`非房基数 = amount - roomShare`；大消费/到店服务/商品使用各自演示比例。`roomShare + hotelNonRoomShare + merchantShare + providerShare + platformShare = amount`。比例和规则版本是原型样例，不是正式计费承诺。

界面中的“预计分账”可包含未支付有效需求的测算值，并单独标注；“已支付口径收入”不等于已经到账。“待结算”可包含尚未履约完成或售后条件未满足的订单；`pending` 不代表可提现。只有明确满足条件的状态才应视为可结算；本轮不生成真实结算批次，也不自动划转资金。

### 10.4 12 岗权限与本地状态

实际默认岗位为：

- 总部：`hq_admin`、`hq_ops`、`hq_finance`。
- 服务商：`service_owner`、`service_ops`、`service_finance`。
- 酒店：`hotel_manager`、`hotel_frontdesk`、`hotel_finance`。
- 商户：`merchant_owner`、`merchant_staff`、`merchant_technician`。

总部权限矩阵提供总览、订单、履约、财务、供货产品、门店在售、门店调价、资料、审计、推荐营销、资源公海、团队、授权等能力的前端演示配置。页面进一步保留业务职责限制，例如服务商不得代履约，酒店不得操作服务/商品履约，技师仅访问本人任务。PC 和小程序均读取 `data.js` / `model.js` / `growth.js` 中同一组组织、员工与岗位配置；配置变化存入当前浏览器的本地状态。

V6 使用独立 `data.js`、`model.js`、`growth.js`、`opportunities.js` 和 `kmf_v6_*` 本地存储。数据仅在同一浏览器、同一协议/域名/端口下共享；重新打开或刷新相关页面可读取同源保存状态。不同设备、浏览器或域名不自动同步。前端菜单隐藏、字段过滤与操作判断用于展示权限设计，不构成真实账户鉴权或服务端数据隔离。

### 10.5 V6 内的上传与跨店转介

酒店 PC 与“客满房非房收入”小程序提供会议、团队和协议单位上传入口；服务商及趣会议等工具也可提供这三类商机。会议/团队在统一商机池抢单报价，协议单位在资源池认领跟进。既有本店订单保留订单管理和日历，不因商机模式调整被删除或重置。每次上传固定记录原始来源、机构、人员和时间；未支付预算、协议单位资源均不计收入。

已有需求仅在“酒店大消费、未支付、未进入履约、未转介过”的情况下开放一次跨店转介。到店服务、商品订单和已支付大消费单不提供此动作。转介保留原订单号、初始来源、原酒店及原状态/报价/承接信息，并记录目标酒店、原因与客户同意。

目标酒店接单 → 提交新报价 → 等待客户确认新酒店和方案。原酒店能够查看转介进度，不能代新酒店报价或代客户确认。

- **趣会议本人需求**：在当前演示用户的“我的订单”中确认方案；确认后才把当前酒店及所属服务商、售卖/履约主体迁移至新酒店，原酒店和来源继续保留。订单仍然未支付，不自动计入收入或结算。
- **酒店上传的线下需求**：本轮可演示到目标酒店报价、待客户确认；没有酒店代客户确认按钮。正式独立客户确认入口尚待接入，页面明确保持待确认状态。

用户小程序只展示当前演示身份自己创建的需求，不因酒店上传而自动取得这些订单的客户身份。V6 可独立演示上传及转介，旧版订单不自动导入。

### 10.6 后续生产接入

正式实施时再统一服务端订单、组织关系、价格版本、来源归因、角色权限及账本，接入真实账号、短信、微信登录、小程序、支付、客户确认通知、库存、预约排班与结算。目前可交互页面用于确认业务和 UI，不代表这些生产能力已经上线。


## 11. 开发顺序与主要评审交付

详见 [开发计划与验收](开发计划.md)。本轮重点评审机构入驻、新账号登录、员工权限、商品配置、酒店订单、管理与用户多端同步。每次演示应从业务起点推进到可核对的结果；P0、P1、P2 的验收边界分别签收。

## 12. V6 经营与增长规则

### 12.1 门店在售与价格责任

供货商户维护主商品、服务项目、库存和覆盖酒店。门店在售记录单独保存酒店、商品、可售状态、门店售价、调价人、时间和版本。酒店店长能选择本店销售商品、在许可边界内调整商品售价；当前前台和财务岗位不开放调价。到店服务价格仍由履约商户维护。员工有订单权不代表有调价权。新建本店商品需要指定有效履约商户，不能把商户员工派工、库存等权限一并授给酒店。

商户停用、产品下架、门店停售、区域不覆盖或商品缺货时，不允许新下单。每笔新订单保存成交价、供货关系和分账版本；历史订单不随目录价格变化。页面中供货价、客人售价、酒店收益应使用不同字段和标签。

### 12.2 当值与操作归因

登录员工是每一次操作的责任账号，班次描述当时的工作安排；二者不能互相替代。记录员工 ID/姓名/岗位、机构、PC 或小程序渠道、当值班次、对象、操作结果、时间和变更前后。交班不抹去原员工日志；停用账号不删除历史归因。日志提供操作人、对象和操作内容搜索，酒店只能查本店，总部按岗位查授权范围；正式工程补充日期检索与完整审计导出。

个人中心的提成汇总下钻到本人订单或推荐记录，保留规则版本和预计/已结算/冲正状态。实际操作者、业务获客人、推荐人、提成受益人分别记录，不能因员工点击一次订单就重新归属提成。

酒店员工可在本人推广入口取得专属驿呼百应链接/推广码，绑定酒店及员工。消费者通过该入口下单时保留推广归因，后续满足规则后产生该员工的提成记录；来源无法核实时不补填“当值员工”。注册机构的推荐奖励和住客订单的个人推广提成是两个独立活动与台账，后台审核机构奖励不能自动均分给所有员工。

### 12.3 服务商资源公海与跟进

公海资源是待拓展机构线索，尚未成为平台酒店；和酒店端“协议单位公海”是两个资源域。服务商员工领取资源 → 电话联系 → 回填酒店情况、结果与下次动作 → 邀请登记或直接建档 → 上线 → 首单激活。拨号按钮只发起本机拨号或显示号码，不能自动记录“已联系”；结果由员工确认填报。资源领取、重复资料、归还与转机构保留原始来源和员工。

服务商首页榜单显示前十，实际不足十家则按实际数量。榜单说明周期与收入状态，使用已支付订单的累计应计服务商分账（providerShare），含待结算/冻结，不等同已到账；不能混入酒店交易额、未支付预算和推荐未审核奖励。无财务权限者隐藏金额。后续增加有效新店、首单率、30 日活跃和退款后净收益，避免只按招募数量排行。

### 12.4 推荐关系与奖励

支持服务商推荐酒店/商户，以及酒店推荐其他酒店。只奖励直接推荐，不建立多层级抽佣。推荐码绑定机构、员工及类型；登记保留来源，单一目标只保留一个有效推荐归因。

推荐发起 → 目标机构登记 → 审核上线 → 首笔有效订单完成、支付且已结算 → 达标待审 → 总部审核 → 后续财务发放。只注册不产生奖励，审核通过不等同资金已付。退款、取消、重复目标、自荐等应排除或冲正；归属纠纷由总部按证据处理。

原型奖励规则为示例，可在总部“营销与推荐”调整。历史推荐保留创建时的规则快照；调整仅影响新推荐记录。推荐奖励、员工提成、伙伴分红与四方订单分账各自建账，避免重复统计收入。正式支付奖励需确认预算、承担方、到账周期及售后追回方式。

### 12.5 资料完善

酒店资料包含名称、房量、开业时间、图片与钻级，标明钻级是门店填报还是平台审核；机构负责人、地址与服务范围供运营使用。用户本人资料独立于机构，编辑昵称、姓名或联系方式不能修改岗位、所属组织和提现账户授权。驿呼百应收集完成订单所需的资料，展示用途；照片和联系人不进入公开排行榜。


## 本轮硬件与异业联盟增量

硬件 UI 与本地模拟交互已补充，详见 [硬件接入与协作开发](硬件接入与协作开发.md)。正式后端、厂家真实沙箱及单店试点按 G4–G6 关卡推进。

异业联盟尚处方案阶段，详见 [异业联盟业务方案](异业联盟业务方案.md)：酒店导流外部商户消费、商户反向提供酒店商机、现有酒店跨店甩单分开建模。新增联盟消费核销权属于实际履约商户；酒店推荐收益与商户成交额分别核算；会议/团队/协议单位沿用三来源并扩展渠道归因。