docs: refresh c-end mini program prototype docs
This commit is contained in:
@@ -12,14 +12,30 @@
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
|
||||
### 第一步补充：如果当前目标是重新按租户后台真实能力校正文档
|
||||
- 先看 `docs/12-租户管理员功能重构梳理/00-总览.md`
|
||||
- 再按批次看 `docs/12-租户管理员功能重构梳理/`
|
||||
- 当前已完成批次包括：
|
||||
- `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/07-精细化运营与不前置能力.md`
|
||||
- 对已完成批次，以该目录下文档结论优先
|
||||
|
||||
### 第二步：再理解链路
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/05-页面清单总表.md`
|
||||
|
||||
### 第三步：再理解版本与映射
|
||||
### 第三步：再理解版本、映射与当前执行顺序
|
||||
- `docs/08-全周期版本规划与范围分层.md`
|
||||
- `docs/09-租户后台与C端功能映射总表.md`
|
||||
- `docs/10-全周期研发实施顺序与交付清单.md`
|
||||
- `docs/11-V1.0页面开发执行清单与验收标准.md`
|
||||
|
||||
> 如果你发现 `docs/09` 的描述和 `docs/12-租户管理员功能重构梳理/` 已完成批次冲突，以 `docs/12` 为准。
|
||||
|
||||
### 第四步：开始搭页面
|
||||
- `docs/06-通用组件清单.md`
|
||||
@@ -63,11 +79,18 @@
|
||||
- 秒杀活动页
|
||||
- 限时折扣活动页
|
||||
|
||||
如果当前目标是对齐正式 `Taro` 仓库的 `V1.0` 落地顺序，则以：
|
||||
- `docs/11-V1.0页面开发执行清单与验收标准.md`
|
||||
|
||||
作为更细的页面执行顺序依据。
|
||||
|
||||
## 4. 文档使用规则
|
||||
|
||||
### 4.1 页面规格优先
|
||||
如果某个页面的单页规格文档与总文档描述不同，以单页规格为准。
|
||||
|
||||
但如果该页面所属范围已经在 `docs/12-租户管理员功能重构梳理/` 中完成重构批次，则以 `docs/12` 的结论优先。
|
||||
|
||||
### 4.2 结构先于视觉
|
||||
本套文档优先定义：
|
||||
- 页面区块顺序
|
||||
@@ -86,6 +109,10 @@
|
||||
- `docs/08-全周期版本规划与范围分层.md`
|
||||
- `docs/09-租户后台与C端功能映射总表.md`
|
||||
- `docs/10-全周期研发实施顺序与交付清单.md`
|
||||
- `docs/11-V1.0页面开发执行清单与验收标准.md`
|
||||
|
||||
如果争议来自“旧原型设计”和“后台真实能力”不一致，再优先参考：
|
||||
- `docs/12-租户管理员功能重构梳理/`
|
||||
|
||||
## 5. 交付标准
|
||||
|
||||
@@ -96,4 +123,3 @@
|
||||
- 每个区块具备文档要求的字段与交互
|
||||
- 页面具备默认态、空态、异常态、禁用态等必要状态
|
||||
- 业务对象和后台配置关系清晰可追溯
|
||||
|
||||
|
||||
@@ -8,10 +8,10 @@
|
||||
|
||||
| 编码 | 页面名称 | 路由建议 | 页面层级 | 说明 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `T01` | 首页 | `pages/tab/home/index` | Tab | 选店、活动导流、推荐 |
|
||||
| `T01` | 首页 | `pages/tab/home/index` | Tab | 当前门店摘要、动态活动导流、推荐 |
|
||||
| `T02` | 点餐 | `pages/tab/menu/index` | Tab | 商品浏览、加购、结算入口 |
|
||||
| `T03` | 订单 | `pages/tab/orders/index` | Tab | 订单列表、履约、售后 |
|
||||
| `T04` | 我的 | `pages/tab/me/index` | Tab | 资产、消息、服务、复购 |
|
||||
| `T03` | 订单 | `pages/tab/orders/index` | Tab | 顾客视角订单列表、履约、售后 |
|
||||
| `T04` | 我的 | `pages/tab/me/index` | Tab | 身份、资产、服务、复购聚合 |
|
||||
|
||||
### 1.2 二级页面
|
||||
|
||||
@@ -43,7 +43,7 @@
|
||||
| `C01` | 商品详情抽屉 | 底部抽屉 / 右滑抽屉 | 点餐页 | 规格、加料、数量选择 |
|
||||
| `C02` | 购物车抽屉 | 底部抽屉 | 点餐页 | 已选商品清单 |
|
||||
| `C03` | 登录授权弹层 | 中央弹窗 / 底部弹层 | 全局 | 订单与资产前拦截 |
|
||||
| `C04` | 优惠选择弹层 | 底部抽屉 | 结算页 | 券、积分、余额选择 |
|
||||
| `C04` | 手动资产选择弹层 | 底部抽屉 | 结算页 | 优惠券、余额、次卡选择 |
|
||||
| `C05` | 支付方式弹层 | 底部抽屉 | 结算页 | 微信支付 / 余额支付 |
|
||||
| `C06` | 地址选择抽屉 | 底部抽屉 | 结算页 | 快捷切换地址 |
|
||||
|
||||
@@ -70,17 +70,34 @@
|
||||
## 4. 页面显示规则
|
||||
|
||||
### 4.1 Tab 页面
|
||||
|
||||
- 保持底部 TabBar 可见
|
||||
- 顶部导航不显示返回按钮
|
||||
- 页面滚动位置可按产品需要保留
|
||||
|
||||
### 4.2 二级页面
|
||||
|
||||
- 显示顶部导航和返回按钮
|
||||
- 进入后覆盖当前 Tab 内容
|
||||
- 返回时回到来源页面
|
||||
|
||||
### 4.3 抽屉与弹层
|
||||
|
||||
- 不应中断当前页面上下文
|
||||
- 应支持手势关闭 / 点击遮罩关闭（支付与关键确认除外）
|
||||
- 关闭后保留当前页面已选状态
|
||||
|
||||
## 5. 当前使用规则
|
||||
|
||||
- 如 `docs/07-页面规格/` 与本文件冲突，以单页规格为准
|
||||
- 如 `docs/12-租户管理员功能重构梳理/` 已完成批次与本文件冲突，以 `docs/12` 为准
|
||||
- 当前已冻结的关键边界包括：
|
||||
- 首页活动区是动态精选，不是固定八宫格
|
||||
- 场景切换必须受门店 `serviceTypes` 约束
|
||||
- 结算页手动资产选择当前只确认：
|
||||
- 优惠券
|
||||
- 余额
|
||||
- 次卡
|
||||
- `积分抵扣` 当前不作为已冻结结算能力
|
||||
- 消息中心页当前保留页面职责，但未冻结完整 inbox 结构
|
||||
|
||||
|
||||
@@ -3,20 +3,24 @@
|
||||
## 1. 用户身份与登录
|
||||
|
||||
### 1.1 可匿名浏览的范围
|
||||
|
||||
- 首页
|
||||
- 门店选择页
|
||||
- 点餐页基础浏览
|
||||
- 商品详情查看
|
||||
- 活动会场基础浏览
|
||||
|
||||
### 1.2 必须登录 / 绑定手机号的动作
|
||||
|
||||
- 提交订单
|
||||
- 使用优惠券、积分、储值、次卡
|
||||
- 使用优惠券、余额、次卡
|
||||
- 查看“我的”资产
|
||||
- 查看消息中心
|
||||
- 查看订单与售后
|
||||
- 提交退款申请
|
||||
- 提交评价
|
||||
|
||||
### 1.3 登录拦截方式
|
||||
|
||||
- 优先使用 `C03 登录授权弹层`
|
||||
- 拦截后登录成功，应返回原业务场景继续执行
|
||||
|
||||
@@ -31,11 +35,14 @@
|
||||
| `dine_in` | 堂食扫码 | 需要门店和桌号 |
|
||||
|
||||
### 2.2 门店选择规则
|
||||
|
||||
- 顾客必须在“某一家门店”下点单
|
||||
- 同一时间购物车只属于一个门店 + 一个场景
|
||||
- 切换门店时，应提示当前购物车可能清空
|
||||
- 场景切换必须受门店真实 `serviceTypes` 约束
|
||||
- 切换门店或切换场景时，应提示当前购物车可能清空
|
||||
|
||||
### 2.3 堂食规则
|
||||
|
||||
- 堂食优先由扫码进入
|
||||
- 扫码后自动识别门店与桌号
|
||||
- 堂食场景默认不展示配送地址与配送费模块
|
||||
@@ -43,7 +50,9 @@
|
||||
## 3. 商品与价格规则
|
||||
|
||||
### 3.1 商品展示规则
|
||||
|
||||
- 商品按分类展示
|
||||
- 商品与类目展示必须按当前场景过滤
|
||||
- 支持热销、招牌、新品、推荐等标签
|
||||
- 商品在以下情况下显示不可售：
|
||||
- 售罄
|
||||
@@ -52,13 +61,17 @@
|
||||
- 当前场景不可售
|
||||
|
||||
### 3.2 SKU 与规格规则
|
||||
|
||||
- 规格做法与加料均在商品详情抽屉中完成
|
||||
- 当商品启用多规格时，价格与库存以 SKU 为准
|
||||
- 简单商品可直接加购
|
||||
- 套餐商品必须先完成套餐组选择
|
||||
- 如果规格变化导致库存不足，应立即提示
|
||||
|
||||
### 3.3 费用结构
|
||||
|
||||
结算时至少展示以下金额项：
|
||||
|
||||
- 商品金额
|
||||
- 打包费
|
||||
- 餐具费
|
||||
@@ -73,62 +86,88 @@
|
||||
| 类型 | 说明 |
|
||||
| --- | --- |
|
||||
| 优惠券 | 满减券、折扣券、免配送费券 |
|
||||
| 积分 | 获取、抵扣、兑换 |
|
||||
| 积分 | 获取、兑换；是否支持订单抵扣当前不冻结 |
|
||||
| 储值余额 | 充值后可支付订单 |
|
||||
| 次卡 | 对特定商品或分类核销 |
|
||||
| 会员等级 | 折扣、积分倍率、生日权益、会员日权益 |
|
||||
|
||||
### 4.2 资产使用原则
|
||||
- 顾客端只负责展示可用资产和命中结果
|
||||
### 4.2 使用原则
|
||||
|
||||
- 顾客手动选择的资产当前只确认：
|
||||
- 优惠券
|
||||
- 余额
|
||||
- 次卡
|
||||
- 自动命中的结果当前主要包括：
|
||||
- 满减
|
||||
- 新客优惠
|
||||
- 会员折扣
|
||||
- 免配送费
|
||||
- 具体叠加、互斥、优先级由后台规则决定
|
||||
- 若资产不可用，必须给出原因说明
|
||||
|
||||
### 4.3 典型不可用原因
|
||||
|
||||
- 未达到金额门槛
|
||||
- 不适用当前门店
|
||||
- 不适用当前场景
|
||||
- 不适用当前商品
|
||||
- 已过期
|
||||
- 已使用
|
||||
- 余额不足
|
||||
|
||||
## 5. 订单状态规则
|
||||
|
||||
### 5.1 订单状态定义
|
||||
### 5.1 顾客视角状态分组
|
||||
|
||||
| 状态值 | 中文名称 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| `pending_pay` | 待支付 | 已提交订单，未完成支付 |
|
||||
| `paid_wait_accept` | 已支付待接单 | 等待商家处理 |
|
||||
| `preparing` | 制作中 | 商家已接单，正在备餐 |
|
||||
| `delivering` | 配送中 | 外卖场景履约中 |
|
||||
| `wait_pickup` | 待自提 | 自提场景等待到店取餐 |
|
||||
| `dine_in_serving` | 堂食进行中 | 堂食场景订单进行中 |
|
||||
| `finished` | 已完成 | 订单已履约完成 |
|
||||
| `refunding` | 退款中 | 售后处理中 |
|
||||
| `refunded` | 已退款 | 退款已完成 |
|
||||
| `closed` | 已关闭 | 超时取消或主动取消 |
|
||||
订单页顶层统一使用顾客任务语言：
|
||||
|
||||
- 全部
|
||||
- 待支付
|
||||
- 进行中
|
||||
- 已完成
|
||||
- 售后
|
||||
|
||||
### 5.2 顾客可感知的细分状态
|
||||
|
||||
- 商家处理中
|
||||
- 制作中
|
||||
- 配送中
|
||||
- 待取餐
|
||||
- 已完成
|
||||
- 退款中
|
||||
- 已退款
|
||||
- 已取消
|
||||
|
||||
### 5.3 订单动作与状态对应
|
||||
|
||||
### 5.2 订单动作与状态对应
|
||||
- `待支付`：可继续支付、取消订单
|
||||
- `已支付待接单 / 制作中`：可查看详情、催单、部分场景可申请退款
|
||||
- `配送中 / 待自提 / 堂食进行中`：可查看履约信息
|
||||
- `进行中`：以查看详情和查看履约信息为主
|
||||
- `已完成`：可评价、再来一单
|
||||
- `退款中 / 已退款`：可查看退款详情
|
||||
- `售后`：可查看退款详情
|
||||
- `已取消` 等结果态：以查看信息为主
|
||||
|
||||
## 6. 消息通知规则
|
||||
当前不把以下能力冻结为所有订单的固定动作：
|
||||
|
||||
### 6.1 消息分类
|
||||
- 催单
|
||||
- 取餐码查看
|
||||
- 骑手轨迹
|
||||
|
||||
| 类型 | 内容范围 |
|
||||
| --- | --- |
|
||||
| 订单消息 | 支付成功、接单、出餐、配送、退款处理 |
|
||||
| 营销消息 | 发券提醒、活动开始、会员日提醒 |
|
||||
| 系统通知 | 门店公告、规则更新、服务通知 |
|
||||
## 6. 消息与服务规则
|
||||
|
||||
### 6.2 消息行为
|
||||
- 未读消息需要角标或红点提示
|
||||
- 进入消息详情或打开消息中心后，消息可置为已读
|
||||
- 消息应能跳转到对应业务页面
|
||||
### 6.1 消息中心边界
|
||||
|
||||
- `P16 消息中心页` 当前保留页面职责
|
||||
- 当前已知后台事实源更接近“运营发送中心”，不是顾客 inbox
|
||||
- 因此下列能力暂不冻结为正式前台契约：
|
||||
- 完整消息分类
|
||||
- 未读 / 已读状态流转
|
||||
- 消息点击跳转规则
|
||||
- 消息角标数量
|
||||
|
||||
### 6.2 帮助中心边界
|
||||
|
||||
- `P17 帮助中心页` 当前作为服务兜底页保留
|
||||
- FAQ 分类、帮助文章 CMS、在线客服、电话客服等动态能力当前不冻结
|
||||
|
||||
## 7. 页面通用状态
|
||||
|
||||
@@ -141,13 +180,15 @@
|
||||
- 网络重试态
|
||||
|
||||
### 7.1 典型空态
|
||||
|
||||
- 无门店可选
|
||||
- 当前分类无商品
|
||||
- 无可用优惠券
|
||||
- 无可见券模板
|
||||
- 无历史订单
|
||||
- 无消息
|
||||
- 暂无可展示消息
|
||||
|
||||
### 7.2 典型错误态
|
||||
|
||||
- 网络异常
|
||||
- 定位失败
|
||||
- 支付失败
|
||||
@@ -161,4 +202,5 @@
|
||||
- 结算相关页面必须把金额明细解释清楚
|
||||
- 场景切换、门店切换、地址切换属于高风险动作，需要在必要时提示购物车清空
|
||||
- 同一页面的主要操作按钮文案要稳定，不同页面不要频繁变形
|
||||
- 活动页必须导流回商品、购物车、结算主链路，不单独生长成一套交易系统
|
||||
|
||||
|
||||
@@ -1,113 +1,241 @@
|
||||
# 核心用户流程
|
||||
|
||||
- 文档目标：把顾客在小程序中的核心路径梳理成稳定流程，供页面设计、路由设计、状态设计和验收使用。
|
||||
- 使用边界：本文件描述的是“顾客流程”，不是“商家后台流程”，也不是“后端字段清单”。
|
||||
|
||||
---
|
||||
|
||||
## 1. F01 外卖下单流程
|
||||
|
||||
### 流程目标
|
||||
让用户从“选门店”顺利进入“外卖点餐”，完成地址校验、优惠结算和支付。
|
||||
|
||||
### 流程步骤
|
||||
1. 用户进入首页
|
||||
2. 系统尝试定位并推荐最近门店
|
||||
3. 用户确认或切换门店
|
||||
4. 用户选择 `外卖` 场景
|
||||
5. 用户进入点餐页浏览商品
|
||||
6. 用户打开商品详情抽屉选择规格、加料、数量
|
||||
7. 用户加入购物车
|
||||
8. 用户打开购物车并点击去结算
|
||||
9. 进入结算确认页
|
||||
10. 选择或新增配送地址
|
||||
11. 系统校验配送范围、起送价、配送费
|
||||
12. 用户选择优惠券 / 积分 / 储值等资产
|
||||
13. 用户确认金额并支付
|
||||
14. 进入支付成功页
|
||||
15. 跳转订单详情查看履约进度
|
||||
让顾客从进入小程序开始，完成门店确认、外卖点餐、地址确认、结算支付和订单查看。
|
||||
|
||||
### 主流程
|
||||
|
||||
1. 顾客进入首页。
|
||||
2. 系统展示当前门店和可用场景。
|
||||
3. 顾客确认当前门店，或进入门店选择页切店。
|
||||
4. 顾客切换到 `外卖` 场景。
|
||||
5. 顾客进入点餐页浏览分类和商品。
|
||||
6. 简单商品直接加购，复杂商品进入商品详情抽屉选择规格或组合。
|
||||
7. 顾客打开购物车抽屉确认已选商品。
|
||||
8. 顾客进入结算确认页。
|
||||
9. 顾客选择或新增配送地址。
|
||||
10. 系统展示配送相关校验结果和金额试算结果。
|
||||
11. 顾客确认手动资产选择：
|
||||
- 优惠券
|
||||
- 余额
|
||||
- 次卡
|
||||
12. 系统展示自动优惠命中结果：
|
||||
- 满减
|
||||
- 新客优惠
|
||||
- 会员折扣
|
||||
- 免配送费
|
||||
13. 顾客确认订单并支付。
|
||||
14. 进入支付成功页。
|
||||
15. 顾客进入订单页或订单详情页查看状态。
|
||||
|
||||
### 核心判断点
|
||||
- 地址是否在配送范围内
|
||||
- 是否达到起送门槛
|
||||
- 优惠是否可用
|
||||
- 当前门店是否营业
|
||||
|
||||
- 当前门店是否支持外卖。
|
||||
- 地址是否有效，是否需要补全。
|
||||
- 配送范围、配送费、起送条件是否满足。
|
||||
- 简单商品和复杂商品是否走了正确加购路径。
|
||||
- 结算页是否区分了手动资产和自动优惠。
|
||||
|
||||
### 当前冻结边界
|
||||
|
||||
- `积分抵扣` 当前不作为已冻结结算能力写入主流程。
|
||||
- 支付方式页面表达当前只先冻结为 `微信支付` 和 `余额支付`。
|
||||
|
||||
---
|
||||
|
||||
## 2. F02 自提下单流程
|
||||
|
||||
### 流程目标
|
||||
让用户选择门店和自提时间，完成到店取餐订单。
|
||||
|
||||
### 流程步骤
|
||||
1. 用户进入首页或点餐页
|
||||
2. 选择 `自提` 场景
|
||||
3. 浏览商品并加入购物车
|
||||
4. 进入结算确认页
|
||||
5. 选择自提时间段
|
||||
6. 填写取餐人信息
|
||||
7. 使用优惠资产
|
||||
8. 完成支付
|
||||
9. 支付成功页展示取餐时间与取餐入口
|
||||
10. 订单详情页展示取餐码和门店信息
|
||||
让顾客在当前门店支持自提时，完成自提场景下的点餐、结算和支付。
|
||||
|
||||
### 主流程
|
||||
|
||||
1. 顾客进入首页或点餐页。
|
||||
2. 顾客确认当前门店支持 `自提`。
|
||||
3. 顾客切换到 `自提` 场景。
|
||||
4. 顾客浏览商品并完成加购。
|
||||
5. 顾客进入购物车抽屉确认商品。
|
||||
6. 顾客进入结算确认页。
|
||||
7. 页面展示自提门店信息和自提场景说明。
|
||||
8. 顾客确认联系人信息、备注信息和可用资产。
|
||||
9. 系统展示自动优惠命中结果和应付金额。
|
||||
10. 顾客完成支付。
|
||||
11. 进入支付成功页。
|
||||
12. 顾客进入订单详情页查看订单状态和取餐说明。
|
||||
|
||||
### 核心判断点
|
||||
- 当前门店是否支持自提
|
||||
- 所选时间段是否可预约
|
||||
- 是否满足活动与优惠使用条件
|
||||
|
||||
- 当前门店是否支持自提。
|
||||
- 自提场景下是否错误要求顾客填写配送地址。
|
||||
- 结算页是否正确展示自提门店信息而不是外卖地址卡。
|
||||
|
||||
### 当前冻结边界
|
||||
|
||||
- 自提后续展示要以“顾客下一步怎么做”为中心，不把商家后台履约动作直接搬到顾客端。
|
||||
- `取餐码` 当前不作为所有版本都必须先写死的固定能力。
|
||||
|
||||
---
|
||||
|
||||
## 3. F03 堂食扫码点餐流程
|
||||
|
||||
### 流程目标
|
||||
让顾客通过扫码快速绑定桌号，进入堂食点餐和加菜流程。
|
||||
|
||||
### 流程步骤
|
||||
1. 用户扫码进入小程序
|
||||
2. 进入堂食扫码确认页
|
||||
3. 系统展示门店、桌号、当前桌台信息
|
||||
4. 用户确认进入堂食点餐
|
||||
5. 点餐页切换为 `堂食` 场景
|
||||
6. 用户选择商品、规格、加料并加入购物车
|
||||
7. 进入结算确认页
|
||||
8. 页面默认带出堂食门店与桌号
|
||||
9. 用户确认订单并支付
|
||||
10. 订单详情展示桌号和堂食状态
|
||||
11. 用户可再次进入点餐页继续加菜
|
||||
让顾客通过扫码进入堂食上下文，确认桌台后开始点餐，并在后续可以继续加菜。
|
||||
|
||||
### 主流程
|
||||
|
||||
1. 顾客扫码进入小程序。
|
||||
2. 系统进入堂食扫码确认页。
|
||||
3. 页面展示门店、桌台或扫码结果信息。
|
||||
4. 顾客确认进入堂食点餐。
|
||||
5. 系统切换当前场景为 `堂食`。
|
||||
6. 顾客进入点餐页浏览商品并完成加购。
|
||||
7. 顾客进入购物车抽屉和结算确认页。
|
||||
8. 结算页展示堂食桌台信息和堂食场景说明。
|
||||
9. 顾客完成支付。
|
||||
10. 支付成功页和订单详情页展示当前订单结果。
|
||||
11. 顾客需要继续加菜时，再次回到点餐页。
|
||||
|
||||
### 核心判断点
|
||||
- 桌号是否有效
|
||||
- 当前桌是否可继续点单
|
||||
- 当前场景是否需要合单或追加订单展示
|
||||
|
||||
## 4. F04 售后与评价流程
|
||||
- 扫码结果是否有效。
|
||||
- 当前门店是否支持堂食。
|
||||
- 堂食上下文是否能从确认页稳定带到点餐页和结算页。
|
||||
|
||||
### 当前冻结边界
|
||||
|
||||
- 当前优先冻结的是“扫码确认 + 桌台上下文 + 进入堂食点餐”。
|
||||
- 是否需要合单、追加单、更多桌台状态，不在当前最小冻结范围内。
|
||||
|
||||
---
|
||||
|
||||
## 4. F04 订单查看与结果承接流程
|
||||
|
||||
### 流程目标
|
||||
让用户在订单完成后可以评价，在履约异常时可以申请退款。
|
||||
|
||||
### 流程步骤 A：退款
|
||||
1. 用户进入订单详情页
|
||||
2. 点击申请退款
|
||||
3. 进入退款申请页
|
||||
4. 填写退款原因与说明
|
||||
5. 提交退款申请
|
||||
6. 跳转退款详情页查看处理状态
|
||||
让顾客在支付后能快速找到订单、理解当前状态，并进入下一步操作。
|
||||
|
||||
### 流程步骤 B：评价
|
||||
1. 用户进入订单详情页
|
||||
2. 点击去评价
|
||||
3. 进入评价页
|
||||
4. 选择星级、输入评价、上传图片、选择匿名
|
||||
5. 提交评价
|
||||
6. 评价成功后返回订单详情或订单列表
|
||||
### 主流程
|
||||
|
||||
## 5. F05 会员与资产流程
|
||||
1. 顾客支付完成后进入支付成功页。
|
||||
2. 页面展示订单摘要和当前场景关键信息。
|
||||
3. 顾客可选择：
|
||||
- 查看订单详情
|
||||
- 进入订单页
|
||||
- 继续点餐
|
||||
4. 顾客进入订单页查看自己的订单列表。
|
||||
5. 顾客按顾客视角状态筛选订单。
|
||||
6. 顾客进入订单详情页查看订单状态、商品清单、费用明细和下一步动作。
|
||||
|
||||
### 核心判断点
|
||||
|
||||
- 支付成功页是否具备稳定回流路径。
|
||||
- 订单页状态表达是否是顾客语言。
|
||||
- 订单详情页是否能解释“订单当前走到哪一步”。
|
||||
|
||||
### 当前冻结边界
|
||||
|
||||
- 订单页不直接照搬商家后台看板列。
|
||||
- 商家动作不属于顾客端页面。
|
||||
- `催单 / 骑手轨迹 / 取餐码` 当前都不作为固定必做按钮写死。
|
||||
|
||||
---
|
||||
|
||||
## 5. F05 售后与评价流程
|
||||
|
||||
### 流程目标
|
||||
让用户在“我的”中查看和使用所有可用资产，并引导复购。
|
||||
|
||||
### 流程步骤
|
||||
1. 用户进入我的页
|
||||
2. 查看会员等级、优惠券、积分、储值、次卡摘要
|
||||
3. 按需进入二级页面
|
||||
- 领券中心
|
||||
- 会员中心
|
||||
- 积分商城
|
||||
- 储值充值
|
||||
让顾客在订单完成或异常时，能够进行最小售后申请和评价反馈。
|
||||
|
||||
### 子流程 A：退款
|
||||
|
||||
1. 顾客进入订单详情页。
|
||||
2. 在符合条件时点击申请退款。
|
||||
3. 进入退款申请页。
|
||||
4. 选择退款原因并补充说明。
|
||||
5. 提交退款申请。
|
||||
6. 进入退款详情页查看当前状态和结果。
|
||||
|
||||
### 子流程 B：评价
|
||||
|
||||
1. 顾客进入订单详情页。
|
||||
2. 在符合条件时点击去评价。
|
||||
3. 进入评价页。
|
||||
4. 顾客选择星级并填写评价内容。
|
||||
5. 提交评价。
|
||||
6. 页面回流到订单详情页或订单页。
|
||||
|
||||
### 核心判断点
|
||||
|
||||
- 退款入口是否只在合适状态下出现。
|
||||
- 退款结果页是否能讲清当前处理结果。
|
||||
- 评价流程是否保持最小闭环，不过早叠加复杂玩法。
|
||||
|
||||
---
|
||||
|
||||
## 6. F06 我的、资产与复购流程
|
||||
|
||||
### 流程目标
|
||||
|
||||
让顾客在“我的”页看到自己的身份、资产、订单入口和服务入口，并回流到交易链路。
|
||||
|
||||
### 主流程
|
||||
|
||||
1. 顾客进入我的页。
|
||||
2. 页面展示用户头部信息。
|
||||
3. 页面展示资产摘要和订单快捷入口。
|
||||
4. 顾客按需进入以下二级页面：
|
||||
- 会员中心页
|
||||
- 积分商城页
|
||||
- 储值充值页
|
||||
- 次卡页
|
||||
4. 用户领取、充值、兑换或购买资产
|
||||
5. 返回点餐页或结算页使用资产
|
||||
5. 顾客完成查看、充值、兑换或购买后回流到点餐页或结算页。
|
||||
|
||||
### 核心判断点
|
||||
|
||||
- 我的页是否保持“聚合页”定位。
|
||||
- 资产页是否能回流到交易链路，而不只是静态展示。
|
||||
- 是否把不稳定数量字段过早写成强依赖。
|
||||
|
||||
### 当前冻结边界
|
||||
|
||||
- 我的页不是资产真源页。
|
||||
- 优惠券数、未读消息数、次卡实例数等当前不先冻结为强依赖字段。
|
||||
|
||||
---
|
||||
|
||||
## 7. F07 活动导购流程
|
||||
|
||||
### 流程目标
|
||||
|
||||
让顾客通过活动页进入标准交易链路，而不是停留在孤立活动页面。
|
||||
|
||||
### 主流程
|
||||
|
||||
1. 顾客在首页、点餐页或我的页看到活动入口。
|
||||
2. 顾客进入以下活动导购页之一：
|
||||
- 领券中心页
|
||||
- 秒杀活动页
|
||||
- 限时折扣活动页
|
||||
3. 顾客查看活动规则和活动商品。
|
||||
4. 顾客进入商品详情抽屉或点餐页加购。
|
||||
5. 顾客进入购物车、结算和支付流程。
|
||||
|
||||
### 核心判断点
|
||||
|
||||
- 活动是否真正导流到点餐和结算。
|
||||
- 活动页是否绕开了标准交易主链路。
|
||||
|
||||
### 当前冻结边界
|
||||
|
||||
- 当前值得独立页面承接的活动只冻结为 `领券中心 / 秒杀 / 限时折扣`。
|
||||
- 满减和新客优惠当前主要在结果区表达，不先扩成重页面。
|
||||
|
||||
@@ -2,71 +2,90 @@
|
||||
|
||||
## 1. 页面总表
|
||||
|
||||
| 编码 | 页面名称 | 层级 | 优先级 | 场景 | 规格文件 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| `T01` | 首页 | Tab | P0 | 全场景 | `docs/07-页面规格/01-Tab-首页.md` |
|
||||
| `T02` | 点餐页 | Tab | P0 | 外卖 / 自提 / 堂食 | `docs/07-页面规格/02-Tab-点餐页.md` |
|
||||
| `T03` | 订单页 | Tab | P0 | 全场景 | `docs/07-页面规格/03-Tab-订单页.md` |
|
||||
| `T04` | 我的页 | Tab | P0 | 全场景 | `docs/07-页面规格/04-Tab-我的页.md` |
|
||||
| `P01` | 门店选择页 | 二级页 | P1 | 全场景 | `docs/07-页面规格/05-门店选择页.md` |
|
||||
| `P02` | 地址管理页 | 二级页 | P1 | 外卖 | `docs/07-页面规格/06-地址管理页.md` |
|
||||
| `C01` | 商品详情抽屉 | 抽屉 | P0 | 点餐 | `docs/07-页面规格/07-商品详情抽屉.md` |
|
||||
| `C02` | 购物车抽屉 | 抽屉 | P0 | 点餐 | `docs/07-页面规格/08-购物车抽屉.md` |
|
||||
| `P03` | 结算确认页 | 二级页 | P0 | 外卖 / 自提 / 堂食 | `docs/07-页面规格/09-结算确认页.md` |
|
||||
| `P04` | 支付成功页 | 二级页 | P0 | 全场景 | `docs/07-页面规格/10-支付成功页.md` |
|
||||
| `P05` | 订单详情页 | 二级页 | P0 | 全场景 | `docs/07-页面规格/11-订单详情页.md` |
|
||||
| `P06` | 退款申请页 | 二级页 | P1 | 订单售后 | `docs/07-页面规格/12-退款申请页.md` |
|
||||
| `P07` | 退款详情页 | 二级页 | P1 | 订单售后 | `docs/07-页面规格/13-退款详情页.md` |
|
||||
| `P08` | 评价页 | 二级页 | P1 | 已完成订单 | `docs/07-页面规格/14-评价页.md` |
|
||||
| `P09` | 领券中心页 | 二级页 | P1 | 会员营销 | `docs/07-页面规格/15-领券中心页.md` |
|
||||
| `P10` | 秒杀活动页 | 二级页 | P1 | 营销活动 | `docs/07-页面规格/16-秒杀活动页.md` |
|
||||
| `P11` | 限时折扣活动页 | 二级页 | P1 | 营销活动 | `docs/07-页面规格/17-限时折扣活动页.md` |
|
||||
| `P12` | 会员中心页 | 二级页 | P1 | 会员 | `docs/07-页面规格/18-会员中心页.md` |
|
||||
| `P13` | 积分商城页 | 二级页 | P1 | 积分 | `docs/07-页面规格/19-积分商城页.md` |
|
||||
| `P14` | 储值充值页 | 二级页 | P1 | 储值 | `docs/07-页面规格/20-储值充值页.md` |
|
||||
| `P15` | 次卡页 | 二级页 | P1 | 次卡 | `docs/07-页面规格/21-次卡页.md` |
|
||||
| `P16` | 消息中心页 | 二级页 | P1 | 全场景 | `docs/07-页面规格/22-消息中心页.md` |
|
||||
| `P17` | 帮助中心页 | 二级页 | P2 | 全场景 | `docs/07-页面规格/23-帮助中心页.md` |
|
||||
| `P18` | 堂食扫码确认页 | 二级页 | P0 | 堂食 | `docs/07-页面规格/24-堂食扫码确认页.md` |
|
||||
| 编码 | 页面名称 | 层级 | 优先级 | 主要场景 | 当前定位 | 规格文件 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| `T01` | 首页 | Tab | P0 | 全场景 | 当前门店摘要、动态活动导流、推荐 | `docs/07-页面规格/01-Tab-首页.md` |
|
||||
| `T02` | 点餐页 | Tab | P0 | 外卖 / 自提 / 堂食 | 商品浏览、活动价表达、加购入口 | `docs/07-页面规格/02-Tab-点餐页.md` |
|
||||
| `T03` | 订单页 | Tab | P0 | 全场景 | 顾客视角订单列表、履约、售后 | `docs/07-页面规格/03-Tab-订单页.md` |
|
||||
| `T04` | 我的页 | Tab | P0 | 全场景 | 身份、资产、服务、复购聚合页 | `docs/07-页面规格/04-Tab-我的页.md` |
|
||||
| `P01` | 门店选择页 | 二级页 | P1 | 全场景 | 切店与当前场景可服务性判断 | `docs/07-页面规格/05-门店选择页.md` |
|
||||
| `P02` | 地址管理页 | 二级页 | P1 | 外卖 | 地址管理与配送可用性前置 | `docs/07-页面规格/06-地址管理页.md` |
|
||||
| `C01` | 商品详情抽屉 | 抽屉 | P0 | 点餐 | 规格、加料、套餐选择 | `docs/07-页面规格/07-商品详情抽屉.md` |
|
||||
| `C02` | 购物车抽屉 | 抽屉 | P0 | 点餐 | 已选商品确认与结算入口 | `docs/07-页面规格/08-购物车抽屉.md` |
|
||||
| `P03` | 结算确认页 | 二级页 | P0 | 外卖 / 自提 / 堂食 | 结算确认、手动资产选择、支付前确认 | `docs/07-页面规格/09-结算确认页.md` |
|
||||
| `P04` | 支付成功页 | 二级页 | P0 | 全场景 | 支付结果页与后续导流 | `docs/07-页面规格/10-支付成功页.md` |
|
||||
| `P05` | 订单详情页 | 二级页 | P0 | 全场景 | 状态解释、履约信息、订单结果 | `docs/07-页面规格/11-订单详情页.md` |
|
||||
| `P06` | 退款申请页 | 二级页 | P1 | 订单售后 | 最小售后申请页 | `docs/07-页面规格/12-退款申请页.md` |
|
||||
| `P07` | 退款详情页 | 二级页 | P1 | 订单售后 | 退款结果查看页 | `docs/07-页面规格/13-退款详情页.md` |
|
||||
| `P08` | 评价页 | 二级页 | P1 | 已完成订单 | 最小评价提交页 | `docs/07-页面规格/14-评价页.md` |
|
||||
| `P09` | 领券中心页 | 二级页 | P1 | 活动导购 | 可见券模板聚合与导流 | `docs/07-页面规格/15-领券中心页.md` |
|
||||
| `P10` | 秒杀活动页 | 二级页 | P1 | 活动导购 | 强时效秒杀会场 | `docs/07-页面规格/16-秒杀活动页.md` |
|
||||
| `P11` | 限时折扣活动页 | 二级页 | P1 | 活动导购 | 限时折扣商品会场 | `docs/07-页面规格/17-限时折扣活动页.md` |
|
||||
| `P12` | 会员中心页 | 二级页 | P1 | 会员 | 当前等级、权益、等级说明 | `docs/07-页面规格/18-会员中心页.md` |
|
||||
| `P13` | 积分商城页 | 二级页 | P1 | 积分 | 积分余额、可兑换内容、兑换记录 | `docs/07-页面规格/19-积分商城页.md` |
|
||||
| `P14` | 储值充值页 | 二级页 | P1 | 储值 | 余额、充值方案、充值记录 | `docs/07-页面规格/20-储值充值页.md` |
|
||||
| `P15` | 次卡页 | 二级页 | P1 | 次卡 | 模板说明与使用结果记录 | `docs/07-页面规格/21-次卡页.md` |
|
||||
| `P16` | 消息中心页 | 二级页 | P2 | 服务 | 页面职责预留，未冻结完整 inbox | `docs/07-页面规格/22-消息中心页.md` |
|
||||
| `P17` | 帮助中心页 | 二级页 | P2 | 服务 | 服务兜底页 | `docs/07-页面规格/23-帮助中心页.md` |
|
||||
| `P18` | 堂食扫码确认页 | 二级页 | P0 | 堂食 | 扫码上下文确认与入桌前置页 | `docs/07-页面规格/24-堂食扫码确认页.md` |
|
||||
|
||||
## 2. 组件级清单
|
||||
|
||||
| 编码 | 名称 | 优先级 | 规格文件 |
|
||||
| --- | --- | --- | --- |
|
||||
| `C01` | 商品详情抽屉 | P0 | `docs/07-页面规格/07-商品详情抽屉.md` |
|
||||
| `C02` | 购物车抽屉 | P0 | `docs/07-页面规格/08-购物车抽屉.md` |
|
||||
| 编码 | 名称 | 优先级 | 当前定位 | 规格文件 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `C01` | 商品详情抽屉 | P0 | 规格、加料、套餐选择 | `docs/07-页面规格/07-商品详情抽屉.md` |
|
||||
| `C02` | 购物车抽屉 | P0 | 已选商品确认与结算入口 | `docs/07-页面规格/08-购物车抽屉.md` |
|
||||
|
||||
## 3. 推荐实现顺序
|
||||
|
||||
### 第一阶段：交易闭环
|
||||
### 第一阶段：交易主链路
|
||||
|
||||
- `T01` 首页
|
||||
- `P01` 门店选择页
|
||||
- `P02` 地址管理页
|
||||
- `P18` 堂食扫码确认页
|
||||
- `T02` 点餐页
|
||||
- `C01` 商品详情抽屉
|
||||
- `C02` 购物车抽屉
|
||||
- `P03` 结算确认页
|
||||
- `P04` 支付成功页
|
||||
- `T03` 订单页
|
||||
- `P05` 订单详情页
|
||||
|
||||
### 第二阶段：履约与售后
|
||||
|
||||
- `T03` 订单页
|
||||
- `P05` 订单详情页
|
||||
- `P06` 退款申请页
|
||||
- `P07` 退款详情页
|
||||
- `P08` 评价页
|
||||
|
||||
### 第三阶段：资产与增长
|
||||
### 第三阶段：我的与资产
|
||||
|
||||
- `T04` 我的页
|
||||
- `P09` 领券中心页
|
||||
- `P10` 秒杀活动页
|
||||
- `P11` 限时折扣活动页
|
||||
- `P12` 会员中心页
|
||||
- `P13` 积分商城页
|
||||
- `P14` 储值充值页
|
||||
- `P15` 次卡页
|
||||
|
||||
### 第四阶段：辅助页
|
||||
- `P01` 门店选择页
|
||||
- `P02` 地址管理页
|
||||
### 第四阶段：活动导购
|
||||
|
||||
- `P09` 领券中心页
|
||||
- `P10` 秒杀活动页
|
||||
- `P11` 限时折扣活动页
|
||||
|
||||
### 第五阶段：服务与预留页
|
||||
|
||||
- `P16` 消息中心页
|
||||
- `P17` 帮助中心页
|
||||
- `P18` 堂食扫码确认页
|
||||
|
||||
## 4. 当前使用规则
|
||||
|
||||
- 本表用于做页面层级、优先级和实现分组总览
|
||||
- 单页职责、字段、状态和边界以 `docs/07-页面规格/` 为准
|
||||
- 如本表与 `docs/12-租户管理员功能重构梳理/` 冲突，以 `docs/12` 已完成批次结论为准
|
||||
- 当前必须记住的几条边界：
|
||||
- `T04` 是聚合页，不是资产真源
|
||||
- `P09` 是券模板导购页，不是“我的优惠券”页
|
||||
- `P10` 和 `P11` 都是导购会场，不能绕开正常商品与结算主链路
|
||||
- `P16` 当前只保留页面职责，不冻结完整消息 inbox
|
||||
- `P17` 当前是服务兜底页，不冻结 FAQ / 客服后台动态能力
|
||||
|
||||
|
||||
@@ -1,69 +1,158 @@
|
||||
# 通用组件清单
|
||||
|
||||
## 1. 说明
|
||||
- 文档目标：整理跨页面可复用的 UI 组件和业务组件，避免每个页面重复定义结构，也避免把未来能力过早做成当前刚性组件。
|
||||
- 使用方式：页面规格优先定义“页面职责”，本文件定义“可复用部件”；如果两者冲突，以页面职责和全局业务规则为准。
|
||||
|
||||
以下组件建议在实现时先抽象出来，避免每个页面重复拼装。
|
||||
页面规格文档会引用这些通用组件。
|
||||
---
|
||||
|
||||
## 2. 全局组件
|
||||
## 1. 使用原则
|
||||
|
||||
| 编码 | 组件名称 | 用途 | 必备状态 |
|
||||
| --- | --- | --- | --- |
|
||||
| `G01` | 顶部导航栏 | 二级页面返回、标题展示 | 默认态 |
|
||||
| `G02` | 底部 TabBar | Tab 页面切换 | 选中 / 未选中 |
|
||||
| `G03` | 页面空态卡片 | 列表为空时提示 | 图标 / 文案 / CTA |
|
||||
| `G04` | 页面错误卡片 | 网络错误、加载失败时提示 | 错误文案 / 重试 |
|
||||
| `G05` | 状态标签 Tag | 订单状态、活动状态、会员状态 | 多色标签 |
|
||||
### 1.1 先抽共性，不抽幻觉
|
||||
|
||||
- 只有跨页面稳定复用的结构，才进入通用组件清单。
|
||||
- 还没有冻结的能力，不做刚性组件。
|
||||
|
||||
### 1.2 先抽职责，不先抽字段
|
||||
|
||||
- 组件先定义“解决什么问题”。
|
||||
- 字段可以随接口阶段调整，不应反过来驱动组件设计。
|
||||
|
||||
### 1.3 先服务当前阶段，再预留未来阶段
|
||||
|
||||
- `V1.0` 交易主链路相关组件优先级最高。
|
||||
- `V1.1 / V2.0 / V2.1 / V3.0` 组件可以预留，但要明确阶段边界。
|
||||
|
||||
---
|
||||
|
||||
## 2. 全局基础组件
|
||||
|
||||
| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `G01` | 顶部导航栏 | 二级页返回、标题、右侧操作占位 | 全部二级页 | `V1.0+` |
|
||||
| `G02` | 底部 TabBar | 四个 Tab 页面切换 | `T01 / T02 / T03 / T04` | `V1.0+` |
|
||||
| `G03` | 页面空态卡片 | 列表无数据时统一提示和 CTA | 列表页、结果页 | `V1.0+` |
|
||||
| `G04` | 页面错误卡片 | 网络失败、数据异常、重试 | 全部业务页 | `V1.0+` |
|
||||
| `G05` | 状态标签 | 订单状态、活动状态、会员状态等语义标签 | 订单、活动、会员页 | `V1.0+` |
|
||||
| `G06` | 固定底部主操作栏 | 承载主 CTA，处理安全区和禁用态 | 结算页、订单详情页 | `V1.0+` |
|
||||
|
||||
---
|
||||
|
||||
## 3. 门店与场景组件
|
||||
|
||||
| 编码 | 组件名称 | 用途 | 使用页面 |
|
||||
| --- | --- | --- | --- |
|
||||
| `G10` | 门店切换条 | 显示当前门店，点击切换 | 首页、点餐页 |
|
||||
| `G11` | 场景切换条 | 外卖 / 自提 / 堂食切换 | 首页、点餐页 |
|
||||
| `G12` | 门店信息卡 | 地址、营业、距离、电话 | 首页、结算页、堂食确认页 |
|
||||
| `G13` | 服务规则条 | 起送价、配送费、自提规则等 | 首页、点餐页、结算页 |
|
||||
| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `G10` | 门店切换条 | 展示当前门店并进入切店流程 | 首页、点餐页 | `V1.0+` |
|
||||
| `G11` | 场景切换条 | 在门店支持范围内切换外卖 / 自提 / 堂食 | 首页、点餐页 | `V1.0+` |
|
||||
| `G12` | 门店信息卡 | 展示门店地址、营业状态、电话、基础服务信息 | 首页、结算页、堂食确认页 | `V1.0+` |
|
||||
| `G13` | 服务规则条 | 展示起送价、配送费、自提说明、堂食提示等简要规则 | 首页、点餐页、结算页 | `V1.0+` |
|
||||
| `G14` | 场景结果卡 | 展示当前场景的前置信息，如地址、自提门店、桌台 | 地址页、堂食确认页、结算页 | `V1.0+` |
|
||||
|
||||
---
|
||||
|
||||
## 4. 商品与购物车组件
|
||||
|
||||
| 编码 | 组件名称 | 用途 | 使用页面 |
|
||||
| --- | --- | --- | --- |
|
||||
| `G20` | 分类侧边栏 / 顶部分类条 | 分类浏览商品 | 点餐页 |
|
||||
| `G21` | 商品卡片 | 展示图片、价格、标签、加购按钮 | 点餐页、活动页 |
|
||||
| `G22` | 数量步进器 | 商品数量增减 | 点餐页、商品详情、购物车 |
|
||||
| `G23` | 规格选项组 | 规格做法单选/多选 | 商品详情抽屉 |
|
||||
| `G24` | 加料选项组 | 附加项选择 | 商品详情抽屉 |
|
||||
| `G25` | 底部购物车栏 | 已选数量、金额、去结算按钮 | 点餐页 |
|
||||
| `G26` | 购物车商品行 | 展示已选商品和规格组合 | 购物车抽屉 |
|
||||
| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `G20` | 类目导航 | 承接分类切换、当前类目高亮、吸顶表达 | 点餐页 | `V1.0+` |
|
||||
| `G21` | 商品卡片 | 展示商品图、标签、价格、活动摘要、加购入口 | 点餐页、活动页 | `V1.0+` |
|
||||
| `G22` | 数量步进器 | 商品数量加减和禁用态表达 | 点餐页、抽屉、购物车 | `V1.0+` |
|
||||
| `G23` | 商品详情头部 | 展示商品图、标题、描述、销量、价格、售罄态 | 商品详情抽屉 | `V1.0+` |
|
||||
| `G24` | 规格选项组 | 承接规格、做法、套餐组等选择 | 商品详情抽屉 | `V1.0+` |
|
||||
| `G25` | 加料选项组 | 承接附加项和加价项选择 | 商品详情抽屉 | `V1.0+` |
|
||||
| `G26` | 底部购物车栏 | 展示已选件数、金额和去结算入口 | 点餐页 | `V1.0+` |
|
||||
| `G27` | 购物车商品行 | 展示已选商品、规格摘要、数量编辑、删除动作 | 购物车抽屉 | `V1.0+` |
|
||||
| `G28` | 凑单 / 优惠提示条 | 展示凑单距离、优惠提示、配送门槛说明 | 购物车抽屉、结算页 | `V1.0+` |
|
||||
|
||||
---
|
||||
|
||||
## 5. 结算与订单组件
|
||||
|
||||
| 编码 | 组件名称 | 用途 | 使用页面 |
|
||||
| --- | --- | --- | --- |
|
||||
| `G30` | 地址卡片 | 展示收货地址或取餐信息 | 结算页 |
|
||||
| `G31` | 费用明细卡 | 展示金额构成 | 结算页、订单详情页 |
|
||||
| `G32` | 优惠资产单元格 | 展示优惠券 / 积分 / 余额入口 | 结算页 |
|
||||
| `G33` | 订单摘要卡 | 展示门店、商品、金额、状态 | 订单页 |
|
||||
| `G34` | 订单时间轴 | 展示履约节点 | 订单详情页、退款详情页 |
|
||||
| `G35` | 固定底部操作栏 | 继续支付、催单、退款、评价等 CTA | 结算页、订单详情页 |
|
||||
| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `G30` | 履约信息卡 | 根据场景展示配送地址、自提门店或堂食桌台信息 | 结算页、订单详情页 | `V1.0+` |
|
||||
| `G31` | 手动资产选择单元格 | 展示并进入手动资产选择入口 | 结算页 | `V1.0+` |
|
||||
| `G32` | 自动优惠命中列表 | 展示自动命中的优惠结果和说明 | 结算页 | `V1.0+` |
|
||||
| `G33` | 费用明细卡 | 展示商品金额、配送费、优惠、应付金额 | 结算页、订单详情页 | `V1.0+` |
|
||||
| `G34` | 订单摘要卡 | 展示订单门店、状态、金额、时间和主动作 | 订单页、支付成功页 | `V1.0+` |
|
||||
| `G35` | 履约时间轴 | 展示顾客可理解的订单阶段和进展 | 订单详情页、退款详情页 | `V1.1+` |
|
||||
| `G36` | 退款原因选择区 | 退款原因和补充说明输入 | 退款申请页 | `V1.1+` |
|
||||
| `G37` | 评价输入区 | 星级、文本输入和最小评价反馈区 | 评价页 | `V1.1+` |
|
||||
|
||||
## 6. 资产与服务组件
|
||||
---
|
||||
|
||||
| 编码 | 组件名称 | 用途 | 使用页面 |
|
||||
| --- | --- | --- | --- |
|
||||
| `G40` | 用户头部卡 | 头像、昵称、会员等级 | 我的页、会员中心 |
|
||||
| `G41` | 资产总览卡 | 券、积分、余额、次卡摘要 | 我的页 |
|
||||
| `G42` | 资产列表项 | 进入券、积分、储值、次卡详情 | 我的页 |
|
||||
| `G43` | 活动券卡片 | 满减券、折扣券、免配送费券 | 领券中心 |
|
||||
| `G44` | 充值方案卡 | 展示充值金额、赠送金额、到账金额 | 储值充值页 |
|
||||
| `G45` | 次卡卡片 | 展示次卡名称、剩余次数、有效期 | 次卡页 |
|
||||
| `G46` | 消息列表项 | 展示消息标题、摘要、时间、未读状态 | 消息中心 |
|
||||
## 6. 我的、资产与增长组件
|
||||
|
||||
## 7. 通用实现要求
|
||||
| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `G40` | 用户头部卡 | 展示头像、昵称、会员信息摘要 | 我的页、会员中心页 | `V1.0+` |
|
||||
| `G41` | 资产摘要卡 | 展示会员、积分、余额、次卡等摘要信息 | 我的页 | `V2.0+` |
|
||||
| `G42` | 订单快捷入口组 | 展示待支付、进行中、已完成等快捷入口 | 我的页 | `V1.0+` |
|
||||
| `G43` | 资产入口列表 | 承接会员、积分、储值、次卡等二级页入口 | 我的页 | `V2.0+` |
|
||||
| `G44` | 活动券卡片 | 展示券模板名称、门槛、有效期和领取 CTA | 领券中心页 | `V2.1+` |
|
||||
| `G45` | 活动商品卡 | 展示秒杀或限时折扣商品及活动状态 | 秒杀页、限时折扣页 | `V2.1+` |
|
||||
| `G46` | 充值方案卡 | 展示充值金额、赠送说明和到账结果 | 储值充值页 | `V2.0+` |
|
||||
| `G47` | 次卡卡片 | 展示次卡名称、权益摘要、剩余次数和有效期 | 次卡页 | `V2.0+` |
|
||||
| `G48` | 服务入口组 | 展示帮助、消息、客服等服务入口 | 我的页、帮助中心页 | `V3.0+` |
|
||||
|
||||
- 所有卡片组件需要支持禁用态或不可点击态
|
||||
- 列表项需要支持右侧箭头、辅助文案、角标等变化
|
||||
- 底部固定操作栏需要考虑安全区
|
||||
- 金额展示组件统一格式化
|
||||
- 状态标签颜色语义在整个应用中保持一致
|
||||
---
|
||||
|
||||
## 7. 服务与预留组件
|
||||
|
||||
| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `G50` | 消息列表项 | 展示消息标题、摘要、时间和已读状态 | 消息中心页 | `V3.0+` |
|
||||
| `G51` | 帮助问题列表项 | 展示问题标题、分类和跳转入口 | 帮助中心页 | `V3.0+` |
|
||||
| `G52` | 服务兜底卡 | 展示客服电话、在线客服、售后指引等信息 | 帮助中心页、我的页 | `V3.0+` |
|
||||
|
||||
---
|
||||
|
||||
## 8. 当前必须守住的组件边界
|
||||
|
||||
### 8.1 场景切换条
|
||||
|
||||
- `G11` 必须跟随门店 `serviceTypes` 控制可用场景。
|
||||
- 不能做固定三按钮硬编码。
|
||||
|
||||
### 8.2 商品卡和商品详情抽屉
|
||||
|
||||
- `G21` 必须区分简单商品和复杂商品。
|
||||
- 简单商品可直接加购。
|
||||
- 复杂商品必须进入 `G23 / G24 / G25` 组合后的商品详情抽屉流程。
|
||||
|
||||
### 8.3 结算资产组件
|
||||
|
||||
- `G31` 当前只冻结：
|
||||
- 优惠券
|
||||
- 余额
|
||||
- 次卡
|
||||
- `积分抵扣` 当前不进入该组件的已冻结范围。
|
||||
|
||||
### 8.4 自动优惠组件
|
||||
|
||||
- `G32` 当前只展示自动命中结果。
|
||||
- 当前冻结范围包括：
|
||||
- 满减
|
||||
- 新客优惠
|
||||
- 会员折扣
|
||||
- 免配送费
|
||||
|
||||
### 8.5 订单操作组件
|
||||
|
||||
- `G06` 不应把商家动作直接变成顾客动作。
|
||||
- `催单 / 骑手轨迹 / 取餐码` 当前都不作为固定组件按钮写死。
|
||||
|
||||
### 8.6 消息与帮助组件
|
||||
|
||||
- `G50` 当前只是未来职责预留，不代表已经冻结完整消息 inbox。
|
||||
- `G51 / G52` 当前用于服务兜底，不默认假设 FAQ CMS 或客服系统已经成熟存在。
|
||||
|
||||
---
|
||||
|
||||
## 9. 通用实现要求
|
||||
|
||||
- 所有可点击组件都要有禁用态或不可点击态。
|
||||
- 所有异步主按钮都要有 `loading` 反馈。
|
||||
- 金额显示格式在全应用保持一致。
|
||||
- 状态标签颜色语义在全应用保持一致。
|
||||
- 固定底部组件需要处理小程序安全区。
|
||||
- 组件文案优先使用顾客语言，不使用商家后台字段名。
|
||||
|
||||
@@ -2,100 +2,244 @@
|
||||
|
||||
- 页面编码：`T01`
|
||||
- 页面层级：`Tab`
|
||||
- 适用场景：`外卖 / 自提 / 堂食导流`
|
||||
- 页面目标：完成选店、选场景、看活动、快速进入点餐
|
||||
- 主要依赖组件：`G02`、`G10`、`G11`、`G12`、`G13`、`G21`
|
||||
- 适用场景：`全场景导流页`，当前可切换场景由当前门店 `serviceTypes` 决定
|
||||
- 页面目标：完成“选对门店 + 进入正确场景 + 感知当前有效活动 + 用最短路径进入点餐或活动会场”
|
||||
- 主要依赖组件：`G02`、`G10`、`G11`、`G12`、`G13`、`G21`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`、`02-菜单浏览与加购链路.md`、`05-我的资产消息复购链路.md`、`06-活动导购与增长链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部信息区
|
||||
2. 门店切换条
|
||||
3. 场景切换条
|
||||
4. Banner 活动区
|
||||
5. 快捷入口区
|
||||
6. 推荐商品区
|
||||
7. 门店服务信息区
|
||||
1. 顶部上下文区
|
||||
2. 当前门店卡
|
||||
3. 动态场景切换条
|
||||
4. 当前场景服务摘要条
|
||||
5. 动态活动 Banner 区
|
||||
6. 精选活动入口区
|
||||
7. 推荐商品摘要区
|
||||
8. 门店服务轻信息区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 顶部信息区
|
||||
- 左侧显示当前位置 / 当前门店简称
|
||||
- 右侧显示消息入口
|
||||
- 点击门店或位置进入 `P01 门店选择页`
|
||||
- 点击消息入口进入 `P16 消息中心页`
|
||||
### 2.1 顶部上下文区
|
||||
|
||||
### 2.2 门店切换条
|
||||
- 使用 `G10`
|
||||
- 显示当前门店名称、营业状态、距离
|
||||
- 支持点击切换门店
|
||||
- 左侧显示当前上下文摘要，不再简单写成“当前位置 / 门店简称”
|
||||
- 文案跟随当前场景变化：
|
||||
- `delivery`：当前配送地址或“请选择配送地址”
|
||||
- `pickup`：当前门店名称 / 商圈摘要
|
||||
- `dine_in`：当前门店名称与“支持堂食”提示
|
||||
- `delivery` 场景点击左侧摘要，优先进入 `P02 地址管理页`
|
||||
- `pickup / dine_in` 场景点击左侧摘要，优先进入 `P01 门店选择页`
|
||||
- 右侧动作位不再强制写死为“消息入口”
|
||||
- 如产品仍需保留右侧服务入口，可承接：
|
||||
- `P16 消息中心页`
|
||||
- 其他服务页入口
|
||||
- 当前不冻结：
|
||||
- 首页消息未读红点
|
||||
- 首页消息数量角标
|
||||
|
||||
### 2.2 当前门店卡
|
||||
|
||||
- 使用 `G10` + `G12`
|
||||
- 展示当前门店的核心事实：
|
||||
- 门店名称
|
||||
- 当前营业状态
|
||||
- 地址摘要 / 距离摘要
|
||||
- 联系电话或联系门店入口
|
||||
- 点击门店卡主体进入 `P01 门店选择页`
|
||||
- 门店卡不需要一次性展开配送、自提、堂食三整套规则
|
||||
- 门店卡内只保留当前场景强相关摘要：
|
||||
- `delivery`：当前地址是否可配送、预计送达、起送价
|
||||
- `pickup`：当前是否可自提、最近可约时段
|
||||
- `dine_in`：当前是否开启堂食、是否支持扫码入桌
|
||||
- 门店卡应提供一个主导流动作：
|
||||
- `delivery / pickup`：进入 `T02 点餐页`
|
||||
- `dine_in`：优先提示“扫码入桌后点餐”，不强行虚构手动入桌链路
|
||||
|
||||
### 2.3 动态场景切换条
|
||||
|
||||
### 2.3 场景切换条
|
||||
- 使用 `G11`
|
||||
- 固定提供 `外卖`、`自提`、`堂食` 三项
|
||||
- 切换后刷新下方活动和推荐内容
|
||||
- 不再固定提供 `外卖 / 自提 / 堂食` 三项
|
||||
- 场景项必须由当前门店真实 `serviceTypes` 动态生成
|
||||
- 默认策略：
|
||||
- 支持的场景正常展示并可切换
|
||||
- 不支持的场景默认不展示
|
||||
- 如果产品需要保留固定槽位，也只能用禁用态展示，并明确原因
|
||||
- 切换场景后必须同步刷新：
|
||||
- 顶部上下文摘要
|
||||
- 门店卡中的服务摘要
|
||||
- 活动内容
|
||||
- 推荐商品
|
||||
|
||||
### 2.4 Banner 活动区
|
||||
- 展示门店主推活动轮播
|
||||
- Banner 点击可跳转：
|
||||
- `P09 领券中心页`
|
||||
### 2.4 当前场景服务摘要条
|
||||
|
||||
- 使用 `G13`
|
||||
- 这一条只展示“当前场景的一层摘要”，不承担完整规则页职责
|
||||
- `delivery` 场景至少展示：
|
||||
- 是否可配送
|
||||
- 预计送达
|
||||
- 起送价
|
||||
- 配送费
|
||||
- `pickup` 场景至少展示：
|
||||
- 当前营业状态
|
||||
- 最近可约时段
|
||||
- 是否支持当日自提
|
||||
- `dine_in` 场景至少展示：
|
||||
- 是否开启堂食
|
||||
- 堂食点餐提示
|
||||
- 扫码入桌提示
|
||||
- 不在首页平铺以下后台细节：
|
||||
- `polygonGeoJson`
|
||||
- `hourlyCapacityLimit`
|
||||
- `platformServiceRate`
|
||||
- 员工排班
|
||||
|
||||
### 2.5 动态活动 Banner 区
|
||||
|
||||
- Banner 区展示的是“当前门店 + 当前场景 + 当前资格 + 当前生效状态”下的精选活动
|
||||
- Banner 不固定写死活动类别，内容由当前有效活动动态生成
|
||||
- 首页优先承接的活动类型只有：
|
||||
- `P10 秒杀活动页`
|
||||
- `P11 限时折扣活动页`
|
||||
- `P12 会员中心页`
|
||||
- `P09 领券中心页`
|
||||
- 当前资格成立的新客活动
|
||||
- Banner 点击跳转规则：
|
||||
- 秒杀：进入 `P10`
|
||||
- 限时折扣：进入 `P11`
|
||||
- 领券：进入 `P09`
|
||||
- 新客活动：进入 `T02 点餐页` 对应落点或活动说明落点，不单独虚构一页“新客会场”
|
||||
- Banner 区没有有效活动时可整体隐藏
|
||||
|
||||
### 2.5 快捷入口区
|
||||
- 建议 2 行网格或 1 行宫格
|
||||
- 包含以下入口：
|
||||
- 新客有礼
|
||||
### 2.6 精选活动入口区
|
||||
|
||||
- 这一块从“固定八宫格”改为“动态精选入口”
|
||||
- 默认只展示少量高价值入口，建议控制在 `2-4` 个
|
||||
- 入口内容只从当前有效活动里选，不再把所有服务入口混到首页同一层
|
||||
- 可展示的入口类型：
|
||||
- 领券中心
|
||||
- 满减活动
|
||||
- 秒杀专区
|
||||
- 限时折扣
|
||||
- 资格成立时的新客入口
|
||||
- 当前不应占首页核心活动位的内容：
|
||||
- 储值充值
|
||||
- 次卡专区
|
||||
- 会员中心
|
||||
- 帮助中心
|
||||
- 满减活动可以作为摘要感知存在，但不单独做首页固定入口
|
||||
|
||||
### 2.6 推荐商品区
|
||||
- 按顺序展示：
|
||||
- 热销推荐
|
||||
- 套餐推荐
|
||||
- 复购推荐
|
||||
- 猜你喜欢
|
||||
- 每个区块使用横滑或纵向卡片列表
|
||||
- 商品卡点击进入 `C01 商品详情抽屉`
|
||||
### 2.7 推荐商品摘要区
|
||||
|
||||
### 2.7 门店服务信息区
|
||||
- 使用 `G12` + `G13`
|
||||
- 展示：
|
||||
- 营业时间
|
||||
- 配送范围 / 起送价 / 配送费
|
||||
- 自提规则
|
||||
- 堂食规则
|
||||
- 这一块只做轻量商品导流，不复刻点餐页分类与筛选能力
|
||||
- 推荐分组不再固定写死为“热销 / 套餐 / 复购 / 猜你喜欢”四段
|
||||
- 推荐内容可以来自：
|
||||
- 热销商品
|
||||
- 当前活动商品
|
||||
- 常点商品 / 复购推荐
|
||||
- 门店主推商品
|
||||
- 页面实现时建议最多保留少量分组，避免首页过长
|
||||
- 商品卡 `G21` 至少展示：
|
||||
- 商品图
|
||||
- 商品名
|
||||
- 当前售价
|
||||
- 划线价（如有）
|
||||
- 商品标签
|
||||
- 当前活动标识（如有）
|
||||
- 商品卡点击规则：
|
||||
- 默认进入 `C01 商品详情抽屉` 或跳转 `T02` 对应商品位置
|
||||
- 如果商品为“无规格、无加料、非套餐”的简单商品，可选做快速加购
|
||||
- 快速加购不是首页必备结构
|
||||
- 首页商品卡不承载：
|
||||
- 分类切换
|
||||
- 复杂选配
|
||||
- 大段优惠解释
|
||||
|
||||
### 2.8 门店服务轻信息区
|
||||
|
||||
- 这一块只保留轻信息，不再做一个长篇“门店服务信息区”
|
||||
- 可展示内容：
|
||||
- 今日营业时间摘要
|
||||
- 联系门店
|
||||
- 到店导航
|
||||
- 当前场景相关补充说明
|
||||
- 展示原则：
|
||||
- 只展示当前场景直接相关内容
|
||||
- 不把配送、自提、堂食三套规则一次性全部平铺
|
||||
- 如果后续需要承接更完整的门店规则，优先做抽屉或详情承接；本页不先写重
|
||||
|
||||
## 3. 页面主动作
|
||||
|
||||
- 切换门店
|
||||
- 切换场景
|
||||
- 进入点餐页
|
||||
- 进入活动页
|
||||
- 打开商品详情
|
||||
- 切换门店，进入 `P01 门店选择页`
|
||||
- 在 `delivery` 场景切换或补充配送地址，进入 `P02 地址管理页`
|
||||
- 切换当前下单场景
|
||||
- 进入 `T02 点餐页`
|
||||
- 进入 `P09 领券中心页`
|
||||
- 进入 `P10 秒杀活动页`
|
||||
- 进入 `P11 限时折扣活动页`
|
||||
- 打开 `C01 商品详情抽屉` 或跳转点餐页对应商品
|
||||
- 联系门店或打开导航
|
||||
|
||||
## 4. 页面状态
|
||||
|
||||
### 默认态
|
||||
- 有门店、有活动、有推荐商品
|
||||
|
||||
### 空态
|
||||
- 无可用门店时展示空态，并提供重新定位
|
||||
- 无活动时隐藏活动区，保留推荐区
|
||||
- 已确定门店
|
||||
- 当前场景可用
|
||||
- 有活动或有推荐商品
|
||||
- 可以顺畅进入点餐链路
|
||||
|
||||
### 异常态
|
||||
- 定位失败时提示手动选店
|
||||
- 门店休息时展示“休息中”，但可保留浏览
|
||||
### 无门店态
|
||||
|
||||
- 无可用门店时展示 `G03`
|
||||
- 明确告知当前无法进入点餐
|
||||
- 提供重新定位或手动选店动作
|
||||
|
||||
### 无地址 / 不可配送态
|
||||
|
||||
- 仅在 `delivery` 场景下出现
|
||||
- 当未选择地址时：
|
||||
- 顶部摘要提示选择地址
|
||||
- 不默认假设“当前门店可配送”
|
||||
- 当地址不可配送时：
|
||||
- 明确展示“超出配送范围 / 不在配送区域 / 当前不支持配送”
|
||||
- 允许切换地址或切换门店
|
||||
|
||||
### 场景不可用态
|
||||
|
||||
- 当前门店不支持某场景时，不应继续展示可点选主动作
|
||||
- 如使用禁用态展示场景项，需要给出禁用原因
|
||||
|
||||
### 门店休息态
|
||||
|
||||
- 允许浏览门店和活动摘要
|
||||
- 主动作需要降级：
|
||||
- 可提示“休息中”
|
||||
- 如允许预订，则按对应场景展示最近可用时间
|
||||
|
||||
### 无活动态
|
||||
|
||||
- 隐藏 Banner 区和精选活动入口区
|
||||
- 页面仍保留门店摘要与推荐商品摘要
|
||||
|
||||
### 无推荐商品态
|
||||
|
||||
- 推荐商品区可隐藏
|
||||
- 不影响门店切换、场景切换和活动导流
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重新加载当前门店、场景与活动数据
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- 首页优先是“导流页”，不是深度浏览页
|
||||
- 推荐商品只展示摘要，不在首页直接承载复杂选配
|
||||
- 首页首先是“上下文建立 + 导流页”，不是完整点餐页
|
||||
- 首页不能再做固定八宫格目录页
|
||||
- 首页不能把资产入口、服务入口、营销入口混成同一层级
|
||||
- 场景切换必须跟随门店真实 `serviceTypes`
|
||||
- 活动内容必须服从：
|
||||
- 当前门店
|
||||
- 当前场景
|
||||
- 当前活动状态
|
||||
- 当前用户资格
|
||||
- 首页不冻结消息未读数、券数量、次卡数量等聚合角标
|
||||
- `dine_in` 场景不在首页虚构“合单 / 加菜 / 先付款”等后台未证实规则
|
||||
|
||||
|
||||
@@ -2,93 +2,294 @@
|
||||
|
||||
- 页面编码：`T02`
|
||||
- 页面层级：`Tab`
|
||||
- 适用场景：`外卖 / 自提 / 堂食`
|
||||
- 页面目标：完成商品浏览、选配、加购和进入结算
|
||||
- 主要依赖组件：`G10`、`G11`、`G20`、`G21`、`G22`、`G25`
|
||||
- 适用场景：`delivery / pickup / dine_in`，当前可切换场景由当前门店 `serviceTypes` 决定
|
||||
- 页面目标：在“当前门店 + 当前场景”的交易上下文内完成商品浏览、搜索、选配分流、加购、查看购物车并进入结算
|
||||
- 主要依赖组件：`G10`、`G11`、`G13`、`G20`、`G21`、`G22`、`G25`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`、`02-菜单浏览与加购链路.md`、`03-结算与支付链路.md`、`06-活动导购与增长链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部门店条
|
||||
2. 场景切换条
|
||||
3. 搜索与活动提示条
|
||||
4. 菜单主区域
|
||||
5. 底部购物车栏
|
||||
1. 顶部交易上下文区
|
||||
2. 动态场景切换条
|
||||
3. 搜索区
|
||||
4. 轻量活动摘要条
|
||||
5. 菜单主区域
|
||||
6. 底部购物车栏
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 顶部门店条
|
||||
- 显示当前门店名称、营业状态
|
||||
- 点击进入 `P01 门店选择页`
|
||||
- 门店切换需要提示购物车风险
|
||||
### 2.1 顶部交易上下文区
|
||||
|
||||
### 2.2 场景切换条
|
||||
- 显示 `外卖 / 自提 / 堂食`
|
||||
- 切换时刷新：
|
||||
- 这一块不是纯标题区，而是当前交易上下文的事实入口
|
||||
- 使用 `G10`，并补充当前场景关键信息
|
||||
- 至少展示：
|
||||
- 当前门店名称
|
||||
- 当前营业状态
|
||||
- 当前场景
|
||||
- 当前场景下的关键上下文
|
||||
- 场景差异：
|
||||
- `delivery`：当前配送地址、是否可送、预计送达或配送摘要
|
||||
- `pickup`：当前门店、是否支持自提、营业摘要
|
||||
- `dine_in`：当前门店、桌号
|
||||
- 点击行为：
|
||||
- 点击门店主体进入 `P01 门店选择页`
|
||||
- `delivery` 场景点击地址摘要进入 `P02 地址管理页`
|
||||
- `dine_in` 场景如桌号缺失或上下文失效，应引导重新扫码或返回 `P18`
|
||||
- 切换门店属于高风险动作，需要提示：
|
||||
- 当前购物车属于单门店 + 单场景
|
||||
- 切店可能清空购物车
|
||||
|
||||
### 2.2 动态场景切换条
|
||||
|
||||
- 使用 `G11`
|
||||
- 不再固定展示 `外卖 / 自提 / 堂食` 三项
|
||||
- 场景项必须按当前门店真实 `serviceTypes` 动态生成
|
||||
- 切换场景后必须同步刷新：
|
||||
- 顶部上下文
|
||||
- 分类导航
|
||||
- 商品列表
|
||||
- 商品可售状态
|
||||
- 服务规则说明
|
||||
- 价格与优惠提示
|
||||
- 活动摘要
|
||||
- 购物车可用性
|
||||
- 切换场景时同样属于高风险动作，需要处理跨场景购物车问题：
|
||||
- 若购物车为空，可直接切换
|
||||
- 若购物车非空，应提示清空风险
|
||||
- 不支持的场景不应继续以可点击主入口出现
|
||||
|
||||
### 2.3 搜索与活动提示条
|
||||
- 搜索框：按商品名搜索
|
||||
- 活动条：显示当前命中的满减、秒杀、折扣等活动摘要
|
||||
### 2.3 搜索区
|
||||
|
||||
### 2.4 菜单主区域
|
||||
- 左侧或顶部为分类导航 `G20`
|
||||
- 右侧或主体为商品列表
|
||||
- 每个商品卡 `G21` 展示：
|
||||
- 图片
|
||||
- 名称
|
||||
- 描述摘要
|
||||
- 标签
|
||||
- 价格 / 划线价
|
||||
- 加购按钮
|
||||
- 点击商品卡进入 `C01 商品详情抽屉`
|
||||
- 直接点击步进器可快速加购默认 SKU
|
||||
- 搜索只在“当前门店 + 当前场景 + 当前时段”内生效
|
||||
- 支持按商品名称、商品关键词做搜索
|
||||
- 搜索结果必须保持和主列表一致的可售口径
|
||||
- 搜索结果页或搜索态中仍需保留：
|
||||
- 商品标签
|
||||
- 当前价格
|
||||
- 当前可售状态
|
||||
- 快速加购 / 打开详情的分流逻辑
|
||||
- 搜索不应绕开分类和场景限制，不能搜出当前场景不可售商品再允许加购
|
||||
|
||||
### 2.4 轻量活动摘要条
|
||||
|
||||
- 这一块保留，但只做轻量摘要，不做营销主区
|
||||
- 只承接会影响当前购买决策的高价值活动结果：
|
||||
- 满减摘要
|
||||
- 新客命中摘要
|
||||
- 秒杀进行中
|
||||
- 限时折扣进行中
|
||||
- 表达形式建议是单行摘要或少量标签化提示
|
||||
- 允许点击进入对应活动页或定位活动商品，但不能把这里做成“活动公告栏堆栈”
|
||||
- 页面内活动口径必须同时服从：
|
||||
- 当前门店
|
||||
- 当前场景
|
||||
- 当前活动状态
|
||||
- 当前用户资格
|
||||
- 当前不在点餐页强写：
|
||||
- 顾客手动选择满减
|
||||
- 新客完整会场
|
||||
- 营销日历入口
|
||||
|
||||
### 2.5 菜单主区域
|
||||
|
||||
- 这一块是页面主区，优先级高于活动摘要
|
||||
- 结构由两部分组成：
|
||||
- 分类导航 `G20`
|
||||
- 商品列表区
|
||||
|
||||
#### 分类导航
|
||||
|
||||
- 分类不是全场景通用一套，必须受后台 `channels` 约束
|
||||
- 前台展示统一使用顾客语言：
|
||||
- `外卖`
|
||||
- `自提`
|
||||
- `堂食`
|
||||
- 当前场景下没有商品的分类不应误导性展示为正常可点主分类
|
||||
- 分类切换与滚动定位需要稳定，不被活动条插队打乱
|
||||
|
||||
#### 商品列表区
|
||||
|
||||
- 商品列表按当前门店、当前场景、当前时段展示可售商品
|
||||
- 商品卡 `G21` 至少展示：
|
||||
- 商品图
|
||||
- 商品名
|
||||
- 摘要描述
|
||||
- 商品标签
|
||||
- 当前售价
|
||||
- 划线价（如有）
|
||||
- 月售等弱经营信息
|
||||
- 商品可售状态
|
||||
- 加购入口
|
||||
- 商品卡必须支持区分三类购买形态：
|
||||
- 简单单品：无规格、无加料、非套餐
|
||||
- 复杂单品：有规格 / 做法 / 加料
|
||||
- 套餐商品：带套餐分组
|
||||
|
||||
#### 快速加购规则
|
||||
|
||||
- 只有“简单单品”允许直接使用 `G22` 快速加购
|
||||
- 复杂单品点击加购时，必须打开 `C01 商品详情抽屉`
|
||||
- 套餐商品点击加购时，必须打开 `C01` 并进入套餐分组选择
|
||||
- 不允许再写“默认 SKU 一键快速加购”作为通用规则
|
||||
|
||||
#### 商品详情打开规则
|
||||
|
||||
- 点击商品卡主体默认打开 `C01 商品详情抽屉`
|
||||
- 抽屉负责处理：
|
||||
- 规格做法
|
||||
- 加料组
|
||||
- 套餐分组
|
||||
- SKU 价格与库存联动
|
||||
- 点餐页本体不直接承担复杂选配
|
||||
|
||||
#### 商品可售状态表达
|
||||
|
||||
- 不可售不能只写成“售罄”
|
||||
- 至少要翻译成顾客可理解的几类原因：
|
||||
- 已售罄
|
||||
- 已下架
|
||||
- 当前时段不可售
|
||||
- 当前场景不可售
|
||||
- 临时沽清
|
||||
- 不可售商品可以浏览，但不可直接加购
|
||||
|
||||
### 2.6 底部购物车栏
|
||||
|
||||
### 2.5 底部购物车栏
|
||||
- 使用 `G25`
|
||||
- 展示：
|
||||
- 始终是页面唯一明确的“去结算”主路径
|
||||
- 至少展示：
|
||||
- 已选商品件数
|
||||
- 当前总金额
|
||||
- 差多少起送 / 差多少免配送费
|
||||
- 去结算按钮
|
||||
- 主按钮“去结算”
|
||||
- 差额提示必须按场景收敛：
|
||||
- `delivery`：可展示差多少起送、差多少免配送费
|
||||
- `pickup`：不展示配送费和免配送费差额
|
||||
- `dine_in`：不展示配送相关差额
|
||||
- 点击购物车区域打开 `C02 购物车抽屉`
|
||||
- 点击“去结算”进入 `P03 结算确认页`
|
||||
- 未登录时，点击去结算应按全局规则先走 `C03 登录授权弹层`
|
||||
|
||||
## 3. 场景差异规则
|
||||
|
||||
### 外卖场景
|
||||
- 突出显示配送费、起送价、预计送达
|
||||
### `delivery`
|
||||
|
||||
### 自提场景
|
||||
- 突出显示自提优惠、自提时段说明
|
||||
- 强调地址与配送可达性
|
||||
- 分类和商品必须按外卖渠道过滤
|
||||
- 页面可展示配送相关轻摘要：
|
||||
- 是否可送
|
||||
- 预计送达
|
||||
- 起送价 / 配送费提示
|
||||
- 购物车栏可显示起送差额与免配送费差额
|
||||
|
||||
### 堂食场景
|
||||
- 突出显示桌号、当前门店、可加菜提示
|
||||
### `pickup`
|
||||
|
||||
- 强调当前门店与自提可用性
|
||||
- 分类和商品必须按自提渠道过滤
|
||||
- 页面只做自提轻摘要，不提前让用户在点餐页选复杂取餐时间
|
||||
- 自提时间的正式确认放到 `P03 结算确认页`
|
||||
|
||||
### `dine_in`
|
||||
|
||||
- 强调门店与桌号上下文
|
||||
- 分类和商品必须按堂食渠道过滤
|
||||
- 页面不展示配送地址、配送费、免配送费相关模块
|
||||
- 页面不虚构以下规则：
|
||||
- 合单
|
||||
- 加菜
|
||||
- 先付款
|
||||
- 如桌号上下文丢失或失效，应优先提示重新扫码或重新确认桌位
|
||||
|
||||
## 4. 页面主动作
|
||||
|
||||
- 切换门店
|
||||
- 切换场景
|
||||
- 切换当前下单场景
|
||||
- 在 `delivery` 场景选择或变更配送地址
|
||||
- 搜索商品
|
||||
- 打开商品详情抽屉
|
||||
- 打开购物车抽屉
|
||||
- 进入结算确认页
|
||||
- 切换分类
|
||||
- 打开 `C01 商品详情抽屉`
|
||||
- 对简单单品直接加购
|
||||
- 打开 `C02 购物车抽屉`
|
||||
- 进入 `P03 结算确认页`
|
||||
|
||||
## 5. 页面状态
|
||||
|
||||
### 默认态
|
||||
- 有分类、有商品、有活动提示
|
||||
|
||||
### 空态
|
||||
- 某分类无商品时，右侧显示空态
|
||||
- 搜索无结果时，提供清空搜索入口
|
||||
- 已确定门店与当前场景
|
||||
- 有分类、有商品
|
||||
- 活动摘要可有可无
|
||||
- 购物车栏按当前选择实时变化
|
||||
|
||||
### 异常态
|
||||
- 当前门店休息：商品可浏览但不能结算
|
||||
- 商品售罄：显示禁用状态，不能加购
|
||||
### 分类空态
|
||||
|
||||
- 当前分类无商品时，商品区展示 `G03`
|
||||
- 提示切换分类或清空筛选 / 搜索
|
||||
|
||||
### 搜索无结果态
|
||||
|
||||
- 搜索结果为空时展示 `G03`
|
||||
- 提供清空关键词、返回分类浏览动作
|
||||
|
||||
### 当前场景无商品态
|
||||
|
||||
- 当前门店在该场景下没有可售商品时，不能继续伪装成正常菜单页
|
||||
- 需要明确提示：
|
||||
- 当前场景暂无可售商品
|
||||
- 可切换其他场景或切换门店
|
||||
|
||||
### 门店休息态
|
||||
|
||||
- 商品允许浏览
|
||||
- 不可直接把“可浏览”误写成“可正常下单”
|
||||
- 主结算路径需要降级或提示：
|
||||
- 当前休息中
|
||||
- 如支持预约，后续在结算页继续确认
|
||||
|
||||
### 地址缺失 / 不可配送态
|
||||
|
||||
- 仅 `delivery` 场景出现
|
||||
- 当地址缺失时：
|
||||
- 顶部上下文明确提示选择地址
|
||||
- 不默认放行正常配送预期
|
||||
- 当地址不可配送时：
|
||||
- 要明确说明原因
|
||||
- 允许切换地址或切换门店
|
||||
|
||||
### 堂食上下文失效态
|
||||
|
||||
- 仅 `dine_in` 场景出现
|
||||
- 当桌号不存在、失效或不可用时：
|
||||
- 提示重新扫码
|
||||
- 禁止继续按正常堂食上下文下单
|
||||
|
||||
### 商品失效态
|
||||
|
||||
- 商品状态变化后要能即时反馈：
|
||||
- 已下架
|
||||
- 已售罄
|
||||
- 当前时段不可售
|
||||
- 当前场景不可售
|
||||
- 失效商品不能继续加购
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重新加载：
|
||||
- 分类数据
|
||||
- 商品数据
|
||||
- 当前场景状态
|
||||
- 活动摘要
|
||||
|
||||
## 6. 实现备注
|
||||
|
||||
- 点餐页是整套小程序最核心页面，需要优先保证信息密度和操作效率
|
||||
- 商品详情、购物车应通过抽屉承载，尽量不跳转新页面
|
||||
- 点餐页是整套小程序的核心交易页，但主区必须始终让位给“商品浏览与加购”
|
||||
- 分类展示必须受当前场景渠道约束，不能做全场景通用菜单
|
||||
- 只有简单单品允许快速加购；复杂单品和套餐统一走 `C01`
|
||||
- 活动摘要条只做轻导流和轻提示，不前移结算和优惠解释
|
||||
- 购物车抽屉优先解决商品确认、失效清理和去结算，不做复杂优惠主战场
|
||||
- 点餐页不承接：
|
||||
- 优惠券选择
|
||||
- 储值选择
|
||||
- 次卡核销
|
||||
- 积分抵扣
|
||||
- 复杂支付方式选择
|
||||
- `dine_in` 场景不在本页承诺后台未证实的堂食规则
|
||||
|
||||
|
||||
@@ -3,62 +3,153 @@
|
||||
- 页面编码：`T03`
|
||||
- 页面层级：`Tab`
|
||||
- 适用场景：`全场景`
|
||||
- 页面目标：让用户快速找到订单，并查看履约、售后和复购入口
|
||||
- 主要依赖组件：`G05`、`G33`
|
||||
- 页面目标：让顾客快速找到自己的订单，先看懂“现在进行到哪一步”，再执行当前状态下最有价值的动作
|
||||
- 主要依赖组件：`G05`、`G33`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部状态筛选区
|
||||
2. 场景筛选区（可选）
|
||||
1. 顶部主筛选区
|
||||
2. 场景二级筛选区
|
||||
3. 订单列表区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 顶部状态筛选区
|
||||
- 建议分段控件或横向标签
|
||||
- 至少包含：
|
||||
### 2.1 顶部主筛选区
|
||||
|
||||
- 这一块必须使用顾客任务语言，不复用商家看板分栏
|
||||
- 顶部主筛选固定为：
|
||||
- 全部
|
||||
- 待支付
|
||||
- 进行中
|
||||
- 已完成
|
||||
- 退款售后
|
||||
- 售后
|
||||
- 这些页签用于帮助顾客快速判断“我现在最可能要处理哪一类单”
|
||||
- 后台更细的状态如：
|
||||
- 待接单
|
||||
- 制作中
|
||||
- 配送中
|
||||
- 待取餐
|
||||
- 不直接上翻成顶层页签，而是下沉到卡片状态文案和详情页表达
|
||||
|
||||
### 2.2 场景筛选区
|
||||
- 可按 `外卖 / 自提 / 堂食` 进行二次筛选
|
||||
- 也可与状态整合为一个过滤区
|
||||
### 2.2 场景二级筛选区
|
||||
|
||||
- 场景筛选 `外卖 / 自提 / 堂食` 可以保留，但只能作为二级筛选
|
||||
- 这一块不能取代顶部主筛选成为主信息架构
|
||||
- 场景筛选的作用是帮助顾客在同一状态下继续缩小范围，例如：
|
||||
- 查看进行中的外卖单
|
||||
- 查看已完成的堂食单
|
||||
- 当前不在订单页继续叠加后台管理筛选，如：
|
||||
- 支付方式
|
||||
- 日期区间
|
||||
- 关键词搜索
|
||||
|
||||
### 2.3 订单列表区
|
||||
|
||||
- 每张订单卡使用 `G33`
|
||||
- 订单卡必须展示：
|
||||
- 订单卡的目标是让顾客一眼看懂：
|
||||
- 哪家门店
|
||||
- 什么状态
|
||||
- 什么场景
|
||||
- 买了什么
|
||||
- 金额多少
|
||||
- 下一步该做什么
|
||||
- 订单卡至少展示：
|
||||
- 门店名称
|
||||
- 订单状态
|
||||
- 当前状态文案
|
||||
- 场景标签
|
||||
- 商品摘要
|
||||
- 订单金额
|
||||
- 下单时间
|
||||
- 主要操作按钮
|
||||
- 订单卡点击进入 `P05 订单详情页`
|
||||
- 可按状态补充一条轻辅助说明，例如：
|
||||
- 商家处理中
|
||||
- 制作中
|
||||
- 配送中
|
||||
- 待到店取餐
|
||||
- 点击订单卡主体进入 `P05 订单详情页`
|
||||
|
||||
## 3. 订单卡动作规则
|
||||
|
||||
- `待支付`：继续支付、取消订单
|
||||
- `进行中`：查看详情、催单、查看取餐码
|
||||
- `已完成`：评价、再来一单
|
||||
- `退款售后`：查看退款详情
|
||||
### `待支付`
|
||||
|
||||
## 4. 页面状态
|
||||
- 主动作：
|
||||
- 继续支付
|
||||
- 取消订单
|
||||
- 这是和第 3 批结算支付链路直接衔接的状态
|
||||
|
||||
### `进行中`
|
||||
|
||||
- 主动作收敛为：
|
||||
- 查看详情
|
||||
- 不把以下能力冻结为所有进行中订单的固定按钮：
|
||||
- 催单
|
||||
- 查看取餐码
|
||||
- 骑手轨迹
|
||||
|
||||
### `已完成`
|
||||
|
||||
- 主动作：
|
||||
- 去评价
|
||||
- 再来一单
|
||||
|
||||
### `售后`
|
||||
|
||||
- 主动作：
|
||||
- 查看退款详情
|
||||
|
||||
### 其他结果态
|
||||
|
||||
- 如为已取消等只读结果态：
|
||||
- 以查看详情为主
|
||||
- 不堆叠无意义动作
|
||||
|
||||
## 4. 状态翻译原则
|
||||
|
||||
- 后台订单状态不能原样以商家术语抛给顾客
|
||||
- 订单页顶层统一使用顾客视角页签：
|
||||
- 全部
|
||||
- 待支付
|
||||
- 进行中
|
||||
- 已完成
|
||||
- 售后
|
||||
- 更细的后台状态只用于驱动卡片文案，例如：
|
||||
- 待接单 / 商家处理中
|
||||
- 制作中
|
||||
- 配送中
|
||||
- 待取餐
|
||||
|
||||
## 5. 页面状态
|
||||
|
||||
### 默认态
|
||||
|
||||
- 有订单列表
|
||||
- 顾客可以快速扫读状态、门店、金额与下一步动作
|
||||
|
||||
### 空态
|
||||
- 某筛选条件下无订单时，展示空态和“去点餐” CTA
|
||||
|
||||
### 异常态
|
||||
- 加载失败时展示重试
|
||||
- 某个筛选条件下无订单时，展示 `G03`
|
||||
- 提供“去点餐” CTA
|
||||
- 空态文案应跟当前筛选条件相关，例如：
|
||||
- 暂无待支付订单
|
||||
- 暂无进行中订单
|
||||
- 暂无售后订单
|
||||
|
||||
## 5. 实现备注
|
||||
### 未登录态
|
||||
|
||||
- 订单页重点是列表可扫读性
|
||||
- 一屏内要能快速看懂状态、门店、金额和下一步动作
|
||||
- 订单页属于顾客本人数据页
|
||||
- 未登录时不直接展示空订单列表
|
||||
- 应先走登录授权，再进入本人订单查询
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示残缺列表
|
||||
|
||||
## 6. 实现备注
|
||||
|
||||
- `T03` 的重点是列表可扫读性，不是后台查单控制台
|
||||
- 不要复用商家订单看板四列布局
|
||||
- 不要把 `支付方式 / 日期区间 / 关键词` 这类后台管理筛选搬到顾客端
|
||||
- 不要把 `催单 / 取餐码 / 再来一单` 做成所有订单都存在的固定按钮
|
||||
- 列表页负责“找单和看懂状态”，完整履约、售后和基础信息下沉到 `P05`
|
||||
|
||||
|
||||
@@ -3,76 +3,134 @@
|
||||
- 页面编码：`T04`
|
||||
- 页面层级：`Tab`
|
||||
- 适用场景：`全场景`
|
||||
- 页面目标：集中展示用户身份、资产、服务和复购入口
|
||||
- 主要依赖组件：`G40`、`G41`、`G42`
|
||||
- 页面目标：作为顾客身份、资产、订单、服务和复购的聚合页，帮助顾客快速进入高频任务，而不是承接完整资产明细
|
||||
- 主要依赖组件：`G40`、`G41`、`G42`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 用户头部卡
|
||||
2. 资产总览区
|
||||
1. 身份头部卡
|
||||
2. 资产摘要区
|
||||
3. 订单快捷入口区
|
||||
4. 会员与增长入口区
|
||||
5. 服务入口区
|
||||
6. 复购推荐区
|
||||
4. 核心入口区
|
||||
5. 复购区
|
||||
6. 底部辅助入口区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 用户头部卡
|
||||
- 使用 `G40`
|
||||
- 展示：
|
||||
- 头像
|
||||
- 昵称
|
||||
- 会员等级
|
||||
- 成长值进度摘要
|
||||
### 2.1 身份头部卡
|
||||
|
||||
- 使用 `G40`
|
||||
- 这一块只承接最稳的顾客身份信息，不扩展成会员规则详情页
|
||||
- 至少展示：
|
||||
- 头像
|
||||
- 展示名
|
||||
- 当前会员等级
|
||||
- 入会信息
|
||||
- 可提供进入 `18-会员中心页.md` 的入口
|
||||
- 当前不把成长值进度、距离下一等级差值写成强必做能力
|
||||
|
||||
### 2.2 资产摘要区
|
||||
|
||||
### 2.2 资产总览区
|
||||
- 使用 `G41`
|
||||
- 展示：
|
||||
- 优惠券数量
|
||||
- 积分余额
|
||||
- 这一块只做轻摘要，不做资产真源
|
||||
- 优先展示当前已证实、顾客可直接感知的资产：
|
||||
- 积分
|
||||
- 储值余额
|
||||
- 次卡数量 / 剩余次数摘要
|
||||
- 会员权益入口
|
||||
- 如后续顾客资产聚合接口补齐，可继续补充更多摘要项
|
||||
- 当前不把以下内容冻结为首页必须显示的精确数字：
|
||||
- 优惠券数量
|
||||
- 次卡数量
|
||||
- 次卡剩余次数总览
|
||||
|
||||
### 2.3 订单快捷入口区
|
||||
- 展示：
|
||||
|
||||
- 这一块用于帮助顾客从“我的”快速回到订单任务
|
||||
- 快捷入口直接继承 `T03 订单页` 的顾客视角状态分组：
|
||||
- 待支付
|
||||
- 进行中
|
||||
- 已完成
|
||||
- 售后 / 退款
|
||||
- 点击后跳转 `T03 订单页` 对应筛选状态
|
||||
- 售后
|
||||
- 点击后跳转 `T03` 对应状态
|
||||
- 当前不把状态角标数量冻结为正式能力
|
||||
|
||||
### 2.4 核心入口区
|
||||
|
||||
### 2.4 会员与增长入口区
|
||||
- 使用 `G42`
|
||||
- 入口包含：
|
||||
- 这一块承接高价值资产入口和服务入口
|
||||
- 可包含：
|
||||
- 会员中心
|
||||
- 领券中心
|
||||
- 积分商城
|
||||
- 储值充值
|
||||
- 次卡页
|
||||
|
||||
### 2.5 服务入口区
|
||||
- 包含：
|
||||
- 地址管理
|
||||
- 消息中心
|
||||
- 帮助中心
|
||||
- 联系客服
|
||||
- 协议与隐私
|
||||
- `领券中心` 可以作为导流入口保留，但当前只定义入口，不在本页解释完整活动规则
|
||||
- `消息中心` 当前也只保留入口，不在本页预设未读数和消息摘要列表
|
||||
|
||||
### 2.6 复购推荐区
|
||||
- 展示最近订单和常点商品
|
||||
- 提供“再来一单”入口
|
||||
### 2.5 复购区
|
||||
|
||||
- 这一块承接轻量复购，不做复杂推荐系统首页
|
||||
- 可承接的内容包括：
|
||||
- 最近订单
|
||||
- 常点商品
|
||||
- 再来一单入口
|
||||
- 目标是帮助顾客快速重复购买，不解释复杂算法推荐逻辑
|
||||
- 当前以轻推荐为主，不冻结多层推荐策略
|
||||
|
||||
### 2.6 底部辅助入口区
|
||||
|
||||
- 这一块放低频但合理存在的辅助入口
|
||||
- 可保留：
|
||||
- 协议与隐私
|
||||
- 平台说明类入口
|
||||
- 当前不把客服系统能力写成后台已证实的正式前台契约
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
### 登录态
|
||||
- 展示完整资产与服务
|
||||
|
||||
- 展示完整身份摘要、资产摘要、订单快捷入口和复购入口
|
||||
- 页面目标是帮助顾客快速进入下一步，而不是在当前页消费全部明细
|
||||
|
||||
### 未登录态
|
||||
- 展示基础入口
|
||||
- 资产卡片改为“登录后查看”
|
||||
|
||||
## 4. 实现备注
|
||||
- 展示基础结构，但资产与订单相关内容应提示登录后查看
|
||||
- 主 CTA 应收敛为登录 / 授权
|
||||
- 不展示伪造的资产数字和订单数据
|
||||
|
||||
- “我的”页要兼顾资产页和服务页
|
||||
- 顶部头部卡与资产总览区需要在视觉上形成核心焦点
|
||||
### 空态
|
||||
|
||||
- 当复购区暂无最近订单或常点商品时，使用 `G03`
|
||||
- 可提供“去点餐”入口
|
||||
- 不因为某个区块无数据就让整个 `T04` 失效
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残资产信息
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 优惠券数量与我的券包详情
|
||||
- 我的次卡实例清单
|
||||
- 订单快捷入口角标数量
|
||||
- 未读消息数
|
||||
- 到下一等级的精确差值
|
||||
- 首页直接展开完整消息列表
|
||||
- 首页直接展开完整帮助内容
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源还不足以把它们写成 `T04` 的正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `T04` 的本质是聚合页，不是会员页、资产页、消息页或帮助页的替代品
|
||||
- 视觉重心应放在：
|
||||
- 身份识别
|
||||
- 高频资产摘要
|
||||
- 高频任务入口
|
||||
- 页面不应因为想“看起来丰富”就堆太多数字、说明和规则
|
||||
- 复购区先强调最近订单和再来一单，不先扩成复杂推荐系统
|
||||
|
||||
|
||||
@@ -2,51 +2,92 @@
|
||||
|
||||
- 页面编码：`P01`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：让用户选择合适门店，并明确当前场景是否可服务
|
||||
- 主要依赖组件：`G01`、`G12`
|
||||
- 页面目标：切换当前门店，并在当前场景下明确门店是否可下单、当前最关键的履约摘要是什么
|
||||
- 主要依赖组件：`G01`、`G12`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 搜索区
|
||||
3. 场景筛选区
|
||||
4. 当前定位结果区
|
||||
5. 门店列表区
|
||||
3. 当前定位 / 地址结果区
|
||||
4. 门店列表区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 搜索区
|
||||
- 支持按门店名称、商圈关键词搜索
|
||||
|
||||
### 2.2 场景筛选区
|
||||
- 按 `外卖 / 自提 / 堂食` 过滤门店
|
||||
- 支持按门店名称、商圈或地址关键词搜索
|
||||
- 搜索的目标是快速找到门店，不是做后台式多条件筛选
|
||||
|
||||
### 2.3 当前定位结果区
|
||||
- 显示当前定位城市 / 坐标结果
|
||||
- 提供重新定位动作
|
||||
### 2.2 当前定位 / 地址结果区
|
||||
|
||||
### 2.4 门店列表区
|
||||
- 每个门店卡展示：
|
||||
- 这一块用于告诉顾客当前判断门店可服务性的依据是什么
|
||||
- 外卖场景下，应优先展示：
|
||||
- 当前定位结果或当前收货地址
|
||||
- 重新定位 / 切换地址入口
|
||||
- 自提场景下，可弱化定位，强调当前门店范围和营业信息
|
||||
- 堂食场景下，手动选店只是兜底，不是主入口
|
||||
|
||||
### 2.3 门店列表区
|
||||
|
||||
- 每张门店卡必须先回答“当前场景下能不能下单”
|
||||
- 至少展示：
|
||||
- 门店名称
|
||||
- 距离
|
||||
- 营业状态
|
||||
- 地址
|
||||
- 场景支持标签
|
||||
- 起送价 / 配送费 / 自提 / 堂食提示
|
||||
- 点击门店即切换当前门店并返回来源页
|
||||
- 营业状态
|
||||
- 当前支持的服务方式
|
||||
- 当前场景下的关键履约摘要
|
||||
- 外卖场景下，门店卡至少要能表达：
|
||||
- 是否可配送
|
||||
- 预计送达
|
||||
- 配送费
|
||||
- 起送门槛
|
||||
- 自提场景下，门店卡至少要能表达：
|
||||
- 是否支持自提
|
||||
- 当前是否营业
|
||||
- 最早可预约时段
|
||||
- 堂食场景下，门店卡应强调：
|
||||
- 是否支持堂食
|
||||
- 手动选店只是扫码失败时的兜底
|
||||
- 点击门店后不应默认无条件直接返回
|
||||
- 如存在购物车、地址不兼容或场景不兼容，应先给出确认和结果提示
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
### 默认态
|
||||
- 有门店列表
|
||||
|
||||
- 有门店列表时，页面重点是帮助顾客判断“哪家店现在能服务我”
|
||||
|
||||
### 空态
|
||||
- 搜索无结果或当前区域无门店
|
||||
|
||||
### 异常态
|
||||
- 定位失败时只展示手动选店模式
|
||||
- 搜索无结果或当前范围无可用门店时，使用 `G03`
|
||||
- 可提供重新定位、切换地址或清空筛选入口
|
||||
|
||||
## 4. 实现备注
|
||||
### 定位失败态
|
||||
|
||||
- 门店列表要把“能否下单”说清楚，不仅展示名字
|
||||
- 如定位失败，应退回手动选店模式
|
||||
- 不因为定位失败就阻断整页使用
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残门店信息
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 直接向顾客暴露后台审核状态
|
||||
- 只凭门店名称和距离就默认可下单
|
||||
- 无条件点门店即切换并返回
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更明确支持“按当前场景判断是否可服务”，不支持把门店选择页简化成纯列表切换器。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P01` 的重点是“选门店前先把当前场景下能否服务讲清楚”
|
||||
- 页面至少要让顾客看清楚：
|
||||
- 当前依据什么在判断门店可用性
|
||||
- 当前门店能不能下单
|
||||
- 切店后会不会影响当前购物车和场景上下文
|
||||
- 堂食默认走扫码，不要把手动选店反写成堂食主入口
|
||||
|
||||
|
||||
@@ -2,46 +2,83 @@
|
||||
|
||||
- 页面编码：`P02`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：管理顾客常用收货地址，并服务外卖结算
|
||||
- 主要依赖组件：`G01`
|
||||
- 页面目标：管理顾客常用收货地址，并在外卖场景下前置说明当前地址对当前门店是否可配送
|
||||
- 主要依赖组件：`G01`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 地址列表区
|
||||
3. 新增地址按钮
|
||||
3. 新增地址入口区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 地址列表区
|
||||
- 每个地址项展示：
|
||||
|
||||
- 这一块不是普通通讯录，而是交易前置页
|
||||
- 每个地址项至少展示：
|
||||
- 收货人姓名
|
||||
- 手机号
|
||||
- 详细地址
|
||||
- 默认地址标签
|
||||
- 适用范围提示（可选）
|
||||
- 当前门店下的配送适用状态
|
||||
- 配送适用状态不是可选说明，而是核心字段
|
||||
- 至少应支持表达：
|
||||
- 可配送
|
||||
- 超出最大距离
|
||||
- 不在配送范围
|
||||
- 其他不满足当前门店服务条件的提示
|
||||
- 支持动作：
|
||||
- 设为默认
|
||||
- 编辑
|
||||
- 删除
|
||||
- 选择用于本次结算
|
||||
- 从结算进入时，应支持“选择地址后立即回传配送校验结果”
|
||||
|
||||
### 2.2 新增地址按钮
|
||||
- 固定在页面底部或列表底部
|
||||
- 点击后进入编辑态（可独立页或表单弹层）
|
||||
### 2.2 新增地址入口区
|
||||
|
||||
- 提供新增地址入口
|
||||
- 新增后应尽快回到“地址是否可配送”的判断结果上
|
||||
- 当前文档只冻结地址管理职责，不展开独立地址编辑页细节
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
### 默认态
|
||||
- 展示已有地址
|
||||
|
||||
- 展示已有地址，并明确每个地址对当前门店是否可用
|
||||
- 页面重心不是存地址，而是让顾客知道“这个地址现在能不能送”
|
||||
|
||||
### 空态
|
||||
- 无地址时展示空态和新增 CTA
|
||||
|
||||
### 异常态
|
||||
- 地址保存失败 / 删除失败时需要提示
|
||||
- 无地址时使用 `G03`
|
||||
- 提供新增地址 CTA
|
||||
- 不伪造默认地址和适配状态
|
||||
|
||||
## 4. 实现备注
|
||||
### 保存或删除失败态
|
||||
|
||||
- 如果另一位 AI 需要拆成“地址列表页 + 地址编辑页”，可以追加子页面，但当前文档以一个管理页为主
|
||||
- 明确提示失败原因
|
||||
- 不让列表停留在不确定状态
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残地址和配送状态
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 把适用范围提示当成可有可无的文案
|
||||
- 延迟到支付前才告诉顾客地址不可配送
|
||||
- 把地址页写成通用通讯录页
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源已经明确表明“地址是否可配送”是外卖交易前置条件，必须在地址页和结算页前置处理。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P02` 的重点是“地址管理 + 配送可用性前置”
|
||||
- 页面至少要让顾客看清楚：
|
||||
- 我有哪些地址
|
||||
- 哪个地址现在能送
|
||||
- 选中后是否可以直接用于本次订单
|
||||
- 如果后续拆成“列表页 + 编辑页”，也不能把配送状态判断从主列表里拿掉
|
||||
|
||||
|
||||
@@ -2,57 +2,209 @@
|
||||
|
||||
- 页面编码：`C01`
|
||||
- 页面层级：`组件级抽屉`
|
||||
- 页面目标：完成商品选配，并把用户送入购物车
|
||||
- 主要依赖组件：`G22`、`G23`、`G24`
|
||||
- 页面目标：在不离开当前点餐上下文的前提下，完成商品选配、校验价格与库存、加入购物车
|
||||
- 主要依赖组件：`G22`、`G23`、`G24`、`G05`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md` 回写
|
||||
|
||||
## 1. 抽屉结构（从上到下）
|
||||
|
||||
1. 商品图片区
|
||||
1. 商品媒体区
|
||||
2. 商品基础信息区
|
||||
3. 规格做法区
|
||||
4. 加料区
|
||||
5. 数量与金额区
|
||||
6. 底部主操作区
|
||||
3. 当前可售与活动提示区
|
||||
4. 套餐分组区（套餐商品时出现）
|
||||
5. 规格做法区
|
||||
6. 加料区
|
||||
7. 数量与金额区
|
||||
8. 底部主操作区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 商品图片区
|
||||
- 展示主图，允许左右切换附图（可选）
|
||||
### 2.1 商品媒体区
|
||||
|
||||
- 展示商品主图
|
||||
- 如商品存在多图，可支持轮播或横滑查看附图
|
||||
- 这一块只做商品感知补充，不扩展成长详情页
|
||||
- 抽屉头部应始终保留关闭动作
|
||||
|
||||
### 2.2 商品基础信息区
|
||||
- 展示：
|
||||
|
||||
- 至少展示：
|
||||
- 商品名称
|
||||
- 标签
|
||||
- 描述
|
||||
- 售价
|
||||
- 划线价
|
||||
- 月售 / 热销信息（可选）
|
||||
- 商品标签
|
||||
- 商品摘要描述
|
||||
- 当前售价
|
||||
- 划线价（如有）
|
||||
- 可选展示：
|
||||
- 月售等弱经营信息
|
||||
- 商品级包装费提示
|
||||
- 商品标签必须来自后台启用状态的标签配置，不手写运营词
|
||||
- 商品基础信息区不展示后台内部字段：
|
||||
- `SPU`
|
||||
- 同步平台状态
|
||||
- 预警库存
|
||||
|
||||
### 2.3 当前可售与活动提示区
|
||||
|
||||
- 这一块用于解释当前商品在“当前门店 + 当前场景 + 当前时段”下的可购买状态
|
||||
- 可展示的状态提示包括：
|
||||
- 已售罄
|
||||
- 已下架
|
||||
- 当前时段不可售
|
||||
- 当前场景不可售
|
||||
- 临时沽清
|
||||
- 如商品当前带有活动价，可在这里或价格区做轻提示：
|
||||
- 秒杀价
|
||||
- 限时折扣价
|
||||
- 当前活动标签
|
||||
- 这一块不承接复杂优惠解释，满减、新客、会员折扣仍以页面级轻提示或结算页结果为主
|
||||
|
||||
### 2.4 套餐分组区
|
||||
|
||||
- 仅套餐商品出现
|
||||
- 套餐商品不能套用普通单品结构，必须单独承接套餐分组选择
|
||||
- 每个分组至少展示：
|
||||
- 分组名称
|
||||
- 必选 / 非必选
|
||||
- `minSelect`
|
||||
- `maxSelect`
|
||||
- 当前已选状态
|
||||
- 如分组选项本身还带规格或加料，后续选择仍需纳入统一价格计算
|
||||
- 分组未满足最少选择数时，底部主按钮不可用
|
||||
|
||||
### 2.5 规格做法区
|
||||
|
||||
### 2.3 规格做法区
|
||||
- 使用 `G23`
|
||||
- 支持单选 / 多组单选
|
||||
- 选择后实时刷新价格和库存
|
||||
- 规格做法区必须承接后台模板配置：
|
||||
- `spec`
|
||||
- `method`
|
||||
- `single / multi`
|
||||
- `isRequired`
|
||||
- 每组选项需要清楚展示：
|
||||
- 选项名称
|
||||
- 选项加价
|
||||
- 当前选中状态
|
||||
- 选择规格或做法后，必须实时刷新：
|
||||
- 当前价格
|
||||
- 当前 SKU 结果
|
||||
- 当前库存状态
|
||||
- 必选项未完成时，底部主按钮不可用
|
||||
|
||||
### 2.6 加料区
|
||||
|
||||
### 2.4 加料区
|
||||
- 使用 `G24`
|
||||
- 支持多选和附加价格
|
||||
- 加料区必须承接后台约束：
|
||||
- `required`
|
||||
- `minSelect`
|
||||
- `maxSelect`
|
||||
- 选项价格
|
||||
- 选项库存
|
||||
- 每个加料组选项至少展示：
|
||||
- 名称
|
||||
- 加价
|
||||
- 可选状态
|
||||
- 当加料项库存不足或不可选时，需要明确禁用，不允许形成非法组合
|
||||
- 必选加料未满足最少选择数时，底部主按钮不可用
|
||||
|
||||
### 2.7 数量与金额区
|
||||
|
||||
### 2.5 数量与金额区
|
||||
- 使用 `G22`
|
||||
- 实时展示当前组合总价
|
||||
- 实时展示当前合法组合下的金额结果
|
||||
- 至少包含：
|
||||
- 当前数量
|
||||
- 当前组合总价
|
||||
- 如果价格由以下因素变化，必须实时联动：
|
||||
- SKU
|
||||
- 规格做法
|
||||
- 加料
|
||||
- 套餐分组
|
||||
- 数量步进器需要受库存与当前可售状态约束
|
||||
- 不允许在非法组合未完成时，先放开数量增加再报错
|
||||
|
||||
### 2.6 底部主操作区
|
||||
- 主按钮：加入购物车
|
||||
- 次按钮：立即购买（可选）
|
||||
### 2.8 底部主操作区
|
||||
|
||||
## 3. 状态规则
|
||||
- 主按钮统一为：`加入购物车`
|
||||
- 不再保留 `立即购买` 分支
|
||||
- 主按钮文案与状态需要跟随当前选择结果变化：
|
||||
- 规格未选全
|
||||
- 加料未满足
|
||||
- 套餐分组未完成
|
||||
- 当前不可售
|
||||
- 库存不足
|
||||
- 加入购物车成功后：
|
||||
- 关闭抽屉
|
||||
- 返回原点餐上下文
|
||||
- 不应导致列表滚动位置丢失
|
||||
|
||||
- 规格未选全时，主按钮不可用
|
||||
- 商品售罄时，显示不可售状态
|
||||
- 库存不足时，数量步进器受限
|
||||
## 3. 商品形态差异
|
||||
|
||||
## 4. 实现备注
|
||||
### 简单单品
|
||||
|
||||
- 抽屉应保留当前点餐页上下文
|
||||
- 关闭抽屉不应导致列表位置丢失
|
||||
- 无规格、无加料、非套餐
|
||||
- 这类商品通常可以在点餐页直接快速加购
|
||||
- 但当用户主动点开商品卡时，仍可使用本抽屉查看信息并加购
|
||||
|
||||
### 复杂单品
|
||||
|
||||
- 有规格 / 做法 / 加料
|
||||
- 必须通过本抽屉完成合法组合后才能加入购物车
|
||||
|
||||
### 套餐商品
|
||||
|
||||
- 带套餐分组
|
||||
- 必须通过本抽屉完成套餐分组选择
|
||||
- 不能按普通单品默认 SKU 逻辑处理
|
||||
|
||||
## 4. 状态规则
|
||||
|
||||
### 默认态
|
||||
|
||||
- 商品可售
|
||||
- 当前价格和选项正常显示
|
||||
- 用户可继续选择规格、加料或套餐内容
|
||||
|
||||
### 必选未完成态
|
||||
|
||||
- 规格、做法、加料或套餐分组未选全时：
|
||||
- 主按钮不可用
|
||||
- 需要明确提示缺少的选择项
|
||||
|
||||
### 库存不足态
|
||||
|
||||
- 当前 SKU 或某加料项库存不足时：
|
||||
- 对应选项禁用或提示库存不足
|
||||
- 数量步进器受限
|
||||
- 不允许继续提交非法组合
|
||||
|
||||
### 当前不可售态
|
||||
|
||||
- 商品因以下原因不可售时：
|
||||
- 已售罄
|
||||
- 已下架
|
||||
- 当前时段不可售
|
||||
- 当前场景不可售
|
||||
- 临时沽清
|
||||
- 允许查看信息，但主按钮不可用
|
||||
|
||||
### 价格联动态
|
||||
|
||||
- 用户每次修改规格、加料、套餐分组或数量时：
|
||||
- 总价立即刷新
|
||||
- 不允许等到加入购物车后再结算
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 商品详情数据加载失败时，需要在抽屉内展示错误状态
|
||||
- 支持重试，不强行保留半残状态
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `C01` 是“选配抽屉”，不是完整商品详情页
|
||||
- 抽屉必须始终依附当前门店 + 当前场景上下文，不能跨上下文复用旧选择
|
||||
- 抽屉内不承接：
|
||||
- 优惠券选择
|
||||
- 储值选择
|
||||
- 次卡核销
|
||||
- 积分抵扣
|
||||
- 支付动作
|
||||
- 点餐页负责决定“是否需要打开 C01”，`C01` 负责把不合法商品组合挡在购物车之外
|
||||
|
||||
|
||||
@@ -2,50 +2,176 @@
|
||||
|
||||
- 页面编码：`C02`
|
||||
- 页面层级：`组件级抽屉`
|
||||
- 页面目标：集中展示当前已选商品，并提供进入结算的最后一步确认
|
||||
- 主要依赖组件：`G22`、`G26`
|
||||
- 页面目标：汇总当前门店 + 当前场景下已选商品，支持快速改量，暴露失效商品并清理，提供唯一的去结算主路径
|
||||
- 主要依赖组件：`G22`、`G26`、`G03`、`G04`、`G05`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`、`03-结算与支付链路.md` 回写
|
||||
|
||||
## 1. 抽屉结构（从上到下）
|
||||
|
||||
1. 购物车头部
|
||||
2. 商品列表区
|
||||
3. 优惠与凑单提示区
|
||||
4. 底部结算区
|
||||
2. 失效商品提示区（有失效项时出现）
|
||||
3. 商品列表区
|
||||
4. 轻量提示区
|
||||
5. 底部结算区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 购物车头部
|
||||
- 显示当前门店名
|
||||
- 显示“已选商品”标题
|
||||
- 提供清空购物车按钮
|
||||
|
||||
### 2.2 商品列表区
|
||||
- 至少展示：
|
||||
- 当前门店名称
|
||||
- 当前场景
|
||||
- “已选商品”标题
|
||||
- 右侧提供：
|
||||
- 关闭抽屉
|
||||
- 清空购物车按钮
|
||||
- 清空购物车属于高风险动作，需要二次确认或明显的防误触处理
|
||||
- 购物车头部不承接：
|
||||
- 优惠券选择
|
||||
- 支付方式选择
|
||||
- 会员权益详细说明
|
||||
|
||||
### 2.2 失效商品提示区
|
||||
|
||||
- 当购物车内存在失效商品时，必须显式展示这一块
|
||||
- 这是购物车抽屉的核心职责之一，优先级高于优惠提示
|
||||
- 至少需要告诉用户：
|
||||
- 有哪些商品已失效
|
||||
- 为什么失效
|
||||
- 当前是否还能去结算
|
||||
- 失效原因统一翻译成顾客可理解的口径：
|
||||
- 已下架
|
||||
- 已售罄
|
||||
- 当前时段不可售
|
||||
- 当前场景不可售
|
||||
- 建议提供：
|
||||
- 一键清理失效商品
|
||||
- 手动逐项删除
|
||||
- 在失效商品未处理前：
|
||||
- 默认不允许直接去结算
|
||||
- 或至少需要强提示先清理
|
||||
|
||||
### 2.3 商品列表区
|
||||
|
||||
- 每个商品行使用 `G26`
|
||||
- 展示：
|
||||
- 商品列表只展示当前门店 + 当前场景下的购物车项
|
||||
- 不允许出现跨门店、跨场景混装逻辑
|
||||
- 每个商品行至少展示：
|
||||
- 商品名
|
||||
- 规格摘要
|
||||
- 加料摘要
|
||||
- 套餐选择摘要
|
||||
- 单价
|
||||
- 数量步进器
|
||||
- 小计金额
|
||||
- 如果某项没有规格、加料或套餐摘要，可省略对应字段，但不能把已有组合信息丢掉
|
||||
- 数量步进器 `G22` 的职责：
|
||||
- 快速增减当前购物车项数量
|
||||
- 不改变已选规格、加料、套餐组合
|
||||
- 如用户需要修改商品组合，不应在购物车内直接重做复杂选配：
|
||||
- 优先删除后重新选
|
||||
- 或回到 `C01 商品详情抽屉` 重新选择
|
||||
|
||||
### 2.3 优惠与凑单提示区
|
||||
- 展示：
|
||||
- 满减差额
|
||||
- 起送差额
|
||||
- 免配送费差额
|
||||
- 已命中活动摘要
|
||||
### 2.4 轻量提示区
|
||||
|
||||
### 2.4 底部结算区
|
||||
- 展示总金额
|
||||
- 主按钮：去结算
|
||||
- 这一块只承接轻量提示，不做复杂优惠解释区
|
||||
- 可承接的内容：
|
||||
- `delivery` 场景下差多少起送
|
||||
- `delivery` 场景下差多少免配送费
|
||||
- 当前已命中的轻量活动摘要
|
||||
- 已命中的活动摘要只允许做结果提示，例如：
|
||||
- 已命中满减
|
||||
- 当前有新客优惠
|
||||
- 当前商品含秒杀 / 折扣商品
|
||||
- 这一块不承接：
|
||||
- 优惠券列表
|
||||
- 储值余额选择
|
||||
- 次卡核销选择
|
||||
- 积分抵扣
|
||||
- 复杂叠加规则说明
|
||||
- `pickup / dine_in` 场景下不展示配送费与免配送费差额提示
|
||||
|
||||
## 3. 状态规则
|
||||
### 2.5 底部结算区
|
||||
|
||||
- 空购物车时展示空态
|
||||
- 商品失效时需标记并禁止结算，或提示清理失效商品
|
||||
- 这一块必须始终保持“唯一去结算主路径”
|
||||
- 至少展示：
|
||||
- 已选商品总件数
|
||||
- 当前总金额
|
||||
- 主按钮“去结算”
|
||||
- 如当前是 `delivery` 场景且未达到起送门槛：
|
||||
- 明确展示还差多少起送
|
||||
- 主按钮不可用
|
||||
- 如存在失效商品未清理：
|
||||
- 主按钮不可用或先引导清理
|
||||
- 点击主按钮后进入 `P03 结算确认页`
|
||||
- 未登录时，结算动作应按全局规则先走 `C03 登录授权弹层`
|
||||
|
||||
## 4. 实现备注
|
||||
## 3. 场景差异规则
|
||||
|
||||
- 购物车抽屉必须支持快速修改数量
|
||||
- 去结算按钮应只保留一个主路径，不做复杂分支
|
||||
### `delivery`
|
||||
|
||||
- 可展示起送差额和免配送费差额
|
||||
- 需要跟当前地址与门店配送可用性保持一致
|
||||
- 如地址变更导致当前购物车商品不可正常结算，需要回到页面级状态处理
|
||||
|
||||
### `pickup`
|
||||
|
||||
- 不展示配送费、起送价、免配送费差额
|
||||
- 只保留商品确认、金额确认和去结算路径
|
||||
|
||||
### `dine_in`
|
||||
|
||||
- 不展示配送相关提示
|
||||
- 保持门店 + 桌号上下文一致
|
||||
- 不在购物车内虚构堂食规则：
|
||||
- 合单
|
||||
- 加菜
|
||||
- 先付款
|
||||
|
||||
## 4. 状态规则
|
||||
|
||||
### 默认态
|
||||
|
||||
- 存在有效商品
|
||||
- 商品行可以正常改量
|
||||
- 可以查看轻量提示并进入结算
|
||||
|
||||
### 空购物车态
|
||||
|
||||
- 空购物车时展示 `G03`
|
||||
- 提示返回点餐继续选择商品
|
||||
- 此时不显示去结算主按钮
|
||||
|
||||
### 失效商品态
|
||||
|
||||
- 购物车内存在失效商品时，必须高亮提示
|
||||
- 失效商品默认不能继续参与结算
|
||||
- 允许用户：
|
||||
- 单个删除
|
||||
- 一键清理失效项
|
||||
|
||||
### 未达起送态
|
||||
|
||||
- 仅 `delivery` 场景出现
|
||||
- 明确展示差额
|
||||
- 主按钮不可用
|
||||
|
||||
### 数量受限态
|
||||
|
||||
- 当数量受库存限制时：
|
||||
- 步进器不可继续增加
|
||||
- 需要给出明确提示
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 购物车数据异常时展示 `G04`
|
||||
- 支持重试，不直接显示过期或半残数据
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `C02` 首要解决的是“已选商品确认 + 失效清理 + 去结算”，不是优惠结算主战场
|
||||
- 商品组合的合法性应主要在 `C01` 完成，`C02` 负责承接结果并处理后续状态变化
|
||||
- 购物车里的活动提示只做轻结果，不提前解释完整优惠计算
|
||||
- 优惠券、储值、次卡、积分、支付方式统一放到 `P03` 或后续弹层承接
|
||||
- 去结算按钮必须只保留一个主路径，不做复杂分支
|
||||
|
||||
|
||||
@@ -2,71 +2,241 @@
|
||||
|
||||
- 页面编码：`P03`
|
||||
- 页面层级：`二级页`
|
||||
- 适用场景：`外卖 / 自提 / 堂食`
|
||||
- 页面目标：让用户确认履约信息、优惠和金额，并完成支付
|
||||
- 主要依赖组件：`G01`、`G30`、`G31`、`G32`、`G35`
|
||||
- 适用场景：`delivery / pickup / dine_in`
|
||||
- 页面目标：承接门店、场景和商品组合后的最终确认，向顾客解释金额来源，并完成提交订单与支付前确认
|
||||
- 主要依赖组件：`G01`、`G30`、`G31`、`G32`、`G35`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`、`03-结算与支付链路.md`、`05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 场景信息卡
|
||||
2. 场景履约信息卡
|
||||
3. 商品清单区
|
||||
4. 优惠资产区
|
||||
5. 备注与附加信息区
|
||||
6. 费用明细区
|
||||
7. 底部支付栏
|
||||
4. 手动资产区
|
||||
5. 自动优惠与权益结果区
|
||||
6. 备注与附加信息区
|
||||
7. 费用明细区
|
||||
8. 支付方式区
|
||||
9. 底部提交栏
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 场景信息卡
|
||||
- 外卖：展示收货地址、预计送达
|
||||
- 自提：展示门店、自提时间、取餐人信息
|
||||
- 堂食：展示门店、桌号、堂食说明
|
||||
### 2.1 场景履约信息卡
|
||||
|
||||
- 使用 `G30`
|
||||
- 这一块的职责不是展示静态说明，而是确认“本单到底如何履约”
|
||||
- 场景差异：
|
||||
- `delivery`
|
||||
- 收货地址
|
||||
- 是否可配送
|
||||
- 预计送达
|
||||
- 当前配送费
|
||||
- 是否满足起送门槛
|
||||
- `pickup`
|
||||
- 门店名称
|
||||
- 自提时间
|
||||
- 取餐人信息
|
||||
- `dine_in`
|
||||
- 门店名称
|
||||
- 桌号
|
||||
- 核心约束：
|
||||
- `pickup` 不做自由文本时间输入
|
||||
- 自提时间必须基于后台预览结果和时段配置生成可选时间
|
||||
- `dine_in` 不展示配送相关模块
|
||||
- 点击行为：
|
||||
- `delivery` 可进入 `P02 地址管理页`
|
||||
- `pickup` 可重新选择自提时间
|
||||
- `dine_in` 仅在桌号失效等异常下引导回扫码确认
|
||||
|
||||
### 2.2 商品清单区
|
||||
- 展示商品、规格、加料、数量、小计
|
||||
|
||||
### 2.3 优惠资产区
|
||||
- 承接来自 `T02 / C01 / C02` 的合法商品组合结果
|
||||
- 至少展示：
|
||||
- 商品名称
|
||||
- 规格摘要
|
||||
- 加料摘要
|
||||
- 套餐选择摘要
|
||||
- 数量
|
||||
- 商品小计
|
||||
- 这一块只展示已确认的结果，不再重做商品选配
|
||||
- 如用户需要修改商品组合，优先返回购物车或点餐页，不在结算页内重新做复杂选配
|
||||
|
||||
### 2.3 手动资产区
|
||||
|
||||
- 使用 `G32`
|
||||
- 入口包含：
|
||||
- 优惠券选择
|
||||
- 积分抵扣
|
||||
- 这一块只承接真正需要顾客主动选择的资产
|
||||
- 当前冻结为三类：
|
||||
- 优惠券
|
||||
- 储值余额支付
|
||||
- 次卡核销（适用时）
|
||||
- 次卡核销
|
||||
- 每一类都需要展示：
|
||||
- 当前是否可用
|
||||
- 已选择结果或当前默认状态
|
||||
- 不可用原因
|
||||
- 典型不可用原因：
|
||||
- 不适用当前门店
|
||||
- 不适用当前场景
|
||||
- 不适用当前商品
|
||||
- 未达到门槛
|
||||
- 已过期 / 已用完
|
||||
- 当前不在本页冻结为正式主流程能力：
|
||||
- 积分抵扣
|
||||
- 如后续需要承接更细的选择交互，应由 `C04 优惠选择弹层` 处理，不在本页直接展开长列表
|
||||
|
||||
### 2.4 备注与附加信息区
|
||||
- 订单备注
|
||||
- 餐具选择
|
||||
- 其他补充字段（按场景可选）
|
||||
### 2.4 自动优惠与权益结果区
|
||||
|
||||
- 这一块专门承接“系统自动命中”的结果，不让顾客手动勾选规则
|
||||
- 可承接的结果包括：
|
||||
- 满减命中结果
|
||||
- 新客有礼命中结果
|
||||
- 会员折扣
|
||||
- 会员免配送费权益
|
||||
- 会员日额外折扣
|
||||
- 展示原则：
|
||||
- 清楚告诉用户“已为你优惠多少”
|
||||
- 必要时说明不叠加或已自动选择最优
|
||||
- 这一块不是优惠规则详情页，不展开后台活动配置细节
|
||||
|
||||
### 2.5 备注与附加信息区
|
||||
|
||||
- 可承接的输入项：
|
||||
- 订单备注
|
||||
- 餐具相关选择
|
||||
- 场景需要的少量补充字段
|
||||
- 这里不扩展为大而杂的表单区
|
||||
- `pickup` 场景的核心仍是时间与取餐信息，不应混入无证据的附加规则
|
||||
- `dine_in` 场景不在这里新增“合单 / 加菜 / 先付款”等后台未证实项
|
||||
|
||||
### 2.6 费用明细区
|
||||
|
||||
### 2.5 费用明细区
|
||||
- 使用 `G31`
|
||||
- 必须清楚展示所有金额构成
|
||||
- 这一块必须明确回答“为什么付这个金额”
|
||||
- 至少拆清楚：
|
||||
- 商品金额
|
||||
- 包装费
|
||||
- 餐具费
|
||||
- 配送费
|
||||
- 自动优惠减免
|
||||
- 手动资产减免
|
||||
- 实付金额
|
||||
- 费用明细只展示顾客需要理解的收费项和减免项，不展示后台记账字段
|
||||
- 如果某项费用或减免来自门店规则、商品组合或资产使用，必须用顾客能理解的文案解释
|
||||
|
||||
### 2.7 支付方式区
|
||||
|
||||
- 这一块只展示本单当前支付方式摘要，不做复杂收银台
|
||||
- 当前小程序支付方式先收敛为：
|
||||
- 微信支付
|
||||
- 余额支付
|
||||
- `alipay / cash / card` 虽然存在于后台订单或交易口径中，但不前置为小程序支付方式选项
|
||||
- 如需切换支付方式，由 `C05 支付方式弹层` 承接
|
||||
- 当余额不足时，需要明确提示：
|
||||
- 当前余额不足以完成支付
|
||||
- 可切换微信支付或前往充值
|
||||
|
||||
### 2.8 底部提交栏
|
||||
|
||||
### 2.6 底部支付栏
|
||||
- 使用 `G35`
|
||||
- 左侧显示实付金额
|
||||
- 右侧主按钮：提交订单并支付
|
||||
- 左侧展示：
|
||||
- 实付金额
|
||||
- 可选的优惠结果摘要
|
||||
- 右侧主按钮统一为：
|
||||
- `提交订单并支付`
|
||||
- 主按钮点击后：
|
||||
- 先完成结算校验
|
||||
- 再进入支付方式确认
|
||||
- 未登录时，提交动作应先触发 `C03 登录授权弹层`
|
||||
|
||||
## 3. 场景差异
|
||||
## 3. 场景差异规则
|
||||
|
||||
### 外卖
|
||||
- 必须完成地址校验、起送价校验
|
||||
### `delivery`
|
||||
|
||||
### 自提
|
||||
- 必须完成自提时间选择和取餐人信息校验
|
||||
- 必须完成地址校验
|
||||
- 必须完成配送可用性校验
|
||||
- 必须完成起送门槛校验
|
||||
- 页面中应明确展示：
|
||||
- 收货地址
|
||||
- 预计送达
|
||||
- 配送费
|
||||
- 是否满足起送
|
||||
|
||||
### 堂食
|
||||
- 必须展示桌号，不展示配送相关字段
|
||||
### `pickup`
|
||||
|
||||
- 必须选择有效自提时间
|
||||
- 自提时间来自后台可预约结果，不允许自由输入文本时间
|
||||
- 页面中应明确展示：
|
||||
- 门店
|
||||
- 自提时间
|
||||
- 取餐人信息
|
||||
|
||||
### `dine_in`
|
||||
|
||||
- 必须展示门店与桌号
|
||||
- 不展示配送相关字段
|
||||
- 不在本页扩展堂食业务增强规则
|
||||
|
||||
## 4. 页面状态
|
||||
|
||||
- 优惠不可用时展示原因
|
||||
- 地址超范围时禁止提交
|
||||
- 门店休息时禁止支付
|
||||
### 默认态
|
||||
|
||||
- 场景信息完整
|
||||
- 商品组合合法
|
||||
- 费用明细完整
|
||||
- 可正常进入支付确认
|
||||
|
||||
### 资产不可用态
|
||||
|
||||
- 某项手动资产不可用时：
|
||||
- 保留入口或结果位
|
||||
- 明确展示不可用原因
|
||||
- 不允许只显示灰态而不给原因
|
||||
|
||||
### 地址异常 / 不可配送态
|
||||
|
||||
- 仅 `delivery` 场景出现
|
||||
- 当地址超出范围或当前不可配送时：
|
||||
- 禁止提交订单
|
||||
- 明确引导切换地址或切换门店
|
||||
|
||||
### 未达起送态
|
||||
|
||||
- 仅 `delivery` 场景出现
|
||||
- 明确展示还差多少起送
|
||||
- 禁止提交订单
|
||||
|
||||
### 自提时间未完成态
|
||||
|
||||
- 仅 `pickup` 场景出现
|
||||
- 当未选择或已失效时段时：
|
||||
- 禁止提交订单
|
||||
- 引导重新选择可用时间
|
||||
|
||||
### 门店休息态
|
||||
|
||||
- 当前门店休息或当前场景不可下单时：
|
||||
- 禁止提交订单
|
||||
- 明确说明原因
|
||||
|
||||
### 余额不足态
|
||||
|
||||
- 当顾客选中余额支付但余额不足时：
|
||||
- 明确提示余额不足
|
||||
- 引导切换微信支付或前往充值
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重新加载结算预览数据
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- 结算页核心是“信息确认 + 金额确认”
|
||||
- 所有会影响实付金额的项目都必须可见
|
||||
- `P03` 的核心不是“列很多入口”，而是让顾客确认履约方式、理解金额来源、完成必要选择
|
||||
- 结算页必须明确区分：
|
||||
- 手动资产
|
||||
- 自动优惠
|
||||
- 权益结果
|
||||
- `积分抵扣` 当前不冻结为正式主流程能力
|
||||
- 结算页不应把所有优惠都做成同级可切换入口
|
||||
- 小程序支付方式先收敛为微信支付和余额支付
|
||||
- 结算页里的金额解释必须和门店规则、商品组合、资产使用结果保持一致
|
||||
|
||||
|
||||
@@ -2,41 +2,104 @@
|
||||
|
||||
- 页面编码：`P04`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：明确告诉用户支付已完成，并引导后续查看订单或继续点单
|
||||
- 页面目标：明确告诉顾客本次支付已经完成，并把顾客送往当前场景下最有价值的下一步动作
|
||||
- 主要依赖组件：`G01`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`、`04-履约订单与售后链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 成功状态区
|
||||
2. 订单摘要区
|
||||
3. 场景关键信息区
|
||||
4. 后续动作区
|
||||
4. 下一步动作区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 成功状态区
|
||||
- 成功图标
|
||||
- 标题：支付成功
|
||||
- 副文案：订单已提交，等待商家处理
|
||||
|
||||
- 展示支付成功的明确结果
|
||||
- 至少包含：
|
||||
- 成功图标
|
||||
- 标题：`支付成功`
|
||||
- 副文案：订单已提交，等待商家处理
|
||||
- 这一区块只确认支付完成，不重新解释整套优惠计算过程
|
||||
|
||||
### 2.2 订单摘要区
|
||||
- 展示订单号、门店名称、支付金额
|
||||
|
||||
- 至少展示：
|
||||
- 订单号
|
||||
- 门店名称
|
||||
- 支付金额
|
||||
- 支付方式
|
||||
- 支付方式口径与结算页保持一致：
|
||||
- 微信支付
|
||||
- 余额支付
|
||||
- 这一块的职责是帮助顾客快速确认“哪一单、付了多少、用什么付的”
|
||||
|
||||
### 2.3 场景关键信息区
|
||||
- 外卖：预计送达时间
|
||||
- 自提：取餐时间和取餐说明
|
||||
- 堂食：桌号与用餐状态
|
||||
|
||||
### 2.4 后续动作区
|
||||
- 查看订单详情
|
||||
- 继续点餐 / 再逛逛
|
||||
- 这一块必须继承结算结果中的场景核心信息，不能做成一套通用空模板
|
||||
|
||||
#### `delivery`
|
||||
|
||||
- 至少展示：
|
||||
- 预计送达时间或预计送达区间
|
||||
- 当前履约进入下一步的简短说明
|
||||
- 当前不在本页冻结：
|
||||
- 骑手轨迹
|
||||
- 精确骑手位置地图
|
||||
|
||||
#### `pickup`
|
||||
|
||||
- 至少展示：
|
||||
- 取餐时间
|
||||
- 取餐提示
|
||||
- 当前不在本页强写：
|
||||
- 取餐码一定存在
|
||||
- 取餐号一定存在
|
||||
|
||||
#### `dine_in`
|
||||
|
||||
- 至少展示：
|
||||
- 门店名称
|
||||
- 桌号
|
||||
- 当前用餐上下文提示
|
||||
- 当前不在本页扩展：
|
||||
- 合单
|
||||
- 加菜
|
||||
- 先付款等堂食增强规则
|
||||
|
||||
### 2.4 下一步动作区
|
||||
|
||||
- CTA 必须收敛为少量高价值动作
|
||||
- 当前主动作保留：
|
||||
- 查看订单详情
|
||||
- 继续点餐 / 再逛逛
|
||||
- 不在本页堆过多次级操作，避免结果页变成控制面板
|
||||
- 如后续要补消息提醒、发票申请、客服等能力，应优先进入订单详情页再承接，而不是直接塞到成功页
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 支付成功为唯一主状态
|
||||
- 若返回支付结果异常，应回退到结算页或订单详情页校验状态
|
||||
### 默认成功态
|
||||
|
||||
- 支付成功是页面唯一主状态
|
||||
- 页面应立即告诉顾客：
|
||||
- 支付已经完成
|
||||
- 这是一张什么订单
|
||||
- 下一步该看什么
|
||||
|
||||
### 结果异常态
|
||||
|
||||
- 若返回支付结果异常或状态不一致：
|
||||
- 不停留在错误成功页
|
||||
- 应回退到结算页或订单详情页做状态校验
|
||||
|
||||
## 4. 实现备注
|
||||
|
||||
- 成功页停留时间不宜过长，应明确给出下一步 CTA
|
||||
- `P04` 是结果承接页，不是优惠解释页，也不是履约详情页
|
||||
- 成功页必须按场景给出最关键的信息：
|
||||
- 外卖看送达
|
||||
- 自提看取餐
|
||||
- 堂食看桌号上下文
|
||||
- 页面停留不宜过长，但必须有明确 CTA，避免顾客成功后失去方向
|
||||
|
||||
|
||||
@@ -2,70 +2,221 @@
|
||||
|
||||
- 页面编码：`P05`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：完整承接订单履约、售后和复购动作
|
||||
- 主要依赖组件：`G01`、`G31`、`G34`、`G35`
|
||||
- 页面目标：把订单完整讲清楚，让顾客理解当前状态，并在当前状态下执行唯一有价值的下一步动作
|
||||
- 主要依赖组件：`G01`、`G31`、`G34`、`G35`、`G05`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部状态头图区
|
||||
2. 场景信息区
|
||||
2. 场景履约信息区
|
||||
3. 履约时间轴区
|
||||
4. 商品清单区
|
||||
5. 费用明细区
|
||||
6. 订单基础信息区
|
||||
7. 底部操作栏
|
||||
7. 售后结果摘要区（有售后时出现）
|
||||
8. 底部操作栏
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 顶部状态头图区
|
||||
- 展示当前状态文案与辅助说明
|
||||
- 示例：
|
||||
|
||||
- 这一块是强状态表达区，必须让顾客一眼知道：
|
||||
- 这单现在是什么状态
|
||||
- 接下来最可能发生什么
|
||||
- 状态文案必须使用顾客任务语言，不复用商家后台术语
|
||||
- 可承接的状态表达包括：
|
||||
- 待支付
|
||||
- 商家已接单
|
||||
- 商家处理中
|
||||
- 制作中
|
||||
- 配送中
|
||||
- 待自提
|
||||
- 待取餐
|
||||
- 已完成
|
||||
- 退款中
|
||||
- 已退款
|
||||
- 已取消
|
||||
- 状态头图区可以带一条简短辅助说明，但不扩展成长说明页
|
||||
|
||||
### 2.2 场景信息区
|
||||
- 外卖：收货地址、骑手状态、预计送达
|
||||
- 自提：取餐码、取餐时间、门店信息
|
||||
- 堂食：桌号、门店、是否可继续加菜
|
||||
### 2.2 场景履约信息区
|
||||
|
||||
- 这一块按场景拆开表达，不用一套字段硬套三种履约
|
||||
|
||||
#### `delivery`
|
||||
|
||||
- 至少展示：
|
||||
- 收货地址
|
||||
- 收货人
|
||||
- 联系方式
|
||||
- 可展示当前履约提示或预计送达信息
|
||||
- 当前不在本页冻结：
|
||||
- 骑手轨迹
|
||||
- 精确骑手地图
|
||||
|
||||
#### `pickup`
|
||||
|
||||
- 至少展示：
|
||||
- 门店信息
|
||||
- 取餐提示
|
||||
- 如后端后续补出取餐码 / 取餐号，可在本区承接
|
||||
- 当前不强制写死：
|
||||
- 取餐码一定存在
|
||||
- 取餐号一定存在
|
||||
|
||||
#### `dine_in`
|
||||
|
||||
- 至少展示：
|
||||
- 门店信息
|
||||
- 当前堂食上下文说明
|
||||
- 如订单快照中具备桌号，可回显桌号
|
||||
- 当前不把“完整桌号回显”冻结为所有堂食订单的必有字段
|
||||
- 当前不在本页引入：
|
||||
- 继续加菜
|
||||
- 合单
|
||||
- 先付款
|
||||
|
||||
### 2.3 履约时间轴区
|
||||
|
||||
- 使用 `G34`
|
||||
- 展示订单关键节点时间
|
||||
- 展示订单关键时间节点
|
||||
- 时间轴目标是帮助顾客理解“进展到哪里了”，不是复刻商家履约操作流
|
||||
- 可展示的节点包括：
|
||||
- 下单
|
||||
- 支付成功
|
||||
- 商家处理中 / 制作中
|
||||
- 配送中 / 待取餐 / 堂食进行中
|
||||
- 已完成
|
||||
- 退款处理结果
|
||||
- 时间轴节点数量和名称不在当前文档里写死过细，以后端结果为准
|
||||
|
||||
### 2.4 商品清单区
|
||||
- 展示商品、规格、加料、数量
|
||||
|
||||
- 这一块完整承接订单中的商品结果
|
||||
- 至少展示：
|
||||
- 商品名称
|
||||
- 规格摘要
|
||||
- 加料摘要
|
||||
- 套餐选择摘要
|
||||
- 数量
|
||||
- 商品小计
|
||||
- 这是订单结果区，不再允许编辑商品组合
|
||||
- 如后续支持“再来一单”，也应基于这里的结果回流到点餐页，而不是在本区直接改单
|
||||
|
||||
### 2.5 费用明细区
|
||||
|
||||
- 使用 `G31`
|
||||
- 展示所有金额构成
|
||||
- 至少展示顾客可理解的金额构成：
|
||||
- 商品金额
|
||||
- 包装费
|
||||
- 餐具费
|
||||
- 配送费
|
||||
- 优惠减免
|
||||
- 实付金额
|
||||
- 金额口径需与结算页保持一致
|
||||
- 不展示后台财务记账字段
|
||||
|
||||
### 2.6 订单基础信息区
|
||||
- 展示订单号、下单时间、支付方式、支付时间等
|
||||
|
||||
### 2.7 底部操作栏
|
||||
- 至少展示：
|
||||
- 订单号
|
||||
- 下单时间
|
||||
- 支付方式
|
||||
- 支付时间
|
||||
- 备注
|
||||
- 如后续存在更多稳定的基础字段，可继续扩展，但不在当前把后台筛选字段直接暴露给顾客
|
||||
|
||||
### 2.7 售后结果摘要区
|
||||
|
||||
- 当订单已进入退款中 / 已退款等售后状态时，显示这一块
|
||||
- 至少展示：
|
||||
- 当前退款状态
|
||||
- 退款金额
|
||||
- 退款原因摘要
|
||||
- 这一块只做摘要和导流
|
||||
- 需要查看更完整售后结果时，进入 `P07 退款详情页`
|
||||
|
||||
### 2.8 底部操作栏
|
||||
|
||||
- 使用 `G35`
|
||||
- 动作随状态变化：
|
||||
- 动作必须按状态收敛，不做商家控制面板
|
||||
|
||||
#### `待支付`
|
||||
|
||||
- 可保留：
|
||||
- 继续支付
|
||||
- 取消订单
|
||||
|
||||
#### `进行中`
|
||||
|
||||
- 主动作以“查看履约信息”为主
|
||||
- 如后续退款申请能力补齐，可在允许时显示“申请退款”
|
||||
- 当前不把以下能力冻结为固定按钮：
|
||||
- 催单
|
||||
- 申请退款
|
||||
- 骑手轨迹
|
||||
- 取餐码查看
|
||||
|
||||
#### `已完成`
|
||||
|
||||
- 可保留：
|
||||
- 去评价
|
||||
- 再来一单
|
||||
|
||||
#### `售后`
|
||||
|
||||
- 可保留：
|
||||
- 查看退款详情
|
||||
|
||||
#### 结果态
|
||||
|
||||
- 已取消等只读结果态，以查看信息为主
|
||||
- 不堆叠无意义操作
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 待支付态
|
||||
- 履约进行态
|
||||
- 已完成态
|
||||
- 退款中态
|
||||
- 已退款态
|
||||
### 待支付态
|
||||
|
||||
- 明确告诉顾客：
|
||||
- 订单尚未支付
|
||||
- 是否还能继续支付
|
||||
- 底部操作以继续支付为主
|
||||
|
||||
### 履约进行态
|
||||
|
||||
- 明确告诉顾客订单正在被处理
|
||||
- 重点在状态解释和履约信息，不在页面里堆大量动作
|
||||
|
||||
### 已完成态
|
||||
|
||||
- 重点回到评价和复购
|
||||
- 页面不再强调履约过程焦虑信息
|
||||
|
||||
### 退款中态
|
||||
|
||||
- 明确告诉顾客售后正在处理中
|
||||
- 提供查看退款结果的稳定入口
|
||||
|
||||
### 已退款态
|
||||
|
||||
- 明确告诉顾客退款已经完成
|
||||
- 保留查看退款详情动作
|
||||
|
||||
### 已取消态
|
||||
|
||||
- 页面以结果展示为主
|
||||
- 不再展示与履约相关的动作
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不直接停留在半残状态
|
||||
|
||||
## 4. 实现备注
|
||||
|
||||
- 订单详情页是强状态页面，顶部状态区必须足够明确
|
||||
- `P05` 是强状态详情页，核心是“讲清状态 + 讲清订单 + 给出当前唯一有价值的动作”
|
||||
- 订单详情页不复用商家侧动作：
|
||||
- 接单
|
||||
- 拒单
|
||||
- 出餐完成
|
||||
- 确认送达
|
||||
- 外卖、自提、堂食三种场景要分别表达，但当前不把未证实能力写死
|
||||
- 完整售后结果进入 `P07`，最小退款申请进入 `P06`，评价进入 `P08`
|
||||
|
||||
|
||||
@@ -2,45 +2,104 @@
|
||||
|
||||
- 页面编码：`P06`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：让用户提交退款原因与说明，进入售后流程
|
||||
- 主要依赖组件：`G01`
|
||||
- 页面目标：在订单允许申请售后时，低阻力提交一份最小可用退款申请，并把顾客送入稳定的退款结果查看链路
|
||||
- 主要依赖组件：`G01`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 可退款订单摘要区
|
||||
3. 退款原因区
|
||||
4. 补充说明区
|
||||
5. 提交按钮区
|
||||
3. 可退金额区
|
||||
4. 退款原因区
|
||||
5. 补充说明区
|
||||
6. 提交按钮区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 可退款订单摘要区
|
||||
- 展示门店、订单号、商品摘要、当前可退金额
|
||||
|
||||
### 2.2 退款原因区
|
||||
- 提供预设原因列表
|
||||
- 例如：
|
||||
- 商品与描述不符
|
||||
- 配送超时
|
||||
- 少送漏送
|
||||
- 不想要了
|
||||
- 其他原因
|
||||
- 这一块用于先确认“你正在给哪一单发起退款申请”
|
||||
- 至少展示：
|
||||
- 门店名称
|
||||
- 订单号
|
||||
- 商品摘要
|
||||
- 这一区块只做摘要确认，不重复展开完整订单详情
|
||||
|
||||
### 2.3 补充说明区
|
||||
- 文本输入框
|
||||
- 可选上传凭证图片（如另一位 AI 需要扩展）
|
||||
### 2.2 可退金额区
|
||||
|
||||
### 2.4 提交按钮区
|
||||
- 主按钮：提交退款申请
|
||||
- 明确展示当前可退金额
|
||||
- 如果后端后续补充更多退款范围解释，可在这里扩展
|
||||
- 当前不把以下能力冻结为正式必有：
|
||||
- 部分退款逐商品明细
|
||||
- 复杂退款规则解释
|
||||
|
||||
### 2.3 退款原因区
|
||||
|
||||
- 页面需要提供退款原因选择
|
||||
- 当前只冻结“需要有退款原因”这一能力，不冻结具体原因枚举体系
|
||||
- 也就是说：
|
||||
- 可以有预设原因列表
|
||||
- 也可以保留“其他原因”
|
||||
- 但不在本页把原因分类、售后责任判定、复杂规则写死
|
||||
|
||||
### 2.4 补充说明区
|
||||
|
||||
- 提供文本输入框，允许用户补充说明
|
||||
- 目标是帮助顾客补一句必要背景，而不是做复杂售后表单
|
||||
- 当前不把以下能力冻结为正式必做：
|
||||
- 图片凭证上传
|
||||
- 多段说明
|
||||
- 按商品逐项问题说明
|
||||
|
||||
### 2.5 提交按钮区
|
||||
|
||||
- 主按钮统一为：`提交退款申请`
|
||||
- 提交后应进入 `P07 退款详情页`
|
||||
- 页面不做复杂多分支售后流转
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 原因未选时按钮不可提交
|
||||
- 提交中显示 loading
|
||||
### 默认态
|
||||
|
||||
- 订单允许申请退款
|
||||
- 顾客可以看到订单摘要、可退金额，并填写最小必要信息
|
||||
|
||||
### 原因未完成态
|
||||
|
||||
- 未选择退款原因时，按钮不可提交
|
||||
- 不允许只提示报错而不明确缺少项
|
||||
|
||||
### 提交中态
|
||||
|
||||
- 提交按钮显示 loading
|
||||
- 避免重复提交
|
||||
|
||||
### 提交成功态
|
||||
|
||||
- 提交成功后跳转 `P07 退款详情页`
|
||||
- 不停留在申请页反复确认
|
||||
|
||||
### 不可申请态
|
||||
|
||||
- 当当前订单不允许申请退款时：
|
||||
- 不继续展示正常申请表单
|
||||
- 明确提示当前不可申请
|
||||
- 引导回订单详情或退款结果页
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残申请表单
|
||||
|
||||
## 4. 实现备注
|
||||
|
||||
- 页面目标是低阻力提交，不宜放过多冗余字段
|
||||
- `P06` 的目标是“低阻力申请”，不是完整售后系统
|
||||
- 当前不冻结以下复杂能力：
|
||||
- 部分退款
|
||||
- 按商品逐项退款
|
||||
- 处理 SLA 展示
|
||||
- 固定原因枚举体系
|
||||
- 图片凭证上传为必做
|
||||
- 页面是否显示入口，应由 `P05` 中的订单状态和后端能力标记共同决定
|
||||
|
||||
|
||||
@@ -2,8 +2,9 @@
|
||||
|
||||
- 页面编码：`P07`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：展示退款申请的当前处理状态、时间轴和处理结果
|
||||
- 主要依赖组件：`G01`、`G34`
|
||||
- 页面目标：给顾客一个稳定的退款结果查看页，承接退款状态、退款金额、退款原因、处理时间线和关联订单信息
|
||||
- 主要依赖组件：`G01`、`G34`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
@@ -12,36 +13,83 @@
|
||||
3. 退款金额与原因区
|
||||
4. 退款时间轴区
|
||||
5. 订单关联信息区
|
||||
6. 后续动作区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 退款状态头图区
|
||||
- 展示当前退款状态：
|
||||
|
||||
- 这一块首先回答“这笔退款现在进行到哪一步了”
|
||||
- 状态文案应使用顾客能理解的结果语言
|
||||
- 可展示的结果包括：
|
||||
- 已提交
|
||||
- 处理中
|
||||
- 已退款
|
||||
- 已拒绝
|
||||
- 同时展示简要说明文案
|
||||
- 可搭配一条简短辅助说明，但不展开成复杂审核系统说明
|
||||
- 当前不把后台内部处理节点和商家处理动作直接暴露给顾客
|
||||
|
||||
### 2.2 退款金额与原因区
|
||||
- 展示退款金额
|
||||
- 展示退款原因与用户补充说明
|
||||
|
||||
- 至少展示：
|
||||
- 退款金额
|
||||
- 退款原因
|
||||
- 顾客补充说明摘要（如有）
|
||||
- 如果后端后续补充驳回原因，可直接在这一块显示
|
||||
- 这一块只展示顾客关心的结果信息，不展示后台审批字段
|
||||
|
||||
### 2.3 退款时间轴区
|
||||
|
||||
- 使用 `G34`
|
||||
- 展示：申请时间、商家处理时间、退款完成时间等
|
||||
- 时间轴目标是帮助顾客理解处理进展，而不是定义一套固定售后流程图
|
||||
- 至少需要承接：
|
||||
- 申请提交时间
|
||||
- 后续处理结果时间
|
||||
- 如后端存在更多稳定节点，可继续补充
|
||||
- 当前不把时间线节点数量、名称、阶段数写死过细
|
||||
|
||||
### 2.4 订单关联信息区
|
||||
- 展示订单号、门店、商品摘要
|
||||
- 提供返回订单详情的入口
|
||||
|
||||
- 至少展示：
|
||||
- 订单号
|
||||
- 门店名称
|
||||
- 商品摘要
|
||||
- 这一块用于帮助顾客确认“这是哪一单的退款”
|
||||
- 可提供返回订单详情的入口
|
||||
|
||||
### 2.5 后续动作区
|
||||
|
||||
- CTA 应收敛为结果查看后的高价值动作
|
||||
- 可保留：
|
||||
- 返回订单详情
|
||||
- 返回订单列表
|
||||
- 不在本页扩展复杂售后客服流转
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 处理中
|
||||
- 已退款
|
||||
- 已拒绝
|
||||
### 处理中
|
||||
|
||||
- 明确告诉顾客退款仍在处理
|
||||
- 保留时间线和订单关联信息，减少不确定感
|
||||
|
||||
### 已退款
|
||||
|
||||
- 明确告诉顾客退款已经完成
|
||||
- 保留退款金额和关联订单信息
|
||||
|
||||
### 已拒绝
|
||||
|
||||
- 如后端提供驳回原因，应明确展示
|
||||
- 不只显示“已拒绝”结果，不给原因
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残结果页
|
||||
|
||||
## 4. 实现备注
|
||||
|
||||
- 拒绝状态必须明确展示驳回原因
|
||||
- `P07` 是结果查看页，不是退款申请页，也不是完整售后工作台
|
||||
- 页面职责重点是“稳定解释结果”，不是提前冻结复杂售后阶段
|
||||
- 如后续后端补充更多退款节点或驳回信息，可在当前结构内扩展，不需要重新改页面职责
|
||||
|
||||
|
||||
@@ -2,55 +2,99 @@
|
||||
|
||||
- 页面编码：`P08`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：完成订单评价，并引导商家回复与评价奖励闭环
|
||||
- 主要依赖组件：`G01`
|
||||
- 页面目标：让顾客在订单完成后提交最小可用评价，完成评分、评价内容和晒单上传闭环
|
||||
- 主要依赖组件：`G01`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 与 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 订单摘要区
|
||||
3. 星级评分区
|
||||
4. 快捷评价标签区
|
||||
5. 文本评价区
|
||||
6. 图片上传区
|
||||
7. 匿名开关区
|
||||
8. 提交按钮区
|
||||
3. 评分区
|
||||
4. 文本评价区
|
||||
5. 图片上传区
|
||||
6. 提交操作区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 订单摘要区
|
||||
- 展示门店名称和商品摘要
|
||||
|
||||
### 2.2 星级评分区
|
||||
- 选择 1-5 星
|
||||
- 星级变化可联动文案提示
|
||||
- 这一块先帮助顾客确认“我正在评价哪一单”
|
||||
- 至少展示：
|
||||
- 门店名称
|
||||
- 商品摘要
|
||||
- 下单时间或完成时间
|
||||
- 这一块只做识别，不扩展成订单详情页替代品
|
||||
|
||||
### 2.3 快捷评价标签区
|
||||
- 根据评分展示标签
|
||||
- 例如：
|
||||
- 味道不错
|
||||
- 包装精致
|
||||
- 配送很快
|
||||
- 分量足
|
||||
### 2.2 评分区
|
||||
|
||||
### 2.4 文本评价区
|
||||
- 支持自由输入评价内容
|
||||
- 评分是本页最核心的输入项
|
||||
- 支持 1 到 5 星
|
||||
- 评分后可配一条轻量文案辅助顾客理解当前选择
|
||||
- 当前不把评分后联动的复杂标签体系写成正式能力
|
||||
|
||||
### 2.5 图片上传区
|
||||
- 支持晒单图片上传
|
||||
### 2.3 文本评价区
|
||||
|
||||
### 2.6 匿名开关区
|
||||
- 允许用户匿名评价
|
||||
- 支持顾客输入自由评价内容
|
||||
- 目标是补充对本次消费体验的主观反馈
|
||||
- 当前文档只冻结“可输入评价内容”这一能力
|
||||
- 文本长度限制、敏感词处理、是否必填等规则以后端提交契约为准
|
||||
|
||||
### 2.7 提交按钮区
|
||||
- 主按钮：提交评价
|
||||
### 2.4 图片上传区
|
||||
|
||||
- 支持上传晒单图片
|
||||
- 这一能力已有后台文件上传类型支撑，可以作为正式页面能力保留
|
||||
- 图片上传用于补充真实消费反馈，不扩展成复杂内容社区
|
||||
- 上传数量上限、压缩规则、审核规则当前不在本页写死
|
||||
|
||||
### 2.5 提交操作区
|
||||
|
||||
- 主按钮：`提交评价`
|
||||
- 页面只保留一个主提交流程，不叠加复杂分支动作
|
||||
- 提交成功后应返回稳定结果反馈，不在本页扩展营销弹窗闭环
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 未评分时按钮不可提交
|
||||
- 提交成功后提示是否返回订单详情或继续浏览
|
||||
### 未评分态
|
||||
|
||||
## 4. 实现备注
|
||||
- 未完成评分前，提交按钮不可用
|
||||
- 页面应优先引导顾客先完成星级选择
|
||||
|
||||
- 评价成功后可弹出“获得积分”提示，但不应阻塞主流程
|
||||
### 可提交态
|
||||
|
||||
- 完成评分后允许提交
|
||||
- 文本和图片在当前冻结范围内默认按可选输入处理
|
||||
|
||||
### 提交成功态
|
||||
|
||||
- 明确提示评价已提交成功
|
||||
- 可提供：
|
||||
- 返回订单详情
|
||||
- 返回订单列表
|
||||
- 如果后台配置了评价奖励积分，可使用轻提示说明获得奖励
|
||||
- 奖励提示不能反过来主导页面，也不做复杂营销弹窗
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残页面
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 快捷评价标签
|
||||
- 匿名评价开关
|
||||
- 商家回复展示与回复闭环
|
||||
- 评价后分享裂变玩法
|
||||
- 复杂积分任务说明
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源还不足以把它们写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P08` 是最小评价提交页，不是内容社区页，也不是营销奖励页
|
||||
- 页面重点只有三件事：
|
||||
- 让顾客确认订单
|
||||
- 让顾客完成评价输入
|
||||
- 让顾客稳定提交成功
|
||||
- 评价奖励积分只作为成功反馈中的轻提示，与 `我的` 或积分资产联动即可
|
||||
|
||||
|
||||
@@ -2,41 +2,91 @@
|
||||
|
||||
- 页面编码：`P09`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：集中展示可领取优惠券，并引导回到点餐使用
|
||||
- 主要依赖组件：`G01`、`G43`
|
||||
- 页面目标：集中展示当前门店、当前场景下可见的券模板，并引导顾客回到点餐主链路使用
|
||||
- 主要依赖组件：`G01`、`G43`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 券分类筛选区
|
||||
3. 优惠券列表区
|
||||
4. 底部引导区
|
||||
2. 轻筛选区
|
||||
3. 券模板列表区
|
||||
4. 底部导购区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 券分类筛选区
|
||||
- 可按全部、满减券、折扣券、免配送费券筛选
|
||||
### 2.1 轻筛选区
|
||||
|
||||
- 这一块用于帮助顾客快速收缩券模板范围
|
||||
- 可保留的类型筛选包括：
|
||||
- 全部
|
||||
- 满减券
|
||||
- 折扣券
|
||||
- 免配送费券
|
||||
- 筛选的目标是提升列表可扫读性，不是做复杂券管理后台
|
||||
|
||||
### 2.2 券模板列表区
|
||||
|
||||
### 2.2 优惠券列表区
|
||||
- 使用 `G43`
|
||||
- 每张券卡必须展示：
|
||||
- 这一块是本页核心内容，展示当前可见券模板
|
||||
- 每张券卡至少展示：
|
||||
- 券名称
|
||||
- 金额 / 折扣
|
||||
- 金额或折扣
|
||||
- 使用门槛
|
||||
- 有效期
|
||||
- 适用门店 / 场景
|
||||
- 领取状态
|
||||
- 适用门店
|
||||
- 适用场景
|
||||
- 如后台具备每人限领、开放领取、暂停领取等模板状态，可用于结果说明
|
||||
- 当前页面重点是“这张券是什么、能不能领、适合什么场景”
|
||||
|
||||
### 2.3 底部引导区
|
||||
- 提供“去点餐”入口
|
||||
### 2.3 底部导购区
|
||||
|
||||
- 这一块用于把顾客从领券中心导回主交易链路
|
||||
- 可保留：
|
||||
- 去点餐
|
||||
- 返回首页活动区
|
||||
- 领券中心是导购页，不应在本页内形成封闭玩法
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 默认态：有可领取券
|
||||
- 空态：无券可领
|
||||
- 已领取态：按钮改为已领取或去使用
|
||||
### 默认态
|
||||
|
||||
## 4. 实现备注
|
||||
- 有可见券模板时，优先展示券列表
|
||||
- 页面目标是让顾客快速理解“现在有哪些券值得领”
|
||||
|
||||
- 领取动作应尽量轻量，领取成功后不强制跳转
|
||||
### 空态
|
||||
|
||||
- 当当前门店、当前场景下没有可见券模板时，使用 `G03`
|
||||
- 可提供返回点餐或返回首页的导购入口
|
||||
- 不伪造券模板数据
|
||||
|
||||
### 已领取结果提示态
|
||||
|
||||
- 如后续领券动作契约补齐，可展示轻量领取成功提示
|
||||
- 结果提示应导流回点餐或我的资产页
|
||||
- 当前不把个人领取状态流写成强依赖页面结构
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残券数据
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 顾客个人已领取状态
|
||||
- 剩余可领次数
|
||||
- 去使用状态按钮
|
||||
- 我的券包详情
|
||||
- 完整领券动作接口细节
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“券模板聚合”，还不足以把顾客个人券资产状态写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P09` 的重点是“券模板聚合 + 导流回点餐”
|
||||
- 页面至少要让顾客看清楚：
|
||||
- 这是什么券
|
||||
- 适用什么门店和场景
|
||||
- 领完之后去哪里用
|
||||
- 不要把领券中心误写成“我的优惠券”资产页
|
||||
|
||||
|
||||
@@ -2,40 +2,102 @@
|
||||
|
||||
- 页面编码：`P10`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：承接强时效抢购活动，提升转化
|
||||
- 主要依赖组件：`G01`、`G21`
|
||||
- 页面目标：承接强时效、强库存、强场次的秒杀活动会场，并把顾客导回标准商品购买链路
|
||||
- 主要依赖组件：`G01`、`G21`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 秒杀头图区
|
||||
2. 活动头部区
|
||||
3. 场次切换区
|
||||
4. 秒杀商品列表区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 秒杀头图区
|
||||
- 展示活动标题、主视觉、倒计时
|
||||
### 2.1 活动头部区
|
||||
|
||||
- 这一块负责先建立秒杀会场的时间紧迫感
|
||||
- 至少突出：
|
||||
- 当前场次
|
||||
- 倒计时
|
||||
- 是否预热
|
||||
- 头部区目标是帮助顾客理解“现在能不能抢、还剩多少时间”
|
||||
|
||||
### 2.2 场次切换区
|
||||
- 展示当前场次、即将开始场次、已结束场次
|
||||
|
||||
- 秒杀页必须保留场次概念，不能被写成普通折扣页
|
||||
- 可展示：
|
||||
- 当前进行中场次
|
||||
- 即将开始场次
|
||||
- 已结束场次
|
||||
- 场次切换是秒杀页核心信息架构，不建议删掉
|
||||
|
||||
### 2.3 秒杀商品列表区
|
||||
- 商品卡展示：
|
||||
|
||||
- 每张商品卡至少展示：
|
||||
- 商品图片
|
||||
- 商品名称
|
||||
- 秒杀价
|
||||
- 原价
|
||||
- 剩余库存 / 已售比例
|
||||
- 每单限购
|
||||
- 立即抢购
|
||||
- 剩余库存或抢购进度
|
||||
- 每人限购
|
||||
- 抢购按钮
|
||||
- 商品卡必须强化“抢”的信息密度：
|
||||
- 时间
|
||||
- 库存
|
||||
- 限购
|
||||
- 点击商品后仍然进入正常商品详情、加购、购物车、结算主链路
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 未开始态
|
||||
- 进行中态
|
||||
- 已结束态
|
||||
### 预热态
|
||||
|
||||
## 4. 实现备注
|
||||
- 明确告诉顾客秒杀尚未开始
|
||||
- 可展示开始时间和当前场次信息
|
||||
- 不允许伪装成可购买状态
|
||||
|
||||
- 秒杀页要突出时间紧迫感和库存稀缺感
|
||||
### 进行中态
|
||||
|
||||
- 强调倒计时和库存变化
|
||||
- 这是页面的核心转化状态
|
||||
|
||||
### 已售罄态
|
||||
|
||||
- 如商品库存已空，应明确提示售罄
|
||||
- 不继续给出误导性的抢购按钮
|
||||
|
||||
### 已结束态
|
||||
|
||||
- 明确告诉顾客当前场次已经结束
|
||||
- 可引导查看其他场次或返回点餐
|
||||
|
||||
### 空态
|
||||
|
||||
- 当当前门店、当前场景下暂无秒杀活动时，使用 `G03`
|
||||
- 不伪造活动场次和商品列表
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残活动信息
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 独立秒杀收银台
|
||||
- 绕开商品详情直接成交的特殊交易链路
|
||||
- 复杂抢购资格体系页
|
||||
- 秒杀分享裂变闭环
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“场次、库存、秒杀价、限购”，还不足以把更多营销扩展写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P10` 的重点是“场次 + 倒计时 + 库存 + 限购”
|
||||
- 页面应该优先回答顾客四个问题：
|
||||
- 现在是哪一场
|
||||
- 还有多久结束
|
||||
- 还有没有库存
|
||||
- 我最多能抢多少
|
||||
- 秒杀页是活动会场，不是独立下单系统
|
||||
|
||||
|
||||
@@ -2,42 +2,93 @@
|
||||
|
||||
- 页面编码：`P11`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：承接限时折扣活动，集中展示折扣商品
|
||||
- 主要依赖组件：`G01`、`G21`
|
||||
- 页面目标：承接限时折扣商品会场，让顾客快速浏览当前时段更省的商品集合，并导回标准商品购买链路
|
||||
- 主要依赖组件：`G01`、`G21`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 活动头图区
|
||||
3. 活动时间筛选区
|
||||
2. 活动头部区
|
||||
3. 时间窗口区
|
||||
4. 折扣商品列表区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 活动头图区
|
||||
- 展示活动标题、当前折扣主题、时间说明
|
||||
### 2.1 活动头部区
|
||||
|
||||
### 2.2 活动时间筛选区
|
||||
- 当前进行中
|
||||
- 即将开始
|
||||
- 已结束
|
||||
- 这一块先建立限时折扣的活动认知
|
||||
- 至少展示：
|
||||
- 活动名称
|
||||
- 日期范围
|
||||
- 当前时段说明
|
||||
- 如果是循环活动，可补充周几信息
|
||||
- 头部区要突出“现在买更省”，而不是“现在必须抢”
|
||||
|
||||
### 2.2 时间窗口区
|
||||
|
||||
- 限时折扣页要强调时间窗口，而不是秒杀场次
|
||||
- 可表达：
|
||||
- 当前进行中
|
||||
- 即将开始
|
||||
- 已结束
|
||||
- 如果后端提供循环时段，可在这一块承接周期信息
|
||||
|
||||
### 2.3 折扣商品列表区
|
||||
- 商品卡展示：
|
||||
- 图片
|
||||
|
||||
- 每张商品卡至少展示：
|
||||
- 商品图片
|
||||
- 商品名称
|
||||
- 折扣价
|
||||
- 原价
|
||||
- 折扣力度
|
||||
- 立即购买
|
||||
- 每人限购
|
||||
- 去购买按钮
|
||||
- 商品卡重点表达“省了多少、现在值不值得买”
|
||||
- 点击商品后仍然进入正常商品详情、加购、购物车、结算主链路
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 进行中：可购买
|
||||
- 未开始：展示开始时间
|
||||
- 已结束：置灰展示
|
||||
### 进行中态
|
||||
|
||||
## 4. 实现备注
|
||||
- 当前活动生效，顾客可以正常进入购买链路
|
||||
- 页面应优先突出折扣价和折扣力度
|
||||
|
||||
- 与秒杀页相比，限时折扣页要弱化“抢”，强化“省”
|
||||
### 未开始态
|
||||
|
||||
- 明确展示开始时间或即将开始信息
|
||||
- 不误导顾客认为当前可直接成交
|
||||
|
||||
### 已结束态
|
||||
|
||||
- 明确展示活动已结束
|
||||
- 可引导返回点餐页或查看其他活动
|
||||
|
||||
### 空态
|
||||
|
||||
- 当当前门店、当前场景下暂无折扣活动时，使用 `G03`
|
||||
- 不伪造折扣列表和时间窗口
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残活动数据
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 与秒杀共用一套会场结构
|
||||
- 独立折扣下单系统
|
||||
- 复杂活动分享裂变页
|
||||
- 超出商品主链路的特殊交易流程
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“折扣价、时间窗口、周期规则、限购”，还不足以把更多活动扩展写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P11` 的重点是“折扣强度 + 时间窗口 + 商品集合”
|
||||
- 页面应该优先回答顾客三个问题：
|
||||
- 现在哪些商品更省
|
||||
- 折扣持续到什么时候
|
||||
- 我点进去之后怎么买
|
||||
- 限时折扣页和秒杀页必须分开表达，不要用一套模板糊过去
|
||||
|
||||
|
||||
@@ -2,46 +2,103 @@
|
||||
|
||||
- 页面编码：`P12`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：展示会员等级、成长值、权益和升级路径
|
||||
- 主要依赖组件：`G01`、`G40`
|
||||
- 页面目标：告诉顾客自己当前是什么会员等级、当前能享受什么权益，以及会员等级体系如何运作
|
||||
- 主要依赖组件：`G01`、`G40`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 会员头部卡
|
||||
3. 成长值进度区
|
||||
4. 权益总览区
|
||||
5. 等级说明区
|
||||
6. 会员日 / 生日权益区
|
||||
2. 会员头部区
|
||||
3. 当前权益区
|
||||
4. 等级说明区
|
||||
5. 专项权益说明区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 会员头部卡
|
||||
- 展示头像、昵称、当前会员等级、等级标识
|
||||
### 2.1 会员头部区
|
||||
|
||||
### 2.2 成长值进度区
|
||||
- 展示当前成长值
|
||||
- 展示距离下一等级差值
|
||||
- 这一块先回答顾客“我现在是什么等级”
|
||||
- 至少展示：
|
||||
- 当前会员等级
|
||||
- 等级标识
|
||||
- 入会时间
|
||||
- 如身份信息需要补充，可展示头像和展示名
|
||||
- 这一块不扩展成复杂成长值分析页
|
||||
|
||||
### 2.3 权益总览区
|
||||
- 展示当前可享权益：
|
||||
### 2.2 当前权益区
|
||||
|
||||
- 这是本页最核心的内容区，重点表达“我现在能享受什么”
|
||||
- 可承接的权益包括：
|
||||
- 会员折扣
|
||||
- 积分倍率
|
||||
- 生日权益
|
||||
- 每月赠券
|
||||
- 免配送费
|
||||
- 优先配送
|
||||
- 会员日额外权益
|
||||
- 权益文案要用顾客能直接理解的结果语言
|
||||
- 不把后台配置项原样暴露成顾客不可理解的规则字段
|
||||
|
||||
### 2.3 等级说明区
|
||||
|
||||
- 这一块用于说明会员体系如何运作
|
||||
- 至少说明：
|
||||
- 各等级名称
|
||||
- 各等级核心权益差异
|
||||
- 升级条件
|
||||
- 降级窗口或有效周期规则
|
||||
- 这一块的目标是让顾客理解等级体系，不是做复杂成长任务页
|
||||
|
||||
### 2.4 专项权益说明区
|
||||
|
||||
- 对需要单独解释的权益做补充说明
|
||||
- 当前优先承接：
|
||||
- 生日权益
|
||||
- 会员日权益
|
||||
|
||||
### 2.4 等级说明区
|
||||
- 展示各等级及对应权益
|
||||
|
||||
### 2.5 会员日 / 生日权益区
|
||||
- 单独说明会员日和生日特权
|
||||
- 如果后续还有稳定的专项权益，也可在这一块扩展
|
||||
- 这一块用于解释权益口径，不扩展成活动导购页
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 已登录会员态
|
||||
- 未登录提示态
|
||||
### 已登录会员态
|
||||
|
||||
## 4. 实现备注
|
||||
- 展示完整等级信息、当前权益和等级说明
|
||||
- 页面重心是帮助顾客理解可用权益，而不是刺激顾客研究复杂成长路径
|
||||
|
||||
- 会员中心要重点突出“当前能享受什么”和“如何升级”
|
||||
### 已登录非会员态
|
||||
|
||||
- 如业务存在“已登录但未入会”状态，应明确提示入会价值
|
||||
- 可展示会员权益摘要和入会引导
|
||||
- 不展示伪造的等级与权益数据
|
||||
|
||||
### 未登录态
|
||||
|
||||
- 会员中心属于顾客身份页
|
||||
- 未登录时应先引导登录 / 授权，再查看正式会员信息
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残等级数据和权益说明
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 当前成长值数值展示
|
||||
- 距离下一等级的精确差值
|
||||
- 强依赖成长进度条的主视觉
|
||||
- 复杂任务制升级路径
|
||||
- 与活动导购深度耦合的动态营销模块
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“等级与权益”，还不足以把复杂成长进度写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P12` 的重点是“当前等级 + 当前权益 + 等级说明”
|
||||
- 页面应优先回答顾客最关心的三个问题：
|
||||
- 我是什么等级
|
||||
- 我现在能享受什么
|
||||
- 不同等级差别是什么
|
||||
- 不要让成长值进度条、差值提示和升级倒计时反过来喧宾夺主
|
||||
- 会员中心不是消息页、活动页，也不是积分任务页
|
||||
|
||||
|
||||
@@ -2,43 +2,121 @@
|
||||
|
||||
- 页面编码：`P13`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：展示积分余额、可兑换商品和兑换记录
|
||||
- 主要依赖组件：`G01`
|
||||
- 页面目标：展示顾客当前积分余额、积分可兑换内容和历史兑换结果，回答“我的积分能干什么”
|
||||
- 主要依赖组件：`G01`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 积分余额头部区
|
||||
2. 积分摘要头部区
|
||||
3. Tab 切换区
|
||||
4. 兑换商品列表区 / 兑换记录区
|
||||
5. 规则说明入口区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 积分余额头部区
|
||||
- 展示当前积分余额
|
||||
- 展示积分获取说明入口（可选）
|
||||
### 2.1 积分摘要头部区
|
||||
|
||||
- 这一块先回答顾客“我现在有多少积分”
|
||||
- 至少展示：
|
||||
- 当前积分余额
|
||||
- 积分获取方式摘要
|
||||
- 积分获取方式只做轻说明，例如：
|
||||
- 消费赠分
|
||||
- 评价赠分
|
||||
- 注册赠分
|
||||
- 签到赠分
|
||||
- 当前不把积分规则展开成复杂任务中心
|
||||
|
||||
### 2.2 Tab 切换区
|
||||
- 兑换商品
|
||||
- 兑换记录
|
||||
|
||||
- 页面主结构建议分成两个视图：
|
||||
- 可兑换
|
||||
- 兑换记录
|
||||
- 这样可以把“现在能换什么”和“已经换过什么”分开表达，减少页面拥挤
|
||||
|
||||
### 2.3 兑换商品列表区
|
||||
- 商品卡展示：
|
||||
|
||||
- 这一块承接后台真实商品模型
|
||||
- 可兑换内容可包括：
|
||||
- 券兑换
|
||||
- 商品兑换
|
||||
- 实物兑换
|
||||
- 每张兑换卡至少展示：
|
||||
- 商品图片
|
||||
- 商品名称
|
||||
- 兑换类型
|
||||
- 所需积分
|
||||
- 库存 / 数量说明
|
||||
- 立即兑换
|
||||
- 库存或限购提示
|
||||
- 兑换按钮
|
||||
- 如果后端支持混合兑换 `points / mixed`，页面可以承接结果展示
|
||||
- 页面重点是帮助顾客理解兑换成本和兑换对象，不展开后台核销逻辑
|
||||
|
||||
### 2.4 兑换记录区
|
||||
- 展示兑换时间、兑换内容、状态
|
||||
|
||||
- 这一块承接顾客历史兑换结果
|
||||
- 至少展示：
|
||||
- 兑换时间
|
||||
- 兑换内容
|
||||
- 积分消耗
|
||||
- 当前状态
|
||||
- 如后端后续补充核销方式、核销备注等结果字段，可作为记录详情补充展示
|
||||
- 当前不把商家侧核销动作前置给顾客
|
||||
|
||||
### 2.5 规则说明入口区
|
||||
|
||||
- 这一块只做轻量规则说明或跳转入口
|
||||
- 可说明：
|
||||
- 积分如何获得
|
||||
- 积分有效期
|
||||
- 兑换后如何查看结果
|
||||
- 不把后台通知渠道配置、营销推送配置写成顾客可操作项
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 默认态：有商品可兑
|
||||
- 空态：暂无可兑换商品
|
||||
### 默认态
|
||||
|
||||
## 4. 实现备注
|
||||
- 有可兑换商品时，重点展示积分余额和兑换列表
|
||||
- 让顾客快速理解“我现在可以换什么”
|
||||
|
||||
- 积分商城强调“积分能干什么”，不要只展示数值
|
||||
### 商品空态
|
||||
|
||||
- 当暂无可兑换商品时，使用 `G03`
|
||||
- 可以保留积分余额和规则说明入口
|
||||
- 不因为商品为空就让整个积分页失效
|
||||
|
||||
### 记录空态
|
||||
|
||||
- 当顾客还没有兑换记录时，显示轻空态说明
|
||||
- 不伪造历史记录
|
||||
|
||||
### 未登录态
|
||||
|
||||
- 积分商城属于顾客资产页
|
||||
- 未登录时应先引导登录 / 授权，再查看积分和兑换记录
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残积分数据
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 商家侧核销动作
|
||||
- 通知渠道设置项
|
||||
- 订单结算积分抵扣总入口
|
||||
- 复杂积分任务体系页
|
||||
- 顾客自定义消息提醒配置
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“积分余额、积分商品、兑换记录”，还不足以把其他扩展能力写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P13` 的重点是“积分余额 + 可兑换内容 + 兑换记录”
|
||||
- 页面应该让顾客清楚知道：
|
||||
- 我有多少积分
|
||||
- 积分能换什么
|
||||
- 我换过什么
|
||||
- 不要把积分商城反向扩成积分任务大厅、消息配置页或结算抵扣总入口
|
||||
|
||||
|
||||
@@ -2,43 +2,101 @@
|
||||
|
||||
- 页面编码：`P14`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：展示储值余额、充值方案和充值记录
|
||||
- 主要依赖组件：`G01`、`G44`
|
||||
- 页面目标：展示顾客当前储值资产，支持选择充值方案、发起充值，并回看充值记录
|
||||
- 主要依赖组件：`G01`、`G44`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 储值余额区
|
||||
2. 储值资产摘要区
|
||||
3. 充值方案区
|
||||
4. 充值记录区
|
||||
5. 底部支付区
|
||||
5. 底部提交区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 储值余额区
|
||||
- 展示当前可用余额
|
||||
- 可补充说明实充与赠送余额（如有）
|
||||
### 2.1 储值资产摘要区
|
||||
|
||||
- 这一块先回答顾客“我现在还有多少储值余额”
|
||||
- 至少展示：
|
||||
- 总储值余额
|
||||
- 实充余额
|
||||
- 赠送余额
|
||||
- 这样可以避免顾客把余额来源和可用结构混在一起理解
|
||||
- 当前不把后台更复杂的财务记账字段直接暴露给顾客
|
||||
|
||||
### 2.2 充值方案区
|
||||
|
||||
- 使用 `G44`
|
||||
- 每张方案卡展示：
|
||||
- 这是本页最核心的操作区，负责让顾客快速比较不同充值方案
|
||||
- 每张方案卡至少展示：
|
||||
- 充值金额
|
||||
- 赠送金额
|
||||
- 到账金额
|
||||
- 如存在排序、推荐方案或活动标识，可以作为轻提示展示
|
||||
- 页面重点是帮助顾客理解“充多少、送多少、实际到账多少”
|
||||
|
||||
### 2.3 充值记录区
|
||||
- 展示最近充值记录
|
||||
- 包含：时间、支付方式、到账金额
|
||||
|
||||
### 2.4 底部支付区
|
||||
- 主按钮：立即充值
|
||||
- 这一块用于回看顾客已经发生的充值结果
|
||||
- 至少展示：
|
||||
- 充值时间
|
||||
- 支付方式
|
||||
- 到账金额
|
||||
- 如后续需要补充赠送金额、订单号等稳定字段，可在记录详情里扩展
|
||||
- 当前不把后台财务流水明细直接搬到顾客页
|
||||
|
||||
### 2.4 底部提交区
|
||||
|
||||
- 主按钮：`立即充值`
|
||||
- 页面只保留一个明确主动作，不扩展成复杂收银台
|
||||
- 发起充值后，具体前台支付方式应以后续充值支付契约为准
|
||||
- 当前明确不直接镜像后台交易记录中的全部支付枚举
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 默认态：有方案可选
|
||||
- 空态：暂无充值方案
|
||||
### 默认态
|
||||
|
||||
## 4. 实现备注
|
||||
- 有充值方案时，重点展示资产摘要和方案列表
|
||||
- 顾客应能快速完成方案比较和充值发起
|
||||
|
||||
- 充值金额、赠送金额、到账金额三者必须同时可见
|
||||
### 方案空态
|
||||
|
||||
- 当暂无可用充值方案时，使用 `G03`
|
||||
- 可以继续展示当前储值资产和历史充值记录
|
||||
- 不因为方案为空就隐藏整页资产信息
|
||||
|
||||
### 记录空态
|
||||
|
||||
- 当顾客还没有充值记录时，显示轻空态说明
|
||||
- 不伪造历史记录
|
||||
|
||||
### 未登录态
|
||||
|
||||
- 储值充值页属于顾客资产页
|
||||
- 未登录时应先引导登录 / 授权，再查看余额和充值方案
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残余额信息和方案数据
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 把后台 `alipay / cash / card / balance / wechat` 直接作为小程序前台支付方式列表
|
||||
- 复杂财务流水明细页
|
||||
- 自动续充或周期充值能力
|
||||
- 充值优惠叠加到复杂营销任务体系
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“余额、方案、记录”，还不足以把更多支付和财务扩展写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P14` 的重点是“余额看清楚、方案比明白、充值发得起、记录回得去”
|
||||
- 页面至少要让顾客明确看到三组数字：
|
||||
- 充值金额
|
||||
- 赠送金额
|
||||
- 到账金额
|
||||
- 前台充值支付方式需要和后台记账支付方式分层看待，不能直接把后台枚举原样搬到小程序
|
||||
|
||||
|
||||
@@ -2,37 +2,95 @@
|
||||
|
||||
- 页面编码：`P15`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：展示可购买次卡、已购次卡和核销记录
|
||||
- 主要依赖组件：`G01`、`G45`
|
||||
- 页面目标：解释当前有哪些次卡、适用什么范围、如何使用，并展示已经发生的次卡使用结果
|
||||
- 主要依赖组件：`G01`、`G45`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. Tab 切换区
|
||||
3. 次卡列表区
|
||||
2. 次卡模板区
|
||||
3. 使用记录区
|
||||
4. 规则说明区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 Tab 切换区
|
||||
- 可购买次卡
|
||||
- 我的次卡
|
||||
- 使用记录（可选）
|
||||
### 2.1 次卡模板区
|
||||
|
||||
### 2.2 次卡列表区
|
||||
- 使用 `G45`
|
||||
- 次卡卡片展示：
|
||||
- 次卡名称
|
||||
- 这一块先告诉顾客“当前有哪些次卡可以理解或选择”
|
||||
- 每张次卡卡片至少展示：
|
||||
- 卡名称
|
||||
- 售价
|
||||
- 次数
|
||||
- 适用范围
|
||||
- 有效期
|
||||
- 剩余次数 / 总次数
|
||||
- 购买或查看详情按钮
|
||||
- 如业务已支持购买入口，可在卡片上保留购买动作
|
||||
- 页面重点是把适用范围和核心规则讲清楚，而不是把实例系统写满
|
||||
|
||||
### 2.2 使用记录区
|
||||
|
||||
- 这一块承接顾客已经发生的次卡使用结果
|
||||
- 至少展示：
|
||||
- 使用商品
|
||||
- 使用时间
|
||||
- 剩余次数
|
||||
- 补差金额
|
||||
- 这一区块帮助顾客回看次卡实际怎么被使用，而不是做商家核销工作台
|
||||
|
||||
### 2.3 规则说明区
|
||||
|
||||
- 这一块用于解释次卡的基本使用规则
|
||||
- 可说明：
|
||||
- 适用商品或适用品类
|
||||
- 有效期规则
|
||||
- 是否需要补差
|
||||
- 当前只说明顾客侧能理解的使用规则
|
||||
- 不把商家侧后台配置细项原样暴露给顾客
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 默认态：有可购或已购次卡
|
||||
- 空态：暂无次卡
|
||||
### 默认态
|
||||
|
||||
## 4. 实现备注
|
||||
- 有次卡模板或使用记录时，优先展示模板说明和已发生记录
|
||||
- 页面重心是帮助顾客理解“怎么买、怎么用、用到了哪里”
|
||||
|
||||
- 次卡页需要把“适用什么商品”和“还剩几次”表达清楚
|
||||
### 模板空态
|
||||
|
||||
- 当暂无次卡模板时，使用 `G03`
|
||||
- 可以继续保留使用记录区，避免整页失效
|
||||
|
||||
### 记录空态
|
||||
|
||||
- 当顾客还没有次卡使用记录时，显示轻空态说明
|
||||
- 不伪造剩余次数和历史实例数据
|
||||
|
||||
### 未登录态
|
||||
|
||||
- 次卡页属于顾客资产页
|
||||
- 未登录时应先引导登录 / 授权，再查看正式次卡信息
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残次卡信息
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 我的次卡实例完整列表
|
||||
- 次卡转赠流程
|
||||
- 次卡退款流程
|
||||
- 购买后的实例详情页
|
||||
- 复杂核销操作页
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“模板信息和使用结果”，还不足以把完整实例体系写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P15` 的重点是“次卡是什么、适用什么、怎么用过”
|
||||
- 页面至少要把三件事说清楚：
|
||||
- 可选次卡有哪些
|
||||
- 这些次卡适用什么范围
|
||||
- 我已经发生过哪些使用结果
|
||||
- 不要把 `P15` 误写成完整的“我的次卡资产总账”或商家核销后台
|
||||
|
||||
|
||||
@@ -2,38 +2,68 @@
|
||||
|
||||
- 页面编码：`P16`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：集中查看订单消息、营销消息和系统通知
|
||||
- 主要依赖组件：`G01`、`G46`
|
||||
- 页面目标：保留顾客消息收件中心的页面职责，用于未来承接订单、营销和系统消息
|
||||
- 主要依赖组件：`G01`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 消息分类切换区
|
||||
3. 消息列表区
|
||||
2. 消息内容区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 消息分类切换区
|
||||
- 全部
|
||||
- 订单消息
|
||||
- 营销消息
|
||||
- 系统通知
|
||||
### 2.1 消息内容区
|
||||
|
||||
### 2.2 消息列表区
|
||||
- 使用 `G46`
|
||||
- 每条消息展示：
|
||||
- 标题
|
||||
- 摘要
|
||||
- 时间
|
||||
- 未读状态
|
||||
- 点击消息跳转到对应业务页面
|
||||
- 这一块的页面职责可以保留，用于未来承接顾客收到的：
|
||||
- 订单消息
|
||||
- 营销消息
|
||||
- 系统消息
|
||||
- 但在当前冻结范围内，只确认“消息中心页应存在”
|
||||
- 不把以下内容写成已经稳定的正式能力：
|
||||
- 完整消息分类切换
|
||||
- 顾客消息列表字段模型
|
||||
- 未读 / 已读状态
|
||||
- 消息点击后的跳转规则
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 默认态：有消息
|
||||
- 空态：暂无消息
|
||||
### 预留态
|
||||
|
||||
## 4. 实现备注
|
||||
- 当前阶段，这一页更像信息架构预留页
|
||||
- 页面职责是保住“顾客收消息”这个入口位置，而不是强行定义一套未经证实的 inbox 结构
|
||||
|
||||
- 消息要支持按读写状态区分，但不需要复杂会话系统
|
||||
### 空态
|
||||
|
||||
- 如当前没有可展示消息内容，使用 `G03`
|
||||
- 可提示顾客暂无消息
|
||||
- 不伪造消息分类、未读数和历史消息数据
|
||||
|
||||
### 未登录态
|
||||
|
||||
- 消息中心属于顾客本人服务页
|
||||
- 未登录时应先引导登录 / 授权，再查看正式消息内容
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残消息结构
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 完整消息分类 Tab
|
||||
- 未读 / 已读状态流转
|
||||
- 消息点击跳转规则
|
||||
- 消息角标数量
|
||||
- 顾客消息列表字段结构
|
||||
- 把后台 `message-reach` 的发送状态、阅读率、转化率直接展示给顾客
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“运营发送中心”，还不足以把顾客收件中心写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P16` 当前是保留页面职责，不是冻结完整消息产品
|
||||
- 最重要的边界只有一条：
|
||||
- 后台 `message-reach` 是发送中心，不是顾客消息中心
|
||||
- 后续如果补齐顾客侧消息契约，可以在当前页面职责下继续扩展，不需要重新改信息架构定位
|
||||
|
||||
|
||||
@@ -2,43 +2,74 @@
|
||||
|
||||
- 页面编码：`P17`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：承接常见问题、规则说明和客服联系
|
||||
- 主要依赖组件：`G01`
|
||||
- 页面目标：作为顾客服务兜底页，承接常见问题、基础规则说明和后续服务引导
|
||||
- 主要依赖组件：`G01`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 常见问题区
|
||||
3. 专题帮助区
|
||||
4. 联系客服区
|
||||
2. 帮助内容区
|
||||
3. 服务引导区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 常见问题区
|
||||
- 以折叠列表形式展示
|
||||
- 建议覆盖：
|
||||
- 如何下单
|
||||
- 如何使用优惠券
|
||||
- 如何申请退款
|
||||
- 如何查看取餐码
|
||||
### 2.1 帮助内容区
|
||||
|
||||
### 2.2 专题帮助区
|
||||
- 支付帮助
|
||||
- 配送帮助
|
||||
- 自提帮助
|
||||
- 堂食帮助
|
||||
- 会员与资产帮助
|
||||
- 这一块用于承接顾客常见问题和基础规则说明
|
||||
- 可覆盖的帮助主题包括：
|
||||
- 下单相关
|
||||
- 支付相关
|
||||
- 售后相关
|
||||
- 自提 / 堂食相关
|
||||
- 会员与资产相关
|
||||
- 当前页面只保留“帮助内容可以存在”这一职责
|
||||
- 不把以下内容写成已经稳定的后台动态能力：
|
||||
- 完整 FAQ 分类体系
|
||||
- 帮助文章 CMS
|
||||
- 后台动态配置的专题帮助内容
|
||||
|
||||
### 2.3 联系客服区
|
||||
- 在线客服入口
|
||||
- 电话客服入口
|
||||
### 2.2 服务引导区
|
||||
|
||||
- 当顾客未能从帮助内容中解决问题时，这一块负责继续导向服务兜底能力
|
||||
- 可保留：
|
||||
- 联系平台说明
|
||||
- 查看相关业务页入口
|
||||
- 当前不把完整在线客服、电话客服、工单系统写成后台已证实能力
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 默认态即可
|
||||
- 若帮助内容为空，则展示联系客服入口
|
||||
### 默认态
|
||||
|
||||
## 4. 实现备注
|
||||
- 有帮助内容时，页面承担轻量解释和服务兜底角色
|
||||
- 页面重点是降低顾客找答案的成本，不是做复杂内容平台
|
||||
|
||||
- 帮助中心主要作为兜底服务页，不需要复杂交互
|
||||
### 内容空态
|
||||
|
||||
- 当暂无可展示帮助内容时，使用 `G03`
|
||||
- 可保留基础服务引导区
|
||||
- 不伪造帮助分类和文章数据
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残帮助内容
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 完整 FAQ 后台配置体系
|
||||
- 帮助文章 CMS
|
||||
- 在线客服系统
|
||||
- 电话客服配置
|
||||
- 工单流转系统
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源还不足以把帮助中心写成完整动态服务产品。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P17` 当前是服务兜底页，不是内容运营后台的前台镜像
|
||||
- 页面重点只有两件事：
|
||||
- 帮助顾客快速找到基础说明
|
||||
- 在说明不足时给出合理的后续服务引导
|
||||
- 不要因为想把页面做满，就假设后台已经具备完整 FAQ / 客服 / CMS 契约
|
||||
|
||||
|
||||
@@ -2,46 +2,91 @@
|
||||
|
||||
- 页面编码：`P18`
|
||||
- 页面层级：`二级页`
|
||||
- 页面目标：在扫码后确认门店与桌号，并把用户送入堂食点餐页
|
||||
- 主要依赖组件：`G01`、`G12`
|
||||
- 页面目标：确认扫码得到的门店、区域和桌号是否有效，并把顾客送进堂食点餐上下文
|
||||
- 主要依赖组件：`G01`、`G12`、`G03`、`G04`
|
||||
- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md` 回写
|
||||
|
||||
## 1. 页面结构（从上到下）
|
||||
|
||||
1. 顶部导航栏
|
||||
2. 扫码结果确认卡
|
||||
3. 堂食规则说明区
|
||||
4. 当前桌台状态区（可选）
|
||||
5. 主操作区
|
||||
2. 扫码结果确认区
|
||||
3. 场景说明区
|
||||
4. 主操作区
|
||||
|
||||
## 2. 区块说明
|
||||
|
||||
### 2.1 扫码结果确认卡
|
||||
- 展示：
|
||||
### 2.1 扫码结果确认区
|
||||
|
||||
- 这一块先回答顾客“我扫到的是哪一家店、哪一张桌”
|
||||
- 至少展示：
|
||||
- 门店名称
|
||||
- 桌号 / 桌台编号
|
||||
- 是否可点餐
|
||||
- 区域信息
|
||||
- 桌号
|
||||
- 桌位状态是否可用
|
||||
- 堂食是否开启
|
||||
- 这一块的重点是校验当前扫码上下文是否成立，而不是展示复杂堂食规则
|
||||
|
||||
### 2.2 堂食规则说明区
|
||||
- 展示：
|
||||
- 是否先付款
|
||||
- 是否支持加菜
|
||||
- 是否支持合单
|
||||
- 结账方式说明
|
||||
### 2.2 场景说明区
|
||||
|
||||
### 2.3 当前桌台状态区
|
||||
- 如已有订单，可提示当前桌存在进行中订单
|
||||
- 这一块只做必要的轻说明，帮助顾客理解接下来会进入堂食点餐上下文
|
||||
- 可说明：
|
||||
- 当前点餐门店
|
||||
- 当前桌位信息
|
||||
- 入桌后的点餐提示
|
||||
- 当前不把复杂堂食规则整块堆进本页
|
||||
|
||||
### 2.4 主操作区
|
||||
- 主按钮：进入堂食点餐
|
||||
- 次按钮：重新扫码 / 切换桌号（如需要）
|
||||
### 2.3 主操作区
|
||||
|
||||
- 当扫码结果有效时：
|
||||
- 主按钮：`进入堂食点餐`
|
||||
- 当扫码结果无效或桌位不可用时，应给出明确兜底动作：
|
||||
- 重新扫码
|
||||
- 联系门店
|
||||
- 页面不需要顾客二次输入复杂信息，应优先自动确认扫码上下文
|
||||
|
||||
## 3. 页面状态
|
||||
|
||||
- 正常可入桌
|
||||
- 桌号失效
|
||||
- 当前桌不可用
|
||||
### 正常可入桌态
|
||||
|
||||
## 4. 实现备注
|
||||
- 明确展示门店、区域、桌号和可入桌状态
|
||||
- 主动作收敛为进入堂食点餐
|
||||
|
||||
- 该页要尽量减少用户输入，优先自动确认门店和桌号
|
||||
### 桌位不可用态
|
||||
|
||||
- 明确提示当前桌位不可继续入桌
|
||||
- 提供重新扫码或联系门店的兜底动作
|
||||
|
||||
### 堂食未开启态
|
||||
|
||||
- 明确提示当前门店暂不支持堂食扫码入桌
|
||||
- 不让顾客继续进入错误堂食上下文
|
||||
|
||||
### 码失效态
|
||||
|
||||
- 明确提示当前二维码无效或已失效
|
||||
- 提供重新扫码入口
|
||||
|
||||
### 加载失败态
|
||||
|
||||
- 使用 `G04`
|
||||
- 支持重试，不展示半残门店和桌号信息
|
||||
|
||||
## 4. 当前明确不冻结的能力
|
||||
|
||||
- 先付款规则说明
|
||||
- 合单规则说明
|
||||
- 继续加菜规则说明
|
||||
- 完整当前桌进行中订单详情
|
||||
- 顾客手动切换桌号流程
|
||||
|
||||
这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“堂食开关、桌位、扫码入桌上下文”，还不足以把更多堂食扩展规则写成正式前台契约。
|
||||
|
||||
## 5. 实现备注
|
||||
|
||||
- `P18` 的重点是“扫码上下文确认成功，再进堂食点餐”
|
||||
- 页面应该优先回答顾客三个问题：
|
||||
- 我扫到的是哪家店
|
||||
- 我现在对应哪张桌
|
||||
- 这张桌现在能不能点餐
|
||||
- 不要把堂食扫码确认页扩写成堂食规则大全或订单处理页
|
||||
|
||||
|
||||
@@ -1,46 +1,54 @@
|
||||
# 全周期版本规划与范围分层
|
||||
|
||||
- 文档版本：`V1.0`
|
||||
- 基线日期：`2026-03-16`
|
||||
- 适用项目：`TakeoutSaaS` 小程序 C 端
|
||||
- 文档目标：基于现有租户后台能力与 C 端页面规格，定义小程序从原型期到成熟期的完整版本路径
|
||||
- 文档目标：基于当前已冻结页面职责和当前正式仓库基线，定义小程序从当前阶段到后续成熟阶段的版本路径。
|
||||
|
||||
---
|
||||
|
||||
## 1. 文档目的
|
||||
## 1. 这份文档现在解决什么问题
|
||||
|
||||
本文件不再只回答“一期先做什么”，而是回答以下 3 个问题：
|
||||
本文件回答 4 个问题：
|
||||
|
||||
1. 小程序 C 端全周期应该按什么节奏推进
|
||||
2. 每个版本解决什么用户问题、承接什么后台能力
|
||||
3. 哪些能力属于当前页内实现，哪些能力属于未来扩展
|
||||
1. 小程序应该分几期推进。
|
||||
2. 每一期重点解决什么顾客问题。
|
||||
3. 每一期应该前置哪些页面和能力。
|
||||
4. 哪些租户后台能力当前不应该直接前置到 C 端。
|
||||
|
||||
本文件与 `docs/05-页面清单总表.md`、`docs/09-租户后台与C端功能映射总表.md`、`docs/10-全周期研发实施顺序与交付清单.md` 配合使用。
|
||||
这份文档与以下文档配合使用：
|
||||
|
||||
- `docs/05-页面清单总表.md`
|
||||
- `docs/09-租户后台与C端功能映射总表.md`
|
||||
- `docs/10-全周期研发实施顺序与交付清单.md`
|
||||
- `docs/11-V1.0页面开发执行清单与验收标准.md`
|
||||
|
||||
---
|
||||
|
||||
## 2. 全周期总览
|
||||
|
||||
| 阶段 | 版本建议 | 阶段定位 | 核心目标 | 对应价值 |
|
||||
| 阶段 | 版本建议 | 阶段定位 | 核心目标 | 当前重点 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| G0 | 原型规划期 | 文档与原型收口 | 把页面、路由、组件、流程、业务规则定清楚 | 降低后续返工 |
|
||||
| G1 | `V1.0` 核心交易版 | 先跑通交易主闭环 | 顾客能完成选店、点餐、结算、支付、查订单 | 建立基础下单能力 |
|
||||
| G2 | `V1.1` 履约服务版 | 补全场景与售后 | 顾客能退款、评价、自提、堂食扫码点餐 | 提升服务完整度 |
|
||||
| G3 | `V2.0` 会员资产版 | 建立复购资产池 | 顾客能使用会员、优惠券、积分、储值、次卡 | 提升留存与复购 |
|
||||
| G4 | `V2.1` 营销增长版 | 做活动承接与增长 | 顾客能参与新客礼、满减、秒杀、限时折扣等活动 | 提升转化与拉新 |
|
||||
| G5 | `V3.0` 精细运营版 | 进入精细化经营 | 做消息触达、个性化推荐、服务中心、深度数据联动 | 提升 LTV 与运营效率 |
|
||||
| `G0` | 原型收口期 | 文档、规格、边界冻结 | 把页面职责、路由、规则和映射关系定清楚 | 已基本完成 |
|
||||
| `G1` | `V1.0` 交易闭环收口版 | 收口当前已注册页面和组件 | 让顾客稳定完成选店、点餐、结算、支付、查单 | 当前主阶段 |
|
||||
| `G2` | `V1.1` 履约与售后版 | 补齐支付后的服务链路 | 让顾客看懂订单进展、申请退款、完成评价 | 下一阶段 |
|
||||
| `G3` | `V2.0` 我的与资产版 | 建立长期留存资产承接 | 让顾客查看并使用会员、积分、储值、次卡 | 中期阶段 |
|
||||
| `G4` | `V2.1` 活动导购版 | 把活动能力前置成导流页面 | 让活动真正导流到商品、购物车和结算 | 中后期阶段 |
|
||||
| `G5` | `V3.0` 服务与精细运营版 | 进入服务化和精细化经营 | 让顾客获得消息、帮助和更长期的经营体验 | 长期阶段 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 各阶段详细范围
|
||||
|
||||
## 3.1 G0 原型规划期
|
||||
## 3.1 `G0` 原型收口期
|
||||
|
||||
### 阶段目标
|
||||
- 完成 C 端页面地图、交互流、页面规格、业务规则与组件清单
|
||||
- 对齐租户后台已有能力与 C 端承接关系
|
||||
- 为后续 UI 设计、开发实现、接口对接提供统一母文档
|
||||
|
||||
### 当前应交付内容
|
||||
- 收口页面地图、业务规则、页面规格、组件清单和后台映射关系。
|
||||
- 统一哪些能力要前置到 C 端，哪些能力不前置。
|
||||
|
||||
### 核心交付
|
||||
|
||||
- `docs/01-文档导航与实施顺序.md`
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
@@ -48,217 +56,301 @@
|
||||
- `docs/05-页面清单总表.md`
|
||||
- `docs/06-通用组件清单.md`
|
||||
- `docs/07-页面规格/`
|
||||
- `docs/08-10` 规划类文档
|
||||
- `docs/08-11` 规划和执行文档
|
||||
- `docs/12-租户管理员功能重构梳理/`
|
||||
|
||||
### 阶段完成标准
|
||||
- 产品、设计、开发对页面范围与先后顺序没有歧义
|
||||
- 每个页面都有明确入口、出口和状态要求
|
||||
- 页面与后台能力关系可追溯
|
||||
### 完成标准
|
||||
|
||||
- 页面职责和版本边界已经明确。
|
||||
- 设计、开发、测试对“先做什么、后做什么”没有歧义。
|
||||
|
||||
---
|
||||
|
||||
## 3.2 G1 `V1.0` 核心交易版
|
||||
## 3.2 `G1` `V1.0` 交易闭环收口版
|
||||
|
||||
### 阶段定位
|
||||
先做“顾客下单主闭环”，目标不是一次做全，而是先把最核心的交易能力跑通。
|
||||
|
||||
### 目标用户问题
|
||||
- 顾客能否快速找到门店并进入正确点餐场景
|
||||
- 顾客能否快速选品、加购、结算、支付
|
||||
- 顾客付款后能否看到自己的订单和状态
|
||||
当前正式仓库已经有 10 个页面路由和 2 个关键抽屉组件，不再是“从零起页”的阶段。
|
||||
这一期的重点是把当前已存在页面和组件，对齐到新的冻结规格，形成稳定交易闭环。
|
||||
|
||||
### 重点解决的问题
|
||||
|
||||
- 顾客能不能进入正确门店和正确场景。
|
||||
- 顾客能不能稳定完成加购、结算和支付。
|
||||
- 顾客支付后能不能找到订单和下一步操作。
|
||||
|
||||
### 版本范围
|
||||
|
||||
#### 核心页面
|
||||
- `T01 首页`
|
||||
- `T02 点餐页`
|
||||
- `T03 订单页`
|
||||
- `T04 我的页（基础版）`
|
||||
- `C01 商品详情抽屉`
|
||||
- `C02 购物车抽屉`
|
||||
- `P03 结算确认页`
|
||||
- `P04 支付成功页`
|
||||
- `P05 订单详情页`
|
||||
- `P18 堂食扫码确认页`
|
||||
#### 必须收口的页面与组件
|
||||
|
||||
#### 必要支撑页
|
||||
- `P01 门店选择页（轻量版）`
|
||||
- `P02 地址管理页（基础版）`
|
||||
- `P01` 门店选择页
|
||||
- `P18` 堂食扫码确认页
|
||||
- `P02` 地址管理页
|
||||
- `T02` 点餐页
|
||||
- `C01` 商品详情抽屉
|
||||
- `C02` 购物车抽屉
|
||||
- `P03` 结算确认页
|
||||
- `P04` 支付成功页
|
||||
- `T03` 订单页
|
||||
- `P05` 订单详情页
|
||||
- `T01` 首页
|
||||
- `T04` 我的页
|
||||
|
||||
#### 核心能力
|
||||
- 门店选择与场景切换
|
||||
- 商品分类浏览与商品详情选择
|
||||
- 规格、加料、数量联动
|
||||
- 购物车与金额汇总
|
||||
- 结算页金额明细展示
|
||||
- 微信支付占位与支付成功回流
|
||||
- 订单列表、订单详情、基础状态表达
|
||||
|
||||
### 本阶段不追求
|
||||
- 完整会员资产闭环
|
||||
- 全部营销会场与复杂优惠组合
|
||||
- 售后评价全部细节
|
||||
- 精细化消息与推荐系统
|
||||
- 门店和场景上下文前置。
|
||||
- 渠道和场景驱动的菜单浏览。
|
||||
- 简单商品直接加购，复杂商品走规格或组合选择。
|
||||
- 购物车编辑与结算入口。
|
||||
- 结算页中手动资产与自动优惠分开展示。
|
||||
- 支付成功页、订单页、订单详情页形成结果承接闭环。
|
||||
- 首页与我的页形成聚合和导流能力。
|
||||
|
||||
### 当前必须守住的边界
|
||||
|
||||
- 首页是导流页，不是固定八宫格活动页，不是资产目录页。
|
||||
- 点餐页类目和商品必须跟随场景、渠道和门店能力。
|
||||
- 结算页手动资产当前只确认：
|
||||
- 优惠券
|
||||
- 余额
|
||||
- 次卡
|
||||
- 自动优惠当前只确认结果展示：
|
||||
- 满减
|
||||
- 新客优惠
|
||||
- 会员折扣
|
||||
- 免配送费
|
||||
- `积分抵扣` 当前不作为已冻结结算能力。
|
||||
- 当前支付方式页面表达只冻结：
|
||||
- 微信支付
|
||||
- 余额支付
|
||||
- 订单页和详情页使用顾客语言，不使用商家后台看板语言。
|
||||
|
||||
### 本阶段不做
|
||||
|
||||
- 退款、评价的完整页面闭环。
|
||||
- 领券中心、秒杀、限时折扣等独立活动页。
|
||||
- 会员、积分、储值、次卡等完整资产页。
|
||||
- 完整消息中心和帮助中心能力。
|
||||
|
||||
### 成功标准
|
||||
- 顾客可以从首页进入交易链路并形成订单
|
||||
- 外卖、自提、堂食 3 种场景至少完成基础差异表达
|
||||
- 下单后可在订单页和订单详情页找到订单
|
||||
|
||||
- 顾客可稳定完成 `选店 -> 点餐 -> 结算 -> 支付 -> 查单`。
|
||||
- 外卖 / 自提 / 堂食 3 种场景完成基础差异表达。
|
||||
- 当前仓库注册页面与冻结规格基本对齐。
|
||||
|
||||
---
|
||||
|
||||
## 3.3 G2 `V1.1` 履约服务版
|
||||
## 3.3 `G2` `V1.1` 履约与售后版
|
||||
|
||||
### 阶段定位
|
||||
在 `V1.0` 基础上，把履约透明度与售后能力补齐，让小程序具备完整服务体验。
|
||||
|
||||
在交易闭环稳定后，补齐支付后的订单进展、售后和评价体验。
|
||||
|
||||
### 版本范围
|
||||
- `P06 退款申请页`
|
||||
- `P07 退款详情页`
|
||||
- `P08 评价页`
|
||||
- 回补 `T03 订单页`
|
||||
- 回补 `P05 订单详情页`
|
||||
|
||||
- 回补 `T03` 订单页
|
||||
- 回补 `P05` 订单详情页
|
||||
- `P06` 退款申请页
|
||||
- `P07` 退款详情页
|
||||
- `P08` 评价页
|
||||
|
||||
### 核心能力
|
||||
- 待支付继续支付 / 取消订单
|
||||
- 订单履约时间轴
|
||||
- 外卖配送、自提取餐码、堂食桌号展示
|
||||
- 退款申请、退款状态查询
|
||||
- 订单评价、匿名评价、晒图评价
|
||||
- 再来一单入口
|
||||
|
||||
- 顾客视角订单状态表达。
|
||||
- 更完整的履约时间轴。
|
||||
- 最小退款申请和退款结果查询。
|
||||
- 最小评价提交闭环。
|
||||
- 再来一单等回流动作。
|
||||
|
||||
### 当前必须守住的边界
|
||||
|
||||
- 不把商家后台履约动作直接搬到顾客端。
|
||||
- `催单 / 骑手轨迹 / 取餐码` 不提前写成所有版本固定必做按钮。
|
||||
- 评价页先做最小闭环，不叠加复杂运营玩法。
|
||||
|
||||
### 成功标准
|
||||
- 顾客知道订单当前走到哪一步
|
||||
- 顾客能看见退款入口、处理进度和结果
|
||||
- 已完成订单能评价，评价后能回流到订单或复购场景
|
||||
|
||||
- 顾客知道订单走到哪一步。
|
||||
- 顾客知道售后在哪里、结果怎么看。
|
||||
- 支付后体验不再只停在订单列表的最小展示层。
|
||||
|
||||
---
|
||||
|
||||
## 3.4 G3 `V2.0` 会员资产版
|
||||
## 3.4 `G3` `V2.0` 我的与资产版
|
||||
|
||||
### 阶段定位
|
||||
从“做完订单”升级到“让顾客愿意回来”，建立用户资产和长期关系。
|
||||
|
||||
从“完成一次交易”升级到“形成复购和留存承接”。
|
||||
|
||||
### 版本范围
|
||||
- `T04 我的页（完整版）`
|
||||
- `P09 领券中心页`
|
||||
- `P12 会员中心页`
|
||||
- `P13 积分商城页`
|
||||
- `P14 储值充值页`
|
||||
- `P15 次卡页`
|
||||
|
||||
- 回补 `T04` 我的页完整版
|
||||
- `P12` 会员中心页
|
||||
- `P13` 积分商城页
|
||||
- `P14` 储值充值页
|
||||
- `P15` 次卡页
|
||||
|
||||
### 核心能力
|
||||
- 展示会员等级、成长值、权益、会员日信息
|
||||
- 展示并领取优惠券
|
||||
- 展示积分余额、积分获取与兑换能力
|
||||
- 展示储值方案、充值记录、余额支付入口
|
||||
- 展示次卡购买、核销、剩余次数
|
||||
- 让资产在结算页有实际承接入口
|
||||
|
||||
- 我的页承接身份、资产、服务和复购入口。
|
||||
- 展示会员等级、权益说明和成长信息。
|
||||
- 展示积分余额、兑换内容和兑换记录。
|
||||
- 展示余额、充值方案和充值结果。
|
||||
- 展示次卡说明、购买结果和使用结果。
|
||||
|
||||
### 当前必须守住的边界
|
||||
|
||||
- 我的页是聚合页，不是资产真源页。
|
||||
- 不把不稳定数量字段写成强依赖。
|
||||
- 不把积分商城反向扩成结算页积分抵扣主入口。
|
||||
|
||||
### 成功标准
|
||||
- “我的”页不再只是资料页，而是复购与留存中心
|
||||
- 顾客能理解自己拥有哪些资产、如何使用这些资产
|
||||
- 会员资产与结算页面存在清晰闭环
|
||||
|
||||
- 顾客能理解自己拥有哪些资产。
|
||||
- 资产页能回流到交易链路，而不是只做静态展示。
|
||||
- 我的页形成稳定的身份和复购聚合中心。
|
||||
|
||||
---
|
||||
|
||||
## 3.5 G4 `V2.1` 营销增长版
|
||||
## 3.5 `G4` `V2.1` 活动导购版
|
||||
|
||||
### 阶段定位
|
||||
从“顾客可复购”升级到“商家可持续做增长”，让后台营销能力在前台有承接页和转化路径。
|
||||
|
||||
让后台营销能力在顾客端形成真正的活动导流页，而不是孤立展示。
|
||||
|
||||
### 版本范围
|
||||
- `P10 秒杀活动页`
|
||||
- `P11 限时折扣活动页`
|
||||
- 回补首页活动区与点餐页活动承接
|
||||
- 回补领券中心与结算优惠展示
|
||||
- 接入新客有礼、满减活动、活动日历类运营能力
|
||||
|
||||
- 回补首页动态活动区
|
||||
- 回补点餐页活动摘要和活动价表达
|
||||
- 回补结算页自动优惠命中说明
|
||||
- `P09` 领券中心页
|
||||
- `P10` 秒杀活动页
|
||||
- `P11` 限时折扣活动页
|
||||
|
||||
### 核心能力
|
||||
- 新客礼包导流
|
||||
- 满减自动命中与说明
|
||||
- 秒杀会场与倒计时表达
|
||||
- 限时折扣专区与商品承接
|
||||
- 首页 Banner、活动宫格、专题入口
|
||||
- 老客复购推荐、最近下单商品推荐
|
||||
|
||||
- 券模板聚合和领取导流。
|
||||
- 秒杀会场和倒计时表达。
|
||||
- 限时折扣会场和活动商品承接。
|
||||
- 首页、点餐页、结算页形成活动结果闭环。
|
||||
|
||||
### 当前必须守住的边界
|
||||
|
||||
- 当前值得独立页面承接的活动只冻结为：
|
||||
- 领券中心
|
||||
- 秒杀活动
|
||||
- 限时折扣活动
|
||||
- 满减和新客优惠主要在结果区表达，不先扩成重页面。
|
||||
- 活动页不能绕开标准交易主链路。
|
||||
|
||||
### 成功标准
|
||||
- 商家配置的营销活动能在 C 端被顾客感知并参与
|
||||
- 活动不只是“展示”，而是能引导进店、加购、结算和支付
|
||||
|
||||
- 顾客能在活动页完成导流，不是停留在静态会场。
|
||||
- 商家配置的活动能真实影响加购、结算和支付。
|
||||
|
||||
---
|
||||
|
||||
## 3.6 G5 `V3.0` 精细运营版
|
||||
## 3.6 `G5` `V3.0` 服务与精细运营版
|
||||
|
||||
### 阶段定位
|
||||
从“有交易、有增长”升级到“有精细化经营能力”，让 C 端不仅承接交易，也承接服务和用户经营。
|
||||
|
||||
### 建议范围
|
||||
- `P16 消息中心页`
|
||||
- `P17 帮助中心页`
|
||||
- 回补首页个性化推荐与用户画像相关模块
|
||||
- 回补“我的”页服务区、消息区、客服区
|
||||
- 规划未来扩展：发票、客服、投诉、电子会员码、常购清单、个性化券包
|
||||
在交易、售后、资产和活动都稳定后，进入服务化和精细化经营阶段。
|
||||
|
||||
### 版本范围
|
||||
|
||||
- `P16` 消息中心页
|
||||
- `P17` 帮助中心页
|
||||
- 回补我的页服务区
|
||||
- 回补首页和我的页的个性化推荐模块
|
||||
- 预留未来扩展入口：
|
||||
- 发票
|
||||
- 客服
|
||||
- 投诉建议
|
||||
- 个性化券包
|
||||
|
||||
### 核心能力
|
||||
- 订单消息、营销消息、系统通知的聚合触达
|
||||
- FAQ、客服、售后帮助、自助指引
|
||||
- 基于顾客历史订单和会员标签的商品推荐
|
||||
- 基于活动日历与用户标签的个性化营销承接
|
||||
- 为未来 CRM、财务票据、顾客洞察留前台入口
|
||||
|
||||
- 订单消息、营销消息、系统通知的页面职责承接。
|
||||
- FAQ、售后帮助、服务兜底入口。
|
||||
- 基于顾客历史和标签的推荐与经营模块。
|
||||
|
||||
### 当前必须守住的边界
|
||||
|
||||
- `消息中心页` 当前是职责页，不默认等于成熟的完整 inbox。
|
||||
- `帮助中心页` 当前是服务兜底页，不默认等于成熟的 FAQ CMS 或客服系统。
|
||||
- `发票` 当前更适合作为未来从订单详情页扩出的能力，不在前几期抢主线。
|
||||
|
||||
### 成功标准
|
||||
- 小程序从“下单工具”升级为“用户经营载体”
|
||||
- 顾客在 C 端能获取服务、消息、活动、资产、订单等全维度体验
|
||||
|
||||
- 小程序不只是下单工具，也能承担服务和长期经营入口。
|
||||
- 顾客在 C 端能找到消息、帮助和个性化服务承接。
|
||||
|
||||
---
|
||||
|
||||
## 4. 全周期能力分层
|
||||
|
||||
| 能力域 | 说明 | 主要版本 |
|
||||
| 能力域 | 主要内容 | 主要版本 |
|
||||
| --- | --- | --- |
|
||||
| 交易域 | 选店、点餐、购物车、结算、支付、订单 | `V1.0` |
|
||||
| 履约域 | 配送、自提、堂食、时间轴、退款、评价 | `V1.1` |
|
||||
| 资产域 | 会员、优惠券、积分、储值、次卡 | `V2.0` |
|
||||
| 增长域 | 新客礼、满减、秒杀、限时折扣、复购推荐 | `V2.1` |
|
||||
| 服务域 | 消息、帮助、客服、服务入口 | `V3.0` |
|
||||
| 经营域 | 个性化推荐、顾客标签、票据与更多增值能力 | `V3.0+` |
|
||||
| 交易域 | 选店、场景切换、点餐、购物车、结算、支付、查单 | `V1.0` |
|
||||
| 履约售后域 | 订单进展、退款、评价、结果说明 | `V1.1` |
|
||||
| 资产域 | 会员、积分、储值、次卡、我的聚合 | `V2.0` |
|
||||
| 增长域 | 领券、秒杀、限时折扣、活动导流 | `V2.1` |
|
||||
| 服务域 | 消息、帮助、服务入口、个性化承接 | `V3.0` |
|
||||
|
||||
---
|
||||
|
||||
## 5. 各版本之间的依赖关系
|
||||
## 5. 明确不前置到 C 端的后台能力
|
||||
|
||||
1. `V1.0` 是所有后续版本的底座，没有交易闭环，后续资产和营销没有承接意义
|
||||
2. `V1.1` 解决“下单后怎么办”，否则订单体验不完整
|
||||
3. `V2.0` 解决“顾客为什么愿意回来”，是复购的基础
|
||||
4. `V2.1` 解决“商家如何主动做增长”，是运营放大的关键
|
||||
5. `V3.0` 解决“如何长期经营顾客关系”，是品牌化和精细运营的关键
|
||||
以下能力当前属于租户后台的经营支撑能力，不应该直接推导成顾客端页面：
|
||||
|
||||
- CRM、顾客分析、客户分群
|
||||
- 财务概览、结算、报表、成本分析
|
||||
- 商家经营看板、驾驶舱、数据总览
|
||||
- 后台消息触达中心本身
|
||||
- 后台 FAQ CMS、本地客服系统本身
|
||||
|
||||
这些能力的关系是：
|
||||
|
||||
- 可以支撑 C 端页面展示结果。
|
||||
- 但不直接等于 C 端要做一个同名页面。
|
||||
|
||||
---
|
||||
|
||||
## 6. 推荐落地原则
|
||||
## 6. 版本依赖关系
|
||||
|
||||
### 6.1 不要按页面数量推进，要按闭环推进
|
||||
- 优先级不取决于页面多不多，而取决于是否能形成业务闭环
|
||||
|
||||
### 6.2 不要把所有后台能力一次前置到 C 端
|
||||
- 后台配置能力很多，但前台承接必须按用户价值和转化优先级上线
|
||||
|
||||
### 6.3 每个版本都要有明确“上线后可验证的结果”
|
||||
- `V1.0` 看下单成功率与订单可见性
|
||||
- `V1.1` 看退款与评价路径是否清晰
|
||||
- `V2.0` 看资产使用率与复购率
|
||||
- `V2.1` 看活动参与率与转化率
|
||||
- `V3.0` 看消息触达率、留存和用户活跃度
|
||||
1. `V1.0` 没有稳定交易闭环，后续资产和活动没有承接意义。
|
||||
2. `V1.1` 没有履约和售后，交易体验是不完整的。
|
||||
3. `V2.0` 没有资产承接，复购和留存没有抓手。
|
||||
4. `V2.1` 没有活动导流，后台营销能力很难在顾客端转化。
|
||||
5. `V3.0` 没有服务和精细运营，C 端很难成为长期经营入口。
|
||||
|
||||
---
|
||||
|
||||
## 7. 与现有文档的关系
|
||||
## 7. 当前推荐落地原则
|
||||
|
||||
- `docs/02-信息架构与路由.md` 负责定义“页面怎么挂”
|
||||
- `docs/03-全局业务规则.md` 负责定义“业务怎么跑”
|
||||
- `docs/04-核心用户流程.md` 负责定义“顾客怎么走”
|
||||
- `docs/05-页面清单总表.md` 负责定义“有哪些页面”
|
||||
- `docs/08` 负责定义“整个项目分几期做”
|
||||
- `docs/09` 负责定义“后台能力如何映射到 C 端”
|
||||
- `docs/10` 负责定义“研发实施时先做什么、交付什么”
|
||||
### 7.1 按闭环推进，不按页面数量推进
|
||||
|
||||
- 优先级取决于是否能形成完整顾客闭环。
|
||||
|
||||
### 7.2 先收口当前已存在页面，再扩新页面
|
||||
|
||||
- 当前正式仓库已经有基础页面，不应继续用“未实现很多页面”的思路推进。
|
||||
|
||||
### 7.3 先冻结边界，再扩复杂能力
|
||||
|
||||
- 先把当前顾客真正会遇到的页面做稳定。
|
||||
- 再扩资产、活动、服务等中后期能力。
|
||||
|
||||
---
|
||||
|
||||
## 8. 当前结论
|
||||
|
||||
当前阶段不是“继续发散页面”，而是：
|
||||
|
||||
1. 完成 `V1.0` 当前注册页面和组件的规格收口。
|
||||
2. 再进入 `V1.1` 的订单履约与售后。
|
||||
3. 然后依次推进 `V2.0 / V2.1 / V3.0`。
|
||||
|
||||
一句话说清楚：
|
||||
|
||||
这套小程序的版本路径应该是 `先把交易主闭环做稳，再补订单后链路，再做资产，再做活动，最后做服务与精细运营`。
|
||||
|
||||
@@ -2,76 +2,103 @@
|
||||
|
||||
- 文档版本：`V1.0`
|
||||
- 适用项目：`TakeoutSaaS` 租户后台 / 小程序 C 端
|
||||
- 文档目标：把租户后台现有模块，按“直接承接 / 间接支撑 / 未来扩展”映射到 C 端小程序
|
||||
- 文档目标：把租户后台真实业务域，按“直接承接 / 间接支撑 / 未来扩展 / 明确不前置”映射到 C 端小程序
|
||||
|
||||
---
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
租户后台回答的是“商家如何配置与运营”，C 端回答的是“顾客如何感知与使用这些配置”。
|
||||
租户后台回答的是“商家如何配置与运营”，C 端回答的是“顾客如何感知、选择和完成任务”。
|
||||
|
||||
因此，本文件的作用是：
|
||||
|
||||
1. 明确后台每个模块对 C 端的影响范围
|
||||
2. 明确哪些能力应该直接前置给顾客
|
||||
3. 明确哪些能力只作为 C 端背后的数据或配置支撑
|
||||
4. 为接口对接、页面设计、版本规划提供统一映射依据
|
||||
1. 明确后台每个业务域对 C 端到底有没有直接顾客价值
|
||||
2. 明确哪些能力应直接前置到页面、入口或状态表达
|
||||
3. 明确哪些能力只作为 C 端背后的规则、排序和结果支撑
|
||||
4. 避免把后台菜单机械映射成前台页面
|
||||
|
||||
---
|
||||
|
||||
## 2. 映射原则
|
||||
|
||||
### 2.1 直接承接
|
||||
后台能力在 C 端有明确页面、入口或状态表达，例如：门店营业时间、商品规格、订单状态、优惠券。
|
||||
|
||||
后台能力在 C 端有明确页面、入口、状态或结果表达，例如：
|
||||
|
||||
- 门店可服务性
|
||||
- 商品规格
|
||||
- 订单状态
|
||||
- 会员权益
|
||||
- 秒杀会场
|
||||
|
||||
### 2.2 间接支撑
|
||||
后台能力不会单独出现在 C 端页面上，但会影响推荐、展示、状态或运营策略，例如：顾客画像、财务结算报表。
|
||||
|
||||
后台能力不会独立出现在 C 端页面上，但会影响排序、推荐、资格判断、结果展示或运营节奏，例如：
|
||||
|
||||
- 客户画像
|
||||
- 营销日历
|
||||
- 交易流水记账结构
|
||||
|
||||
### 2.3 未来扩展
|
||||
当前文档未单独建设对应页面，但未来可规划 C 端能力，例如：电子发票、客服工单、精细化标签券包。
|
||||
|
||||
当前不进入正式主链路，但未来存在较自然的顾客动作闭环，例如：
|
||||
|
||||
- 订单详情里的电子发票入口
|
||||
|
||||
### 2.4 明确不前置
|
||||
|
||||
后台能力属于商家经营、财务管理、驾驶舱或 CRM 语言，不应该直接翻译成顾客页面，例如：
|
||||
|
||||
- 财务概览
|
||||
- 到账查询
|
||||
- 成本分析
|
||||
- 顾客版 Dashboard
|
||||
|
||||
---
|
||||
|
||||
## 3. 总映射矩阵
|
||||
## 3. 当前冻结总矩阵
|
||||
|
||||
| 后台域 | 后台能力 | C 端承接页面 / 组件 | 承接方式 | 主要版本 | 说明 |
|
||||
| 后台域 | 后台能力 | C 端承接页面 / 组件 | 承接方式 | 当前结论 | 说明 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 商户域 | 商户中心、品牌设置 | 首页、我的、帮助中心 | 间接支撑 | `V1.0` / `V3.0` | 影响品牌名、Logo、门店说明、客服电话、品牌文案 |
|
||||
| 门店域 | 门店列表 | 首页、门店选择页、点餐页头部 | 直接承接 | `V1.0` | 顾客必须先选门店再点餐 |
|
||||
| 门店域 | 营业时间 | 首页、门店卡、点餐页、订单页 | 直接承接 | `V1.0` | 影响营业中、休息中、即将打烊等状态 |
|
||||
| 门店域 | 配送设置 | 首页、结算页、地址选择 | 直接承接 | `V1.0` | 影响配送范围、起送门槛、配送方式 |
|
||||
| 门店域 | 自提设置 | 首页、结算页、订单详情 | 直接承接 | `V1.0` / `V1.1` | 影响自提时间、取餐说明、取餐规则 |
|
||||
| 门店域 | 费用设置 | 商品详情、结算页 | 直接承接 | `V1.0` | 影响打包费、餐具费、配送费、起送价 |
|
||||
| 门店域 | 堂食管理 | 堂食扫码确认页、点餐页、订单详情 | 直接承接 | `V1.0` / `V1.1` | 影响桌号、堂食规则、是否可加菜 |
|
||||
| 门店域 | 员工排班 | 订单时效、帮助中心说明 | 间接支撑 | `V1.1` / `V3.0` | 不单独前置，但影响顾客对服务时效感知 |
|
||||
| 商品域 | 商品列表 | 点餐页、首页推荐区 | 直接承接 | `V1.0` | 形成点餐主列表 |
|
||||
| 商品域 | 分类管理 | 点餐页左侧分类 / 顶部分类 | 直接承接 | `V1.0` | 决定菜单组织方式 |
|
||||
| 商品域 | 规格做法 | 商品详情抽屉 | 直接承接 | `V1.0` | 决定 SKU 价格与库存表现 |
|
||||
| 商品域 | 加料管理 | 商品详情抽屉 | 直接承接 | `V1.0` | 决定加料项、价格变化 |
|
||||
| 商品域 | 商品标签 | 首页推荐卡、商品卡片、详情抽屉 | 直接承接 | `V1.0` / `V2.1` | 热销、新品、招牌等标签直接影响转化 |
|
||||
| 商品域 | 时段供应 | 点餐页、商品详情抽屉 | 直接承接 | `V1.0` | 决定商品是否可售 |
|
||||
| 商品域 | 批量工具 | 无独立 C 端页面 | 间接支撑 | - | 只影响商家运营效率，不前置给顾客 |
|
||||
| 订单域 | 订单大厅 | 订单页、订单详情页 | 直接承接 | `V1.0` / `V1.1` | C 端看到的是顾客维度订单状态表达 |
|
||||
| 订单域 | 全部订单 | 订单页、订单搜索、订单详情 | 直接承接 | `V1.0` | 承接顾客找单、查单、继续支付 |
|
||||
| 营销域 | 优惠券 | 领券中心、结算页优惠选择、我的页资产摘要 | 直接承接 | `V2.0` | 领券与用券是资产与增长的共同入口 |
|
||||
| 营销域 | 满减活动 | 首页活动入口、结算页自动命中 | 直接承接 | `V2.1` | 顾客未必单独配置，但必须感知结果 |
|
||||
| 营销域 | 新客有礼 | 首页新客入口、结算页自动带入 | 直接承接 | `V2.1` | 新用户拉新核心抓手 |
|
||||
| 营销域 | 秒杀 | 秒杀活动页、首页会场、点餐页商品卡 | 直接承接 | `V2.1` | 强时效型营销场景 |
|
||||
| 营销域 | 限时折扣 | 限时折扣页、首页专区、点餐页标签 | 直接承接 | `V2.1` | 影响商品展示和结算价格 |
|
||||
| 营销域 | 集点 / 打卡 | 次卡页、活动页、我的页资产区 | 直接承接 / 未来扩展 | `V2.1` / `V3.0` | 当前可先做活动表达，后续做完整任务体系 |
|
||||
| 营销域 | 营销日历 | 首页 Banner、活动日程、消息提醒 | 间接支撑 | `V2.1` / `V3.0` | 主要影响前台活动编排与触达节奏 |
|
||||
| 会员域 | 会员管理 | 我的页、会员中心页、结算页会员权益提示 | 直接承接 | `V2.0` | 顾客感知的是等级、折扣、权益 |
|
||||
| 会员域 | 积分商城 | 积分商城页、结算积分抵扣、我的页摘要 | 直接承接 | `V2.0` | 形成积分获取与消耗闭环 |
|
||||
| 会员域 | 储值卡 | 储值充值页、结算余额支付、我的页摘要 | 直接承接 | `V2.0` | 支撑充值和余额消费 |
|
||||
| 会员域 | 消息触达 | 消息中心、我的页红点、活动提醒 | 直接承接 / 间接支撑 | `V3.0` | 支撑订单消息、营销消息、系统通知 |
|
||||
| 顾客域 | 顾客列表 | 无独立顾客页 | 间接支撑 | `V3.0` | 主要服务后台运营和标签管理 |
|
||||
| 顾客域 | 顾客画像 | 首页推荐、复购推荐、券包推荐 | 间接支撑 | `V3.0` | 不直接给顾客看“画像”，但会影响推荐结果 |
|
||||
| 顾客域 | 顾客分析 | 首页个性化、我的页推荐服务 | 间接支撑 | `V3.0` | 作为精细化运营的推荐输入 |
|
||||
| 财务域 | 财务概览 | 无直接前台页 | 间接支撑 | - | 服务后台经营分析，不直接前置 |
|
||||
| 财务域 | 交易流水 | 订单金额、余额记录、储值记录 | 间接支撑 | `V2.0` / `V3.0` | 顾客可见的是“订单金额 / 储值记录”子集 |
|
||||
| 财务域 | 发票管理 | 订单详情未来入口 | 未来扩展 | `V3.0+` | 当前文档未建设，可作为后续增值服务 |
|
||||
| 财务域 | 成本 / 结算 / 报表 | 无直接前台页 | 间接支撑 | - | 只服务商家与平台管理 |
|
||||
| 仪表盘域 | 经营概览 | 无直接前台页 | 间接支撑 | - | 不对顾客展示，但可反哺推荐和活动策略 |
|
||||
| 商户域 | 商户中心、品牌设置 | `T01`、`T04`、`P17` | 间接支撑 | 间接支撑 | 影响品牌名、门店说明、联系信息、品牌文案 |
|
||||
| 门店域 | 门店列表 | `T01`、`P01`、`T02`头部 | 直接承接 | 直接承接 | 顾客必须在正确门店与场景下开始交易 |
|
||||
| 门店域 | 营业时间 | `T01`、`P01`、`T02`、`P03` | 直接承接 | 直接承接 | 影响营业中、休息中、可预约时段 |
|
||||
| 门店域 | 配送设置 | `P01`、`P02`、`P03`、`T01`摘要 | 直接承接 | 直接承接 | 影响配送范围、起送门槛、配送费、预计送达 |
|
||||
| 门店域 | 自提设置 | `T01`摘要、`P03`、`P05` | 直接承接 | 直接承接 | 影响最早可约时段、同日自提等规则结果 |
|
||||
| 门店域 | 费用设置 | `C02`、`P03`、`P05` | 直接承接 | 直接承接 | 只承接顾客可理解的费用项 |
|
||||
| 门店域 | 堂食管理 | `P18`、`T02`头部、`P03`、`P05` | 直接承接 | 直接承接 | 只承接堂食开关、桌号、入桌上下文，不扩成复杂堂食规则页 |
|
||||
| 门店域 | 员工排班 | 无独立前台页 | 间接支撑 | 间接支撑 | 只影响忙闲感知和 ETA，不前置页面 |
|
||||
| 商品域 | 商品列表 | `T02`、`T01`推荐区 | 直接承接 | 直接承接 | 形成点餐主列表 |
|
||||
| 商品域 | 分类管理 | `T02` | 直接承接 | 直接承接 | 分类必须按当前场景过滤 |
|
||||
| 商品域 | 规格做法 | `C01` | 直接承接 | 直接承接 | 决定 SKU、价格、库存表现 |
|
||||
| 商品域 | 加料管理 | `C01` | 直接承接 | 直接承接 | 决定加料项和价格变化 |
|
||||
| 商品域 | 商品标签 | `T01`推荐卡、`T02`商品卡、`C01` | 直接承接 | 直接承接 | 热销、新品、招牌等标签直接影响转化 |
|
||||
| 商品域 | 时段供应 | `T02`、`C01`、`C02` | 直接承接 | 直接承接 | 决定商品是否可售 |
|
||||
| 商品域 | 批量工具 | 无独立前台页 | 间接支撑 | 间接支撑 | 只影响后台运营效率 |
|
||||
| 订单域 | 全部订单 / 订单详情 | `T03`、`P05` | 直接承接 | 直接承接 | C 端必须翻译成顾客任务语言，不复用商家看板口径 |
|
||||
| 订单域 | 履约结果 | `T03`、`P05` | 直接承接 | 直接承接 | 承接商家处理中、制作中、配送中、待取餐等结果表达 |
|
||||
| 订单域 | 退款结果 | `P06`、`P07`、`P05`摘要 | 直接承接 | 直接承接 | 当前以最小申请页和结果页为主 |
|
||||
| 订单域 | 评价图片上传 | `P08` | 直接承接 | 直接承接 | 当前只冻结最小评价闭环 |
|
||||
| 营销域 | 优惠券模板 | `P09`、`T01`活动位、`T04`入口、`P03` | 直接承接 | 直接承接 | 当前承接的是券模板聚合，不是顾客完整券包 |
|
||||
| 营销域 | 满减活动 | `T02`活动摘要、`P03`自动命中、`T01`轻摘要 | 直接承接 | 结果直承接 | 强感知、弱页面，不独立成页 |
|
||||
| 营销域 | 新客有礼 | `T01`资格入口、`P03`自动命中 | 直接承接 | 结果直承接 | 强资格、弱会场，分享链路未冻结 |
|
||||
| 营销域 | 秒杀 | `P10`、`T01`、`T02` | 直接承接 | 直接承接 | 强时效活动会场，仍回到标准交易主链路 |
|
||||
| 营销域 | 限时折扣 | `P11`、`T01`、`T02` | 直接承接 | 直接承接 | 强调折扣和时间窗口，仍回到标准交易主链路 |
|
||||
| 营销域 | 次卡模板 / 打卡 | `P15`、`T04`入口、`P03`次卡选择 | 直接承接 | 有限直接承接 | 当前重点是模板说明和使用结果，不夸大完整实例体系 |
|
||||
| 营销域 | 营销日历 | 无独立前台页 | 间接支撑 | 间接支撑 | 主要影响首页活动编排和提醒节奏 |
|
||||
| 会员域 | 会员管理 / 等级权益 | `T04`、`P12`、`P03`权益提示 | 直接承接 | 直接承接 | 顾客感知的是等级、权益和已享受结果 |
|
||||
| 会员域 | 积分商城 | `P13`、`T04`摘要 | 直接承接 | 直接承接 | 当前承接积分余额、可兑换内容、兑换记录 |
|
||||
| 会员域 | 积分规则 | `P13`、`P08`成功提示 | 直接承接 | 直接承接 | 主要承接获取和兑换，不冻结订单积分抵扣 |
|
||||
| 会员域 | 储值卡 | `P14`、`T04`摘要、`P03`余额支付 | 直接承接 | 直接承接 | 充值方案、余额和记录都可前置，但支付方式要收敛 |
|
||||
| 会员域 | 消息触达 | `P16`来源层、活动提醒 | 间接支撑 | 间接支撑 | 后台是发送中心，不等于顾客消息中心 |
|
||||
| 顾客域 | 顾客列表 | 无独立前台页 | 间接支撑 | 间接支撑 | 仅服务后台运营和标签管理 |
|
||||
| 顾客域 | 顾客画像 | `T01`、`T02`、`T04`复购区 | 间接支撑 | 间接支撑 | 影响推荐排序，不直接显示画像概念 |
|
||||
| 顾客域 | 顾客分析 | 无独立前台页 | 间接支撑 | 间接支撑 | 影响活动定向和推荐策略 |
|
||||
| 财务域 | 财务概览 | 无直接前台页 | 明确不前置 | 不前置 | 属于后台经营驾驶舱 |
|
||||
| 财务域 | 交易流水 | `P05`、`P07`、`P14`、`P13`结果子集 | 间接支撑 | 间接支撑 | 只抽取顾客能理解的订单、退款、充值、积分结果 |
|
||||
| 财务域 | 发票管理 | `P05` 未来扩展位 | 未来扩展 | 未来扩展 | 最自然入口是订单详情页，不做独立财务中心 |
|
||||
| 财务域 | 到账查询 / 结算 / 报表 / 成本 | 无直接前台页 | 明确不前置 | 不前置 | 只服务商家经营与财务管理 |
|
||||
| 仪表盘域 | 工作台 / 分析页 | 无直接前台页 | 明确不前置 | 不前置 | 当前不能作为小程序设计事实源 |
|
||||
|
||||
---
|
||||
|
||||
@@ -80,6 +107,7 @@
|
||||
## 4.1 商户与门店域
|
||||
|
||||
### 后台来源
|
||||
|
||||
- 商户中心
|
||||
- 门店列表
|
||||
- 营业时间
|
||||
@@ -89,24 +117,28 @@
|
||||
- 堂食管理
|
||||
|
||||
### C 端主要承接点
|
||||
|
||||
- `T01 首页`
|
||||
- `T02 点餐页`
|
||||
- `T02 点餐页`头部
|
||||
- `P01 门店选择页`
|
||||
- `P02 地址管理页`
|
||||
- `P03 结算确认页`
|
||||
- `P05 订单详情页`
|
||||
- `P18 堂食扫码确认页`
|
||||
|
||||
### 说明
|
||||
- 这是 C 端最基础的配置域
|
||||
- 没有门店域能力，商品、订单、营销都无法成立
|
||||
- 该域直接决定三场景差异：`delivery`、`pickup`、`dine_in`
|
||||
### 当前结论
|
||||
|
||||
- 门店域是 C 端主链路前提，必须先于商品、订单和活动成立
|
||||
- 首页和点餐页的场景切换必须跟随门店真实 `serviceTypes`
|
||||
- 地址可配送性必须前置，不允许拖到支付前才提示
|
||||
- 堂食页当前只承接扫码入桌上下文，不承接先付款、合单、加菜等未证实规则
|
||||
|
||||
---
|
||||
|
||||
## 4.2 商品域
|
||||
|
||||
### 后台来源
|
||||
|
||||
- 商品列表
|
||||
- 分类管理
|
||||
- 规格做法
|
||||
@@ -115,132 +147,179 @@
|
||||
- 时段供应
|
||||
|
||||
### C 端主要承接点
|
||||
|
||||
- `T02 点餐页`
|
||||
- `C01 商品详情抽屉`
|
||||
- `C02 购物车抽屉`
|
||||
- 首页推荐区 / 活动区
|
||||
- `T01` 推荐区 / 活动商品分组
|
||||
|
||||
### 当前结论
|
||||
|
||||
### 说明
|
||||
- 商品域决定“顾客能买什么、怎么买、什么时候能买”
|
||||
- 规格、加料、标签、时段供应必须在 C 端有明确视觉反馈
|
||||
- 商品、类目和活动价展示都必须受当前场景过滤
|
||||
- 简单商品可直接加购，套餐商品必须先完成套餐组选择
|
||||
|
||||
---
|
||||
|
||||
## 4.3 订单与履约域
|
||||
## 4.3 订单、履约与售后域
|
||||
|
||||
### 后台来源
|
||||
- 订单大厅
|
||||
|
||||
- 全部订单
|
||||
- 订单状态流转
|
||||
- 订单大厅
|
||||
- 订单详情
|
||||
- 退款交易结果
|
||||
- 评价图片上传
|
||||
|
||||
### C 端主要承接点
|
||||
|
||||
- `T03 订单页`
|
||||
- `P05 订单详情页`
|
||||
- `P06 退款申请页`
|
||||
- `P07 退款详情页`
|
||||
- `P08 评价页`
|
||||
|
||||
### 说明
|
||||
- 后台关心接单、出餐、配送；C 端关心“我现在要做什么、还要等多久、能不能退款”
|
||||
- 因此，同一个订单状态，在 C 端需要翻译成顾客可理解的文案与动作按钮
|
||||
### 当前结论
|
||||
|
||||
- 后台看板和商家处理动作不直接前置给顾客
|
||||
- C 端只承接顾客可理解的状态、履约结果和售后结果
|
||||
- `催单`、`骑手轨迹`、`取餐码`、`完整消息通知闭环` 当前都不冻结为正式前台能力
|
||||
|
||||
---
|
||||
|
||||
## 4.4 营销域
|
||||
|
||||
### 后台来源
|
||||
- 优惠券
|
||||
|
||||
- 优惠券模板
|
||||
- 满减活动
|
||||
- 新客有礼
|
||||
- 秒杀
|
||||
- 限时折扣
|
||||
- 集点 / 打卡
|
||||
- 次卡模板 / 打卡
|
||||
- 营销日历
|
||||
|
||||
### C 端主要承接点
|
||||
|
||||
- `T01 首页`
|
||||
- `T02 点餐页`
|
||||
- `P09 领券中心页`
|
||||
- `P10 秒杀活动页`
|
||||
- `P11 限时折扣活动页`
|
||||
- `P03 结算确认页`
|
||||
- `T04 我的页`
|
||||
- `T04` 相关入口
|
||||
|
||||
### 说明
|
||||
- 营销域不是“独立存在”的，它必须嵌入首页、点餐、结算、我的这几个核心页面
|
||||
- 真正的设计重点不是活动页本身，而是活动如何导流到商品和支付
|
||||
### 当前结论
|
||||
|
||||
- 活动内容必须服从“当前门店 + 当前场景 + 当前资格”
|
||||
- 首页活动位必须动态化，不做固定八宫格
|
||||
- 满减和新客活动主要是规则结果展示，不独立成重页面
|
||||
- 秒杀和限时折扣都属于正式活动会场，但必须导流回标准商品、购物车、结算主链路
|
||||
- `P09` 当前只承接可见券模板，不把顾客个人券包状态写死
|
||||
|
||||
---
|
||||
|
||||
## 4.5 会员资产域
|
||||
## 4.5 会员与资产域
|
||||
|
||||
### 后台来源
|
||||
|
||||
- 会员管理
|
||||
- 会员等级体系
|
||||
- 积分商城
|
||||
- 储值卡
|
||||
- 消息触达
|
||||
|
||||
### C 端主要承接点
|
||||
|
||||
- `T04 我的页`
|
||||
- `P12 会员中心页`
|
||||
- `P13 积分商城页`
|
||||
- `P14 储值充值页`
|
||||
- `P15 次卡页`
|
||||
- `P16 消息中心页`
|
||||
- `P03 结算确认页`
|
||||
- `P16 消息中心页` 预留职责
|
||||
|
||||
### 说明
|
||||
- 会员资产域是“我的”页成为留存中心的关键
|
||||
- 所有资产页都不能只做展示，必须回流到点餐页或结算页形成使用闭环
|
||||
### 当前结论
|
||||
|
||||
- `T04` 是聚合页，不是资产真源
|
||||
- 会员中心重点是当前等级、当前权益和等级说明，不强调复杂成长进度条
|
||||
- 积分商城重点是余额、可兑换内容和兑换记录，不反向扩成订单积分抵扣总入口
|
||||
- 储值页要和后台记账支付方式分层看待，不能直接照搬后台支付枚举
|
||||
- `message-reach` 是后台发送中心，不等于顾客消息中心
|
||||
|
||||
---
|
||||
|
||||
## 4.6 顾客、财务、分析域
|
||||
## 4.6 顾客、财务与分析域
|
||||
|
||||
### 后台来源
|
||||
|
||||
- 顾客列表
|
||||
- 顾客画像
|
||||
- 顾客分析
|
||||
- 财务概览
|
||||
- 交易流水
|
||||
- 报表、结算、成本、发票
|
||||
- 发票
|
||||
- 到账查询
|
||||
- 经营报表
|
||||
- 成本管理
|
||||
- 工作台 / 分析页
|
||||
|
||||
### C 端承接方式
|
||||
- 当前以间接支撑为主
|
||||
- 未来可扩展的顾客可见能力包括：
|
||||
- 个性化推荐
|
||||
- 常购商品
|
||||
- 专属券包
|
||||
- 消费记录摘要
|
||||
- 电子发票入口
|
||||
|
||||
### 说明
|
||||
- 这部分不建议在早期版本大量前置
|
||||
- 它更适合作为 `V3.0` 之后的精细化经营能力输入源
|
||||
- 当前以间接支撑和未来扩展为主
|
||||
|
||||
### 当前结论
|
||||
|
||||
- `customer / finance / dashboard` 主要是后台运营、财务和分析层
|
||||
- 不建议新增以下正式顾客页面：
|
||||
- 客户列表页
|
||||
- 客户画像页
|
||||
- 客户分析页
|
||||
- 财务概览页
|
||||
- 交易流水总账页
|
||||
- 到账查询页
|
||||
- 成本分析页
|
||||
- 顾客版 Dashboard
|
||||
- 发票能力可以保留未来扩展位，但最自然入口是订单详情页，不单独建设财务中心
|
||||
|
||||
---
|
||||
|
||||
## 5. 当前文档范围内的直接映射优先级
|
||||
## 5. 当前直接映射优先级
|
||||
|
||||
### 第一优先级：必须先映射到 C 端
|
||||
|
||||
- 门店域
|
||||
- 商品域
|
||||
- 订单域
|
||||
|
||||
### 第二优先级：交易闭环稳定后映射
|
||||
- 会员资产域
|
||||
|
||||
- 会员与资产域
|
||||
- 核心营销域
|
||||
|
||||
### 第三优先级：后续精细化再映射
|
||||
|
||||
- 顾客分析域
|
||||
- 财务增值域
|
||||
- 更复杂的消息触达与个性化能力
|
||||
- 更复杂的消息触达和个性化能力
|
||||
|
||||
---
|
||||
|
||||
## 6. 设计与研发使用建议
|
||||
## 6. 当前明确边界
|
||||
|
||||
- `积分商城` 当前不等于“订单积分抵扣”正式能力
|
||||
- `message-reach` 当前不等于顾客消息中心
|
||||
- `满减 / 新客有礼` 当前主要是结果展示，不是重页面
|
||||
- `营销日历` 当前不是顾客活动日历页
|
||||
- `customer / finance / dashboard` 当前默认不前置成顾客页面
|
||||
- `dashboard` 当前不作为小程序设计事实源
|
||||
|
||||
---
|
||||
|
||||
## 7. 设计与研发使用建议
|
||||
|
||||
1. 做页面设计时，不要只看后台菜单名，要先判断顾客是否真的有任务价值。
|
||||
2. 做接口对接时，不要把后台对象原封不动搬到前台，要翻译成顾客任务语言。
|
||||
3. 做版本规划时，优先上线影响下单、履约、复购和活动转化的映射项。
|
||||
4. 如果某个后台能力当前没有自然顾客动作闭环，就先归为“间接支撑”或“未来扩展”，不要强行造前台页面。
|
||||
|
||||
1. 做页面设计时，不要只看后台名称，要看顾客是否真的需要感知这个能力
|
||||
2. 做接口对接时，不要把后台对象原封不动搬到前台，要翻译成顾客任务语言
|
||||
3. 做版本规划时，优先上线能影响下单、履约、复购的映射项
|
||||
4. 如果某个后台能力当前没有对应的顾客价值，就先作为支撑能力，不强行做前台页面
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
- 文档版本：`V1.0`
|
||||
- 适用项目：`TakeoutSaaS` 小程序 C 端
|
||||
- 文档目标：给设计、前端、接口、测试一个统一的落地顺序，避免“页面很多但不知道先做什么”
|
||||
- 文档目标：给设计、前端、接口、测试一个统一的落地顺序，避免“页面很多但阶段混乱、边界失控”
|
||||
|
||||
---
|
||||
|
||||
@@ -12,8 +12,8 @@
|
||||
|
||||
1. 全周期应该按什么实施顺序推进
|
||||
2. 每一阶段需要产出什么交付物
|
||||
3. 每一阶段达到什么标准才算可以进入下一阶段
|
||||
4. 如果是 AI 或个人开发，也能按什么顺序稳步落地
|
||||
3. 每一阶段达到什么标准，才算可以进入下一阶段
|
||||
4. 如何让实现顺序和当前已经冻结的页面职责保持一致
|
||||
|
||||
---
|
||||
|
||||
@@ -21,216 +21,304 @@
|
||||
|
||||
| 阶段 | 名称 | 主要目标 | 核心交付 |
|
||||
| --- | --- | --- | --- |
|
||||
| S0 | 范围收口 | 定边界、定版本、定文档母版 | 08/09/10 规划文档、页面优先级 |
|
||||
| S1 | 信息架构与设计基线 | 定路由、定组件、定设计规则 | 低保真、组件清单、状态矩阵 |
|
||||
| S2 | 交易主链路开发 | 跑通首页到支付成功 | 首页、点餐、抽屉、结算、订单 |
|
||||
| S3 | 履约与售后开发 | 补齐订单服务链路 | 退款、评价、状态时间轴 |
|
||||
| S4 | 我的与资产开发 | 形成复购资产闭环 | 会员、积分、储值、次卡、领券 |
|
||||
| S5 | 增长与活动开发 | 把营销能力前置到顾客端 | 秒杀、折扣、新客礼、活动入口 |
|
||||
| S6 | 服务与消息开发 | 补齐服务能力和长期经营能力 | 消息、帮助、推荐、服务区 |
|
||||
| S7 | 联调验收与上线准备 | 全局走查和交付 | 联调清单、验收清单、演示脚本 |
|
||||
| `S0` | 范围收口 | 定边界、定版本、定母版文档 | `08 / 09 / 10` 规划文档、页面优先级 |
|
||||
| `S1` | 信息架构与设计基线 | 定路由、定组件、定状态与场景差异 | 路由、低保真、状态矩阵、组件清单 |
|
||||
| `S2` | 交易主链路开发 | 跑通选店、点餐、结算、支付主闭环 | 首页、门店、点餐、抽屉、结算、支付成功 |
|
||||
| `S3` | 履约与售后开发 | 补齐订单后半段体验 | 订单页、订单详情、退款、评价 |
|
||||
| `S4` | 我的与资产开发 | 形成身份、资产、复购聚合闭环 | 我的、会员、积分、储值、次卡 |
|
||||
| `S5` | 活动导购开发 | 把活动导流能力前置到顾客端 | 领券、秒杀、限时折扣、首页活动位 |
|
||||
| `S6` | 服务与预留补位 | 补齐服务兜底和预留职责页 | 帮助中心、消息中心职责页、服务入口 |
|
||||
| `S7` | 联调验收与上线准备 | 全局走查、联调和上线准备 | 联调清单、验收清单、演示脚本 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 各阶段实施顺序
|
||||
|
||||
## 3.1 S0 范围收口
|
||||
## 3.1 `S0` 范围收口
|
||||
|
||||
### 目标
|
||||
- 把“要做什么”和“先做什么”收口
|
||||
|
||||
- 把“本期做什么、不做什么、先做什么”收口
|
||||
|
||||
### 必做事项
|
||||
1. 确认版本分期：`V1.0` / `V1.1` / `V2.0` / `V2.1` / `V3.0`
|
||||
2. 确认页面优先级：P0 / P1 / P2
|
||||
3. 确认三场景：外卖 / 自提 / 堂食
|
||||
4. 确认后台到前台映射关系
|
||||
|
||||
1. 确认版本分期：`V1.0 / V1.1 / V2.0 / V2.1 / V3.0`
|
||||
2. 确认页面优先级：`P0 / P1 / P2`
|
||||
3. 确认三场景：`delivery / pickup / dine_in`
|
||||
4. 确认后台到前台的功能映射层级：
|
||||
- 直接承接
|
||||
- 间接支撑
|
||||
- 未来扩展
|
||||
- 明确不前置
|
||||
|
||||
### 必交付物
|
||||
|
||||
- `docs/08-全周期版本规划与范围分层.md`
|
||||
- `docs/09-租户后台与C端功能映射总表.md`
|
||||
- `docs/10-全周期研发实施顺序与交付清单.md`
|
||||
- 页面优先级结论
|
||||
|
||||
### 完成标准
|
||||
|
||||
- 团队已明确“本期不做什么”
|
||||
- 没有人再按自己理解任意扩散页面
|
||||
- 不再有人按后台菜单数量直接推导前台页面数量
|
||||
|
||||
---
|
||||
|
||||
## 3.2 S1 信息架构与设计基线
|
||||
## 3.2 `S1` 信息架构与设计基线
|
||||
|
||||
### 目标
|
||||
- 让后续页面开发不再重复讨论结构问题
|
||||
|
||||
- 让后续页面开发不再反复讨论结构边界
|
||||
|
||||
### 必做事项
|
||||
1. 确认 4 个 Tab 与全部二级页路由
|
||||
|
||||
1. 确认 `4` 个 Tab 与全部二级页、抽屉、弹层路由
|
||||
2. 确认页面模板：Tab 页、二级页、抽屉、弹层
|
||||
3. 确认全局设计 Token：颜色、字号、间距、圆角、按钮层级
|
||||
4. 确认页面状态矩阵：默认态、空态、加载态、错误态、禁用态
|
||||
5. 确认三场景差异矩阵：外卖 / 自提 / 堂食
|
||||
3. 确认全局状态矩阵：
|
||||
- 默认态
|
||||
- 空态
|
||||
- 加载态
|
||||
- 错误态
|
||||
- 禁用态
|
||||
4. 确认三场景差异矩阵：外卖 / 自提 / 堂食
|
||||
5. 确认页面职责边界：
|
||||
- 聚合页
|
||||
- 导购页
|
||||
- 结果页
|
||||
- 预留职责页
|
||||
|
||||
### 必交付物
|
||||
|
||||
- 路由与页面层级总表
|
||||
- 页面低保真骨架
|
||||
- 全局设计基线
|
||||
- 页面状态矩阵
|
||||
- 场景差异矩阵
|
||||
- 通用组件清单的可实现版本
|
||||
- 通用组件清单
|
||||
|
||||
### 完成标准
|
||||
|
||||
- 任意页面都能用统一模板快速搭出骨架
|
||||
- 新页面设计不会脱离现有模式
|
||||
- 新页面设计不会再脱离现有模式和边界
|
||||
|
||||
---
|
||||
|
||||
## 3.3 S2 交易主链路开发
|
||||
## 3.3 `S2` 交易主链路开发
|
||||
|
||||
### 目标
|
||||
- 先跑通“选店 → 点餐 → 结算 → 支付 → 查单”
|
||||
|
||||
- 先跑通“当前门店上下文建立 → 点餐 → 结算 → 支付成功”
|
||||
|
||||
### 开发顺序
|
||||
|
||||
1. `T01 首页`
|
||||
2. `P01 门店选择页`
|
||||
3. `T02 点餐页`
|
||||
4. `C01 商品详情抽屉`
|
||||
5. `C02 购物车抽屉`
|
||||
6. `P02 地址管理页`
|
||||
7. `P03 结算确认页`
|
||||
8. `P04 支付成功页`
|
||||
9. `T03 订单页`
|
||||
10. `P05 订单详情页`
|
||||
11. `T04 我的页（基础版）`
|
||||
12. `P18 堂食扫码确认页`
|
||||
3. `P02 地址管理页`
|
||||
4. `P18 堂食扫码确认页`
|
||||
5. `T02 点餐页`
|
||||
6. `C01 商品详情抽屉`
|
||||
7. `C02 购物车抽屉`
|
||||
8. `P03 结算确认页`
|
||||
9. `P04 支付成功页`
|
||||
|
||||
### 必交付物
|
||||
- 路由可跳转的交易闭环
|
||||
- 商品与购物车 mock 数据
|
||||
- 结算金额计算占位逻辑
|
||||
- 订单状态 mock 数据
|
||||
|
||||
- 路由可跳转的交易主闭环
|
||||
- 当前门店 / 当前场景上下文闭环
|
||||
- 商品与购物车 mock 或服务层数据
|
||||
- 金额试算与结算结果占位逻辑
|
||||
- 三场景基础差异展示
|
||||
|
||||
### 验收重点
|
||||
- 能否从首页顺利进入点餐和结算
|
||||
- 能否看清价格、优惠和实付金额
|
||||
- 能否支付成功后找到订单
|
||||
|
||||
- 能否在正确门店和场景下进入点餐
|
||||
- 能否看清费用来源、优惠结果和实付金额
|
||||
- 能否从支付成功页进入正确后续动作
|
||||
|
||||
### 当前阶段必须守住的边界
|
||||
|
||||
- `P03` 手动资产当前只确认：
|
||||
- 优惠券
|
||||
- 余额
|
||||
- 次卡
|
||||
- `积分抵扣` 当前不作为已冻结结算能力
|
||||
- `C05` 支付方式当前只收敛为：
|
||||
- 微信支付
|
||||
- 余额支付
|
||||
|
||||
---
|
||||
|
||||
## 3.4 S3 履约与售后开发
|
||||
## 3.4 `S3` 履约与售后开发
|
||||
|
||||
### 目标
|
||||
- 补齐订单后半段体验
|
||||
|
||||
- 补齐支付之后的订单、履约、售后和评价体验
|
||||
|
||||
### 开发顺序
|
||||
1. 回补 `T03 订单页` 状态筛选
|
||||
2. 回补 `P05 订单详情页` 履约时间轴与操作区
|
||||
|
||||
1. `T03 订单页`
|
||||
2. `P05 订单详情页`
|
||||
3. `P06 退款申请页`
|
||||
4. `P07 退款详情页`
|
||||
5. `P08 评价页`
|
||||
|
||||
### 必交付物
|
||||
- 状态时间轴
|
||||
- 退款链路
|
||||
- 评价链路
|
||||
|
||||
- 顾客视角订单状态分组
|
||||
- 履约时间轴与场景信息区
|
||||
- 最小退款申请与退款结果页
|
||||
- 最小评价闭环
|
||||
- 再来一单入口
|
||||
|
||||
### 验收重点
|
||||
- 用户能否快速理解订单当前状态
|
||||
- 用户能否找到退款入口和评价入口
|
||||
|
||||
- 顾客是否能快速看懂“这单现在到哪一步了”
|
||||
- 售后入口和售后结果是否清楚
|
||||
- 评价页是否保持最小闭环，不夹带复杂运营玩法
|
||||
|
||||
### 当前阶段必须守住的边界
|
||||
|
||||
- 不把商家看板四列直接搬到订单页
|
||||
- 不把商家动作直接前置给顾客
|
||||
- 不把 `催单 / 骑手轨迹 / 取餐码` 写成固定必做按钮
|
||||
|
||||
---
|
||||
|
||||
## 3.5 S4 我的与资产开发
|
||||
## 3.5 `S4` 我的与资产开发
|
||||
|
||||
### 目标
|
||||
- 把“我的”页做成留存与复购中心
|
||||
|
||||
- 把“我的”做成身份、资产、服务、复购的聚合页
|
||||
|
||||
### 开发顺序
|
||||
1. 回补 `T04 我的页`
|
||||
|
||||
1. `T04 我的页`
|
||||
2. `P12 会员中心页`
|
||||
3. `P09 领券中心页`
|
||||
4. `P13 积分商城页`
|
||||
5. `P14 储值充值页`
|
||||
6. `P15 次卡页`
|
||||
3. `P13 积分商城页`
|
||||
4. `P14 储值充值页`
|
||||
5. `P15 次卡页`
|
||||
|
||||
### 必交付物
|
||||
- 我的页用户头部与资产摘要
|
||||
|
||||
- 我的页身份头部卡、资产摘要、订单快捷入口、服务入口、复购区
|
||||
- 会员权益表达
|
||||
- 券、积分、储值、次卡结构页
|
||||
- 与结算页联动入口
|
||||
- 积分余额、兑换内容与兑换记录
|
||||
- 储值余额、充值方案与充值记录
|
||||
- 次卡模板说明与使用结果记录
|
||||
|
||||
### 验收重点
|
||||
- 资产页是不是只“展示”没有“回流”
|
||||
- 结算页能否承接资产的使用语境
|
||||
|
||||
- `T04` 是否仍然是聚合页，而不是资产真源
|
||||
- 资产页是否能回流到交易链路，而不只是静态展示
|
||||
- 次卡和储值是否按当前证据边界表达，没有写成过满系统
|
||||
|
||||
### 当前阶段必须守住的边界
|
||||
|
||||
- 不把 `优惠券数量 / 次卡数量 / 未读消息数` 写死成首页强依赖
|
||||
- 不把积分商城反向扩成订单积分抵扣总入口
|
||||
- 不把消息中心当成已经成型的完整收件箱
|
||||
|
||||
---
|
||||
|
||||
## 3.6 S5 增长与活动开发
|
||||
## 3.6 `S5` 活动导购开发
|
||||
|
||||
### 目标
|
||||
- 把后台营销能力转化为前台可感知、可转化的页面能力
|
||||
|
||||
- 把活动能力前置为“导购页 + 导流结果”，而不是活动孤岛
|
||||
|
||||
### 开发顺序
|
||||
1. 回补首页活动区
|
||||
2. `P10 秒杀活动页`
|
||||
3. `P11 限时折扣活动页`
|
||||
4. 回补点餐页活动标签与活动商品专区
|
||||
5. 回补结算页优惠命中说明
|
||||
6. 回补我的页活动与券入口
|
||||
|
||||
1. 回补 `T01` 首页动态活动区
|
||||
2. 回补 `T02` 点餐页活动摘要和活动价表达
|
||||
3. `P09 领券中心页`
|
||||
4. `P10 秒杀活动页`
|
||||
5. `P11 限时折扣活动页`
|
||||
6. 回补 `P03` 结算页自动优惠命中说明
|
||||
|
||||
### 必交付物
|
||||
- 活动承接页
|
||||
- 活动入口与活动状态表达
|
||||
- 新客礼 / 满减 / 秒杀 / 折扣的页面承接逻辑
|
||||
|
||||
- 首页动态活动位
|
||||
- 点餐页活动条与活动价商品表达
|
||||
- 券模板聚合页
|
||||
- 秒杀活动会场
|
||||
- 限时折扣活动会场
|
||||
- 活动导流回商品和结算的链路说明
|
||||
|
||||
### 验收重点
|
||||
- 活动是否能真正导流进商品和结算，而不只是展示横幅
|
||||
|
||||
- 活动是否真正导流进商品、购物车和结算
|
||||
- `P09` 是否保持“券模板导购页”定位
|
||||
- `P10` 和 `P11` 是否明确分开，不再用一套活动页糊过去
|
||||
|
||||
### 当前阶段必须守住的边界
|
||||
|
||||
- 满减和新客活动主要做规则结果展示，不做重页面
|
||||
- 首页活动位必须动态化，不做固定八宫格
|
||||
- 活动页不能绕开标准交易主链路
|
||||
|
||||
---
|
||||
|
||||
## 3.7 S6 服务与消息开发
|
||||
## 3.7 `S6` 服务与预留补位
|
||||
|
||||
### 目标
|
||||
- 把小程序补齐为可长期经营的用户服务端
|
||||
|
||||
- 补齐服务兜底能力和当前只保留职责的预留页
|
||||
|
||||
### 开发顺序
|
||||
1. `P16 消息中心页`
|
||||
2. `P17 帮助中心页`
|
||||
3. 回补首页推荐区与我的服务区
|
||||
4. 预留未来发票、客服、投诉与个性化券包入口
|
||||
|
||||
1. `P17 帮助中心页`
|
||||
2. `P16 消息中心页`
|
||||
3. 回补 `T04` 服务入口与说明文案
|
||||
4. 预留未来发票、客服等扩展入口位
|
||||
|
||||
### 必交付物
|
||||
- 消息分类页
|
||||
- FAQ / 客服 / 帮助中心
|
||||
- 红点、未读、服务入口表达
|
||||
|
||||
- 帮助中心页
|
||||
- 消息中心职责页
|
||||
- 服务入口表达
|
||||
- 未来扩展入口位规划
|
||||
|
||||
### 验收重点
|
||||
- 顾客是否能在订单之外获得通知与帮助
|
||||
|
||||
- 顾客是否能找到基础帮助和服务兜底入口
|
||||
- 是否没有把后台发送中心、FAQ CMS、客服系统直接假定为已完整存在
|
||||
|
||||
### 当前阶段必须守住的边界
|
||||
|
||||
- `P16` 当前只保留页面职责，不冻结完整消息 inbox
|
||||
- `P17` 当前是服务兜底页，不冻结后台 FAQ / 客服动态能力
|
||||
|
||||
---
|
||||
|
||||
## 3.8 S7 联调验收与上线准备
|
||||
## 3.8 `S7` 联调验收与上线准备
|
||||
|
||||
### 目标
|
||||
|
||||
- 把前面阶段串成一套真正可演示、可交付、可联调的版本
|
||||
|
||||
### 必做事项
|
||||
|
||||
1. 检查所有页面路由跳转
|
||||
2. 检查所有主 CTA 是否闭环
|
||||
3. 检查三场景差异是否完整
|
||||
4. 检查所有金额、优惠、状态文案是否一致
|
||||
4. 检查金额、优惠、状态文案是否一致
|
||||
5. 检查登录拦截与回跳逻辑
|
||||
6. 检查空态、错误态、禁用态
|
||||
7. 整理演示脚本、验收清单、联调顺序
|
||||
7. 检查导购页是否都正确回流到交易主链路
|
||||
8. 整理演示脚本、验收清单、联调顺序
|
||||
|
||||
### 必交付物
|
||||
|
||||
- 联调清单
|
||||
- 验收清单
|
||||
- 演示路径脚本
|
||||
- 版本发布说明
|
||||
|
||||
### 完成标准
|
||||
|
||||
- 业务、设计、开发、测试都能按同一套路径演示
|
||||
- 新接手的 AI 或工程师可以快速理解全局结构
|
||||
- 新接手的 AI 或工程师可以快速理解全局结构和边界
|
||||
|
||||
---
|
||||
|
||||
@@ -238,30 +326,33 @@
|
||||
|
||||
| 阶段 | 必交付物 |
|
||||
| --- | --- |
|
||||
| S0 | 分期文档、映射文档、实施文档 |
|
||||
| S1 | 低保真、状态矩阵、场景矩阵、组件清单 |
|
||||
| S2 | 交易主链路页面、mock 数据、跳转脚本 |
|
||||
| S3 | 售后页面、状态时间轴、订单操作脚本 |
|
||||
| S4 | 我的页与资产页、资产回流脚本 |
|
||||
| S5 | 活动页、活动入口、活动承接脚本 |
|
||||
| S6 | 消息与帮助页、红点逻辑、服务入口 |
|
||||
| S7 | 联调文档、验收清单、演示说明 |
|
||||
| `S0` | 分期文档、映射文档、实施文档 |
|
||||
| `S1` | 低保真、状态矩阵、场景矩阵、组件清单 |
|
||||
| `S2` | 交易主链路页面、mock 数据、跳转脚本 |
|
||||
| `S3` | 履约售后页面、状态时间轴、订单操作脚本 |
|
||||
| `S4` | 我的页与资产页、资产回流脚本 |
|
||||
| `S5` | 活动页、活动入口、活动承接脚本 |
|
||||
| `S6` | 服务页、预留职责页、服务入口规划 |
|
||||
| `S7` | 联调文档、验收清单、演示说明 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 如果是个人或 AI 独立推进，建议这样执行
|
||||
|
||||
### 模式 A：先原型后代码
|
||||
1. 先补齐文档与低保真
|
||||
2. 再实现点击原型
|
||||
3. 再把点击原型转成真实小程序代码
|
||||
### 模式 A：先文档后代码
|
||||
|
||||
1. 先补齐文档、边界和低保真
|
||||
2. 再实现可点击原型或页面骨架
|
||||
3. 最后把原型骨架转成真实小程序代码
|
||||
|
||||
### 模式 B：边文档边代码
|
||||
|
||||
### 模式 B：边原型边代码
|
||||
1. 每完成一个页面规格，就同步搭建页面骨架
|
||||
2. 每完成一个阶段，就统一走查路由和状态
|
||||
3. 不要跨阶段跳做复杂资产或复杂营销
|
||||
2. 每完成一个阶段，就统一走查路由、状态和边界
|
||||
3. 不要跨阶段抢做复杂资产、复杂营销或分析页
|
||||
|
||||
### 模式 C：只做 MVP
|
||||
|
||||
1. 只做 `S0 + S1 + S2 + S3`
|
||||
2. 上线后再根据业务反馈扩展 `S4-S7`
|
||||
|
||||
@@ -269,39 +360,45 @@
|
||||
|
||||
## 6. 阶段切换门槛
|
||||
|
||||
### 从 S1 进入 S2 前
|
||||
### 从 `S1` 进入 `S2` 前
|
||||
|
||||
- 页面结构、路由、组件模板已稳定
|
||||
|
||||
### 从 S2 进入 S3 前
|
||||
### 从 `S2` 进入 `S3` 前
|
||||
|
||||
- 主交易闭环可完整演示
|
||||
|
||||
### 从 S3 进入 S4 前
|
||||
### 从 `S3` 进入 `S4` 前
|
||||
|
||||
- 订单与售后体验清晰，没有主流程断点
|
||||
|
||||
### 从 S4 进入 S5 前
|
||||
- 资产页能回流到结算页
|
||||
### 从 `S4` 进入 `S5` 前
|
||||
|
||||
- 资产页已能回流到交易链路
|
||||
|
||||
### 从 `S5` 进入 `S6` 前
|
||||
|
||||
### 从 S5 进入 S6 前
|
||||
- 活动页不是孤岛，已能导流到交易闭环
|
||||
|
||||
### 从 S6 进入 S7 前
|
||||
- 页面、消息、服务、活动、资产已基本成套
|
||||
### 从 `S6` 进入 `S7` 前
|
||||
|
||||
- 页面、服务、活动、资产已基本成套
|
||||
|
||||
---
|
||||
|
||||
## 7. 实施时最容易踩的坑
|
||||
|
||||
1. 一开始就想把所有资产和活动一起做完
|
||||
2. 先画很多视觉稿，却没有先收口状态和流程
|
||||
3. 把后台字段原样搬到前台，没有翻译成顾客语言
|
||||
4. 只做页面，不做版本边界
|
||||
5. 只做静态图，不做关键跳转与交互闭环
|
||||
1. 一开始就想把所有资产、活动、服务一起做完。
|
||||
2. 先画很多视觉稿，却没有先收口状态和流程。
|
||||
3. 把后台字段原样搬到前台，没有翻译成顾客语言。
|
||||
4. 把后台发送中心、财务驾驶舱、分析页直接当成前台设计来源。
|
||||
5. 只做页面，不做关键跳转与交互闭环。
|
||||
|
||||
---
|
||||
|
||||
## 8. 最终建议
|
||||
|
||||
这套项目最稳的推进方式不是“按页面一个个做”，而是：
|
||||
这套项目最稳的推进方式不是“按页面零散推进”，而是：
|
||||
|
||||
1. 先按版本收口
|
||||
2. 再按闭环推进
|
||||
@@ -309,3 +406,4 @@
|
||||
4. 最后统一联调与上线准备
|
||||
|
||||
只有这样，租户后台到 C 端小程序的关系才会清晰，整个项目也不会越做越散。
|
||||
|
||||
|
||||
500
Cend-MiniProgram-Prototype/docs/11-V1.0页面开发执行清单与验收标准.md
Normal file
500
Cend-MiniProgram-Prototype/docs/11-V1.0页面开发执行清单与验收标准.md
Normal file
@@ -0,0 +1,500 @@
|
||||
# V1.0 页面开发执行清单与验收标准
|
||||
|
||||
- 文档版本：`V1.0`
|
||||
- 基线日期：`2026-03-16`
|
||||
- 适用项目：`TakeoutSaaS` 小程序 C 端
|
||||
- 对应前端仓库：`D:\HAZCode\TakeoutSaaS\TakeoutSaaS.C-Side-Mini-Program-V1`
|
||||
- 对应原型目录：`D:\HAZCode\TakeoutSaaS\TakeoutSaaS.Prototypes\Cend-MiniProgram-Prototype`
|
||||
- 对应冻结文档：
|
||||
- `docs/05-页面清单总表.md`
|
||||
- `docs/07-页面规格`
|
||||
- `docs/09-租户后台与C端功能映射总表.md`
|
||||
- `docs/10-全周期研发实施顺序与交付清单.md`
|
||||
- 文档目标：把“当前正式仓库真实已有内容”与“当前已经冻结的新页面职责”对齐，形成可以直接拿来排开发顺序、做验收的执行版清单。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这份文档现在负责什么
|
||||
|
||||
这份文档只解决 4 件事：
|
||||
|
||||
1. 当前正式小程序仓库到底已经有了哪些页面、组件、服务和 store。
|
||||
2. 这些已有内容距离当前冻结规格还差什么。
|
||||
3. 这一轮应该按什么顺序补，不再按旧文档里的过期状态推进。
|
||||
4. 每一项补到什么程度，才算可以进入下一项。
|
||||
|
||||
这份文档不再做两类事情：
|
||||
|
||||
- 不再把“运行时是 mock 还是真接口”写死成长期结论。
|
||||
- 不再把“页面文件是否存在”和“页面职责是否完成”混成一件事。
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前正式仓库真实基线
|
||||
|
||||
本节基于以下代码现状整理：
|
||||
|
||||
- `src/app.config.ts`
|
||||
- `src/pages/**`
|
||||
- `src/components/**`
|
||||
- `src/services/mini.ts`
|
||||
- `src/stores/**`
|
||||
|
||||
### 2.1 已注册页面路由
|
||||
|
||||
当前 `src/app.config.ts` 已注册 10 个页面，说明这些页面都已经进入正式仓库，而不是“未实现”。
|
||||
|
||||
| 编码 | 页面名称 | 路由 | 当前成熟度 | 当前主要缺口 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `T01` | 首页 | `pages/home/index` | 已有业务化骨架 | 还未完全收口为“门店上下文 + 动态活动 + 推荐导流”首页 |
|
||||
| `T02` | 点餐页 | `pages/menu/index` | 主交易页最小闭环已具备 | 还需严格对齐新规格中的渠道类目、商品分流、活动摘要 |
|
||||
| `T03` | 订单页 | `pages/orders/index` | 最小订单列表已具备 | 还需改成顾客任务语言和状态动作闭环 |
|
||||
| `T04` | 我的页 | `pages/profile/index` | 已有占位和联调页能力 | 还未收口为聚合页，不应继续维持“开发说明页”形态 |
|
||||
| `P01` | 门店选择页 | `pages/store/select/index` | 最小可用 | 还缺搜索、场景过滤、不可用门店表达、最近门店表达 |
|
||||
| `P02` | 地址管理页 | `pages/address/index` | 已有最小地址表单 | 还不是完整地址列表与选择页 |
|
||||
| `P03` | 结算确认页 | `pages/trade/checkout/index` | 已有试算、校验、建单、模拟支付链路 | 还需按新规格收口场景卡、优惠结构、备注区、支付表达 |
|
||||
| `P04` | 支付成功页 | `pages/trade/success/index` | 已有最小结果页 | 还需加强订单摘要、场景差异和兜底回流 |
|
||||
| `P05` | 订单详情页 | `pages/order/detail/index` | 已有最小详情页 | 还需补齐履约时间轴、费用明细和状态动作区 |
|
||||
| `P18` | 堂食扫码确认页 | `pages/dinein/confirm/index` | 已有最小桌号确认页 | 还不是冻结后的“扫码确认页”结构 |
|
||||
|
||||
### 2.2 已存在的关键组件
|
||||
|
||||
旧文档把 `C01 / C02` 写成了“未实现”，这一点已经不准确。当前正式仓库中两者都已经存在，并且已经接入点餐页。
|
||||
|
||||
| 编码 | 组件名称 | 代码入口 | 当前成熟度 | 当前主要缺口 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `C01` | 商品详情抽屉 | `src/components/spec-popup/index.vue` | 已存在并接入点餐页 | 还需按新规格补齐商品详情信息、组合商品选择、禁选逻辑 |
|
||||
| `C02` | 购物车抽屉 | `src/components/cart-drawer/index.vue` | 已存在并接入点餐页 | 还需按新规格补齐凑单提示、优惠摘要、空态联动和结算承接 |
|
||||
|
||||
补充说明：
|
||||
|
||||
- `点餐页` 当前已经不是“只有商品列表，没有抽屉组件”的阶段。
|
||||
- 当前更准确的判断是：`已有最小组件和接入关系，但还没有完全对齐冻结规格`。
|
||||
|
||||
### 2.3 当前服务层能力
|
||||
|
||||
当前 `src/services/mini.ts` 已具备以下前端服务封装：
|
||||
|
||||
| 服务函数 | 能力说明 | 当前结论 |
|
||||
| --- | --- | --- |
|
||||
| `getMiniBootstrap()` | 启动引导、租户和场景上下文 | 已具备 |
|
||||
| `getStores()` | 门店列表 | 已具备 |
|
||||
| `getCategories()` | 类目列表 | 已具备 |
|
||||
| `getMenu()` | 菜单列表 | 已具备 |
|
||||
| `getProductDetail()` | 商品详情 | 已具备 |
|
||||
| `estimatePrice()` | 金额试算 | 已具备 |
|
||||
| `checkoutValidate()` | 结算校验 | 已具备 |
|
||||
| `createOrder()` | 创建订单 | 已具备 |
|
||||
| `mockPayOrder()` | 模拟支付 | 已具备 |
|
||||
| `getOrders()` | 订单列表 | 已具备 |
|
||||
| `getOrderDetail()` | 订单详情 | 已具备 |
|
||||
|
||||
这里要明确两个边界：
|
||||
|
||||
1. “服务函数已存在”不等于“所有后端接口都已经联真”。
|
||||
2. 本文只冻结前端 repo 的能力基线，运行时是否走 mock 以环境和后端 readiness 为准，不再写成会过期的绝对结论。
|
||||
|
||||
### 2.4 当前 store 分工
|
||||
|
||||
旧文档只写了 `appStore / cartStore`，这也已经过期。当前仓库已经有 4 个核心状态域。
|
||||
|
||||
| store | 当前职责 | 当前结论 |
|
||||
| --- | --- | --- |
|
||||
| `appStore` | 租户、门店、场景、bootstrap、全局上下文 | 已具备 |
|
||||
| `cartStore` | 购物车商品、数量、金额汇总 | 已具备 |
|
||||
| `customerStore` | 顾客基础信息，如姓名、手机号 | 已具备 |
|
||||
| `fulfillmentStore` | 履约上下文，如地址、桌号 | 已具备 |
|
||||
|
||||
当前更合理的判断不是“还没有地址和顾客状态 store”，而是：
|
||||
|
||||
- 已经有 `customerStore / fulfillmentStore` 作为最小状态承接。
|
||||
- 还没有把它们扩成完整的地址簿、身份中心、履约域模型。
|
||||
|
||||
---
|
||||
|
||||
## 3. 当前冻结结论下，必须守住的实现边界
|
||||
|
||||
这一节不是重复 `docs/07`，而是提炼成编码和验收时不能再跑偏的硬边界。
|
||||
|
||||
### 3.1 首页边界
|
||||
|
||||
- 首页是 `门店上下文 + 场景切换 + 动态导流 + 推荐承接` 页面。
|
||||
- 首页不是固定八宫格活动页。
|
||||
- 首页不是资产目录页。
|
||||
- 首页不是规则说明页。
|
||||
|
||||
### 3.2 点餐与商品边界
|
||||
|
||||
- 场景切换必须受门店 `serviceTypes` 约束，不做固定三按钮硬编码。
|
||||
- 类目展示必须跟随当前渠道和场景，不做静态类目。
|
||||
- 简单商品才允许直接加购。
|
||||
- 套餐或复杂商品必须经过规格 / 组合选择，不得直接跳过。
|
||||
|
||||
### 3.3 结算边界
|
||||
|
||||
- 结算页必须拆开：
|
||||
- `手动资产`：优惠券、余额、次卡
|
||||
- `自动优惠`：满减、新客、会员折扣、免配送费
|
||||
- `积分抵扣` 当前不是已冻结结算能力，不能先写死进主流程。
|
||||
- 当前支付方式页面表达只冻结：
|
||||
- `微信支付`
|
||||
- `余额支付`
|
||||
|
||||
### 3.4 订单与售后边界
|
||||
|
||||
- 订单页必须用顾客任务语言，而不是商家看板列名。
|
||||
- 商家操作不属于顾客端页面。
|
||||
- `催单 / 骑手轨迹 / 取餐码` 当前都不作为固定必做能力写死。
|
||||
|
||||
### 3.5 我的页与资产边界
|
||||
|
||||
- 我的页是聚合页，不是资产真源页。
|
||||
- 优惠券数、未读消息数、次卡实例数等不稳定字段不先冻结为首页级硬依赖。
|
||||
- 后台的“消息触达中心”不是顾客端“消息收件箱”。
|
||||
|
||||
### 3.6 活动与增长边界
|
||||
|
||||
- 当前值得独立页面承接的活动只冻结：
|
||||
- 领券中心
|
||||
- 秒杀活动
|
||||
- 限时折扣活动
|
||||
- 满减和新客礼更偏规则结果展示，不先做重页面。
|
||||
|
||||
---
|
||||
|
||||
## 4. 本轮执行范围
|
||||
|
||||
本轮执行范围只覆盖“当前正式仓库已注册页面 + 已接入关键组件”的收口工作。
|
||||
|
||||
### 4.1 本轮必须收口
|
||||
|
||||
- `T01` 首页
|
||||
- `T02` 点餐页
|
||||
- `T03` 订单页
|
||||
- `T04` 我的页
|
||||
- `P01` 门店选择页
|
||||
- `P02` 地址管理页
|
||||
- `P03` 结算确认页
|
||||
- `P04` 支付成功页
|
||||
- `P05` 订单详情页
|
||||
- `P18` 堂食扫码确认页
|
||||
- `C01` 商品详情抽屉
|
||||
- `C02` 购物车抽屉
|
||||
|
||||
### 4.2 本轮明确不扩
|
||||
|
||||
以下内容仍然在全周期规划内，但不应该在当前这份执行清单里抢主线：
|
||||
|
||||
- `P06` 退款申请页
|
||||
- `P07` 退款详情页
|
||||
- `P08` 评价页
|
||||
- `P09` 领券中心页
|
||||
- `P10` 秒杀活动页
|
||||
- `P11` 限时折扣活动页
|
||||
- `P12` 会员中心页
|
||||
- `P13` 积分商城页
|
||||
- `P14` 储值充值页
|
||||
- `P15` 次卡页
|
||||
- `P16` 消息中心页
|
||||
- `P17` 帮助中心页
|
||||
|
||||
这些页面不是删掉，也不是否定，而是要等当前注册页面和主交易链路先收口。
|
||||
|
||||
---
|
||||
|
||||
## 5. 推荐执行顺序
|
||||
|
||||
本轮推荐顺序不再沿用旧文档的“谁文件不存在就先做谁”，而是按依赖关系推进。
|
||||
|
||||
### 5.1 第一组：先收口上下文前置页
|
||||
|
||||
1. `P01` 门店选择页
|
||||
2. `P18` 堂食扫码确认页
|
||||
3. `P02` 地址管理页
|
||||
|
||||
原因：
|
||||
|
||||
- 顾客进入点餐和结算前，必须先把 `门店 / 场景 / 履约信息` 这三个前置上下文稳定下来。
|
||||
- 当前这三页虽然都已有最小实现，但都还没有达到冻结后的页面职责。
|
||||
|
||||
### 5.2 第二组：收口点餐与加购链路
|
||||
|
||||
1. `T02` 点餐页
|
||||
2. `C01` 商品详情抽屉
|
||||
3. `C02` 购物车抽屉
|
||||
|
||||
原因：
|
||||
|
||||
- 点餐页已经是当前仓库里最接近真实业务的主链路页面。
|
||||
- 现在更值得做的是“对齐冻结规格”，而不是重新从零搭页。
|
||||
- 商品详情抽屉和购物车抽屉已经接入点餐页，应该和 `T02` 一起收口，而不是分离推进。
|
||||
|
||||
### 5.3 第三组：收口结算与支付结果
|
||||
|
||||
1. `P03` 结算确认页
|
||||
2. `P04` 支付成功页
|
||||
|
||||
原因：
|
||||
|
||||
- 当前 repo 已经有建单和模拟支付能力。
|
||||
- 真正缺的是“页面职责表达”和“支付后承接”是否与冻结结论一致。
|
||||
|
||||
### 5.4 第四组：收口订单后链路
|
||||
|
||||
1. `T03` 订单页
|
||||
2. `P05` 订单详情页
|
||||
|
||||
原因：
|
||||
|
||||
- 订单页和详情页已经有最小能力，适合在支付闭环收口后继续精修。
|
||||
- 这一步的目标是让顾客能看懂、找得到、做得了下一步动作。
|
||||
|
||||
### 5.5 第五组：最后回补聚合页
|
||||
|
||||
1. `T01` 首页
|
||||
2. `T04` 我的页
|
||||
|
||||
原因：
|
||||
|
||||
- 首页和我的页目前都已有入口骨架，但都还不是最终职责形态。
|
||||
- 它们依赖前面几组页面的上下文、动作和可跳转目标，适合最后统一回补。
|
||||
|
||||
---
|
||||
|
||||
## 6. 逐项执行清单与验收标准
|
||||
|
||||
### 6.1 `P01` 门店选择页
|
||||
|
||||
- 当前状态：
|
||||
- 已有页面文件和最小切店能力。
|
||||
- 已能承接基础门店列表展示。
|
||||
- 本轮必须补齐：
|
||||
- 门店搜索。
|
||||
- 按当前场景或门店 `serviceTypes` 过滤 / 标记可用性。
|
||||
- 最近使用门店或定位门店的结构占位。
|
||||
- 切店后的全局上下文刷新和回跳逻辑。
|
||||
- 验收标准：
|
||||
- 切店后 `首页 / 点餐页 / 结算页` 上下文同步变化。
|
||||
- 当前场景不支持的门店不能被误选。
|
||||
- 页面具备加载态、空态、异常态。
|
||||
|
||||
### 6.2 `P18` 堂食扫码确认页
|
||||
|
||||
- 当前状态：
|
||||
- 已有最小桌号输入和保存能力。
|
||||
- 目前更像“桌号保存页”，还不是扫码确认页。
|
||||
- 本轮必须补齐：
|
||||
- 扫码结果确认卡。
|
||||
- 桌台信息区和堂食规则说明区。
|
||||
- 确认后切换场景为 `dine_in`。
|
||||
- 确认后进入点餐页，不再只是保存后返回。
|
||||
- 验收标准：
|
||||
- 有扫码参数时能正确承接。
|
||||
- 无扫码参数时有明确兜底路径。
|
||||
- 确认后点餐页进入堂食上下文。
|
||||
|
||||
### 6.3 `P02` 地址管理页
|
||||
|
||||
- 当前状态：
|
||||
- 已有最小地址表单。
|
||||
- 依赖 `customerStore + fulfillmentStore` 保存单地址信息。
|
||||
- 本轮必须补齐：
|
||||
- 地址列表态。
|
||||
- 当前选中地址态。
|
||||
- 默认地址标记。
|
||||
- 新增 / 编辑入口占位。
|
||||
- 从结算页进入、选择后返回的链路。
|
||||
- 验收标准：
|
||||
- 外卖场景可进入并带回选中地址。
|
||||
- 自提 / 堂食场景不误导进入地址选择。
|
||||
- 空地址时有明确引导。
|
||||
|
||||
### 6.4 `T02` 点餐页
|
||||
|
||||
- 当前状态：
|
||||
- 已有分类、菜单、场景切换、加购、抽屉联动等基础能力。
|
||||
- 是当前仓库最接近交易主链路完成态的页面。
|
||||
- 本轮必须补齐：
|
||||
- 类目展示严格跟随当前渠道和场景。
|
||||
- 搜索区、活动摘要区、类目高亮与吸顶表达。
|
||||
- 简单商品直接加购。
|
||||
- 复杂商品进入 `C01`，不直接跳过选择过程。
|
||||
- 底部购物车栏与 `C02` 的联动收口。
|
||||
- 验收标准：
|
||||
- 切换门店或场景后菜单和类目刷新正确。
|
||||
- 售罄商品不能误加购。
|
||||
- 页面结构与 `docs/07-页面规格/02-Tab-点餐页.md` 一致。
|
||||
|
||||
### 6.5 `C01` 商品详情抽屉
|
||||
|
||||
- 当前状态：
|
||||
- `spec-popup` 组件已存在并接入点餐页。
|
||||
- 已不是“未实现”状态。
|
||||
- 本轮必须补齐：
|
||||
- 商品图、描述、标签、销量、价格表达。
|
||||
- 规格组、做法、加料、套餐组合选择。
|
||||
- 金额实时变化。
|
||||
- 售罄、禁选、默认选中规则。
|
||||
- 复杂商品加购写入 `cartStore`。
|
||||
- 验收标准：
|
||||
- 从点餐页商品卡能稳定打开。
|
||||
- 选择项变化后金额即时刷新。
|
||||
- 关闭再打开时状态重置策略明确且一致。
|
||||
|
||||
### 6.6 `C02` 购物车抽屉
|
||||
|
||||
- 当前状态：
|
||||
- `cart-drawer` 组件已存在并接入点餐页。
|
||||
- 已具备最小购物车编辑基础。
|
||||
- 本轮必须补齐：
|
||||
- 商品行编辑、数量增减、清空动作。
|
||||
- 优惠摘要或凑单提示区。
|
||||
- 空购物车联动关闭或空态提示。
|
||||
- 去结算动作与 `P03` 的承接。
|
||||
- 验收标准：
|
||||
- 数量和金额变化实时同步。
|
||||
- 清空后底部栏和抽屉状态同步清零。
|
||||
- 无商品时不能继续进入结算。
|
||||
|
||||
### 6.7 `P03` 结算确认页
|
||||
|
||||
- 当前状态：
|
||||
- 已有金额试算、结算校验、建单、模拟支付。
|
||||
- 已具备最小闭环能力。
|
||||
- 本轮必须补齐：
|
||||
- 外卖 / 自提 / 堂食三场景差异卡片。
|
||||
- 地址区 / 自提门店区 / 堂食桌台区。
|
||||
- `手动资产` 与 `自动优惠` 分开展示。
|
||||
- 备注区和附加说明区。
|
||||
- 支付方式表达只先收口为 `微信支付 / 余额支付`。
|
||||
- 验收标准：
|
||||
- 无商品不能提交。
|
||||
- 金额明细、优惠明细、应付金额逻辑一致。
|
||||
- 不把 `积分抵扣` 先写死进主结算流程。
|
||||
|
||||
### 6.8 `P04` 支付成功页
|
||||
|
||||
- 当前状态：
|
||||
- 已有最小结果页。
|
||||
- 已支持跳订单详情、订单列表、继续点餐。
|
||||
- 本轮必须补齐：
|
||||
- 订单摘要区。
|
||||
- 场景差异信息区，如配送预计、自提提示、桌台信息。
|
||||
- 缺少订单上下文时的兜底回流。
|
||||
- 与 `P03` 的稳定跳转关系。
|
||||
- 验收标准：
|
||||
- 结算成功后稳定进入。
|
||||
- 从结果页可继续进入详情、订单页或点餐页。
|
||||
- 直接打开时不会停留在无意义空白页。
|
||||
|
||||
### 6.9 `T03` 订单页
|
||||
|
||||
- 当前状态：
|
||||
- 已有最小订单列表和状态切换基础。
|
||||
- 本轮必须补齐：
|
||||
- 顾客视角状态筛选。
|
||||
- 场景信息和核心动作区。
|
||||
- 去支付、查看详情、再来一单等动作承接。
|
||||
- 空态回流点餐页。
|
||||
- 验收标准：
|
||||
- 订单状态表达是顾客语言，不是后台列名。
|
||||
- 各卡片 CTA 与详情页动作一致。
|
||||
- 不强行冻结 `催单 / 骑手轨迹 / 取餐码`。
|
||||
|
||||
### 6.10 `P05` 订单详情页
|
||||
|
||||
- 当前状态：
|
||||
- 已有最小详情页和基础状态展示。
|
||||
- 本轮必须补齐：
|
||||
- 履约时间轴。
|
||||
- 商品清单和费用明细。
|
||||
- 基础信息区，如订单号、时间、支付方式、备注。
|
||||
- 按状态显示底部动作。
|
||||
- 验收标准：
|
||||
- 未支付、履约中、完成、关闭等状态动作不混乱。
|
||||
- 未找到订单时有空态和回流。
|
||||
- 页面结构与 `docs/07-页面规格/11-订单详情页.md` 对齐。
|
||||
|
||||
### 6.11 `T01` 首页
|
||||
|
||||
- 当前状态：
|
||||
- 已有门店上下文、场景切换、部分业务展示骨架。
|
||||
- 当前仍残留较多“项目说明型”表达。
|
||||
- 本轮必须补齐：
|
||||
- 按门店支持能力驱动的场景切换。
|
||||
- 动态活动区，而不是固定八宫格。
|
||||
- 推荐商品区、服务信息区、导流入口区。
|
||||
- 减少开发说明模块对主视觉的占用。
|
||||
- 验收标准：
|
||||
- 首页首先服务交易导流，而不是展示开发说明。
|
||||
- 页面结构与 `docs/07-页面规格/01-Tab-首页.md` 一致。
|
||||
- 首页能稳定导流到点餐、订单、活动和服务页。
|
||||
|
||||
### 6.12 `T04` 我的页
|
||||
|
||||
- 当前状态：
|
||||
- 已有页面和占位模块。
|
||||
- 当前仍偏联调 / 演示页。
|
||||
- 本轮必须补齐：
|
||||
- 用户头部卡。
|
||||
- 资产摘要区。
|
||||
- 订单快捷入口区。
|
||||
- 会员增长入口区。
|
||||
- 服务入口区和复购推荐区。
|
||||
- 验收标准：
|
||||
- 我的页是聚合页，不把资产值写成唯一真源。
|
||||
- 不把不稳定数量字段写死成强依赖。
|
||||
- 页面结构与 `docs/07-页面规格/04-Tab-我的页.md` 一致。
|
||||
|
||||
---
|
||||
|
||||
## 7. 跨页面统一验收标准
|
||||
|
||||
只要进入本轮执行范围，每个页面 / 组件都至少满足以下统一标准。
|
||||
|
||||
### 7.1 状态标准
|
||||
|
||||
- 有默认态。
|
||||
- 有加载态。
|
||||
- 有空态。
|
||||
- 有异常态。
|
||||
- 有禁用态。
|
||||
|
||||
### 7.2 触控与交互标准
|
||||
|
||||
- 主点击区域不小于 `44px`。
|
||||
- 异步按钮必须有 `loading` 或禁用反馈。
|
||||
- 错误信息尽量贴近问题区域显示。
|
||||
- 不允许通过隐藏规则让顾客猜下一步怎么做。
|
||||
|
||||
### 7.3 上下文一致性标准
|
||||
|
||||
以下上下文跨页必须一致：
|
||||
|
||||
- 当前门店
|
||||
- 当前场景
|
||||
- 购物车内容
|
||||
- 当前地址或桌台信息
|
||||
- 结算金额口径
|
||||
|
||||
### 7.4 文案标准
|
||||
|
||||
- 用顾客语言，不用商家后台语言。
|
||||
- 用动作导向文案，不用系统字段名堆砌文案。
|
||||
- 同一种状态在不同页面不要出现冲突叫法。
|
||||
|
||||
---
|
||||
|
||||
## 8. 当前这份文档的使用方式
|
||||
|
||||
如果现在继续推进正式小程序仓库，建议直接按下面节奏执行：
|
||||
|
||||
1. 先做 `P01 + P18 + P02`，把前置上下文补稳。
|
||||
2. 再做 `T02 + C01 + C02`，把点餐和加购链路收口。
|
||||
3. 再做 `P03 + P04`，把支付前后闭环收口。
|
||||
4. 再做 `T03 + P05`，把订单后链路收口。
|
||||
5. 最后回补 `T01 + T04`，把聚合页改成最终职责形态。
|
||||
|
||||
一句话结论：
|
||||
|
||||
当前正式仓库已经不是“很多页面还不存在”的阶段，而是“多数关键页面都已有最小实现，现在要按新冻结规格逐项收口”的阶段。
|
||||
111
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/00-总览.md
Normal file
111
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/00-总览.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# 租户管理员功能重构梳理总览
|
||||
|
||||
## 1. 这套文档解决什么问题
|
||||
|
||||
这套文档不是重新发明一套“小程序理想结构”，而是把：
|
||||
|
||||
1. `TenantUI` 里已经真实存在的租户管理员能力
|
||||
2. 旧版小程序原型文档里的页面与链路设计
|
||||
|
||||
重新做一遍对齐、裁剪和纠偏。
|
||||
|
||||
目标是把后台能力翻译成顾客任务语言，并明确：
|
||||
|
||||
- 哪些能力应该直接映射到小程序
|
||||
- 哪些能力只作为小程序背后的规则支撑
|
||||
- 哪些旧页面设计不合理，应该收敛、拆分或延后
|
||||
|
||||
---
|
||||
|
||||
## 2. 事实源优先级
|
||||
|
||||
### 第一优先级：真实后台实现
|
||||
|
||||
以 `TakeoutSaaS.TenantUI/apps/web-antd/src/views` 与 `src/api` 为主源。
|
||||
|
||||
当前已确认的后台业务域包括：
|
||||
|
||||
- `merchant`
|
||||
- `store`
|
||||
- `product`
|
||||
- `order`
|
||||
- `marketing`
|
||||
- `member`
|
||||
- `customer`
|
||||
- `finance`
|
||||
- `dashboard`
|
||||
|
||||
### 第二优先级：旧版小程序原型文档
|
||||
|
||||
旧文档继续保留，但只作为“待校正参考”，重点参考：
|
||||
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/05-页面清单总表.md`
|
||||
- `docs/09-租户后台与C端功能映射总表.md`
|
||||
- `docs/07-页面规格/`
|
||||
|
||||
### 覆盖规则
|
||||
|
||||
从本目录开始，凡是已经完成的批次，其结论优先级高于旧版总表和旧版单页规格中对应范围的描述。
|
||||
|
||||
---
|
||||
|
||||
## 3. 分批方式
|
||||
|
||||
本轮不按后台菜单一块块讲，也不按小程序页面一页页散着讲，而是按顾客真实链路拆批次。
|
||||
|
||||
| 批次 | 链路主题 | 主要后台域 | 主要小程序承接页 | 当前状态 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `B01` | 店铺进入与可下单前提链路 | `merchant` + `store` | `T01`、`P01`、`P02`、`T02`头部、`P03`、`P18` | 已完成 |
|
||||
| `B02` | 菜单浏览与加购链路 | `product` | `T02`、`C01`、`C02`、首页推荐区 | 已完成 |
|
||||
| `B03` | 结算与支付链路 | `order` + `marketing` + `member` + `store` | `P03`、`P04`、优惠/支付弹层 | 已完成 |
|
||||
| `B04` | 履约、订单、售后链路 | `order` + `store` | `T03`、`P05`、`P06`、`P07`、`P08` | 已完成 |
|
||||
| `B05` | 我的、资产、消息、复购链路 | `member` + `marketing` | `T04`、`P12`、`P13`、`P14`、`P15`、`P16` | 已完成 |
|
||||
| `B06` | 活动导购与增长链路 | `marketing` | `T01`、`T02`、`P09`、`P10`、`P11` | 已完成 |
|
||||
| `B07` | 精细化运营与不前置能力 | `customer` + `finance` + `dashboard` | 间接支撑 / 未来扩展 | 已完成 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 每一批固定输出模板
|
||||
|
||||
后续每一批都按同一结构整理，避免越做越乱：
|
||||
|
||||
1. 批次范围与证据源
|
||||
2. 后台真实功能清单
|
||||
3. 小程序承接页面与组件
|
||||
4. 不合理设计点
|
||||
5. 调整后的页面职责与映射结论
|
||||
6. 对下一批的依赖与冻结项
|
||||
|
||||
---
|
||||
|
||||
## 5. 当前已落地成果
|
||||
|
||||
- `01-门店前置链路.md`
|
||||
- `02-菜单浏览与加购链路.md`
|
||||
- `03-结算与支付链路.md`
|
||||
- `04-履约订单与售后链路.md`
|
||||
- `05-我的资产消息复购链路.md`
|
||||
- `06-活动导购与增长链路.md`
|
||||
- `07-精细化运营与不前置能力.md`
|
||||
|
||||
已完成批次：
|
||||
|
||||
- `01-门店前置链路.md`：梳理 `merchant/store` 对首页、选店、地址、结算、堂食扫码的影响
|
||||
- `02-菜单浏览与加购链路.md`：梳理 `product` 对点餐页、商品详情抽屉、购物车抽屉的影响
|
||||
- `03-结算与支付链路.md`：梳理 `order/marketing/member/store` 对结算页、支付方式、支付成功页的影响
|
||||
- `04-履约订单与售后链路.md`：梳理 `order/store` 对订单页、订单详情、退款结果、评价页的影响，并明确商家看板能力与顾客端页面的边界
|
||||
- `05-我的资产消息复购链路.md`：梳理 `member/marketing` 对我的页、会员中心、积分商城、储值充值、次卡、消息入口和复购入口的影响，并明确聚合页与真实资产源的边界
|
||||
- `06-活动导购与增长链路.md`：梳理 `marketing` 对首页活动区、点餐页活动提示、领券中心、秒杀页、限时折扣页的影响，并明确哪些活动适合独立成页、哪些只应作为规则结果存在
|
||||
- `07-精细化运营与不前置能力.md`：梳理 `customer/finance/dashboard` 对小程序的间接支撑边界，并明确哪些后台运营、财务、驾驶舱能力不应直接前置成顾客页面
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前工作规则
|
||||
|
||||
- 优先做“功能映射 + 合理性审查”，暂不直接下钻到字段级页面规格
|
||||
- 一个批次冻结后，再进入下一批
|
||||
- 如果旧文档和后台真实能力冲突，以后台真实能力为准
|
||||
- 如果后台能力当前对顾客没有清晰价值，就先归为“间接支撑”或“未来扩展”，不强行前置
|
||||
375
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/01-门店前置链路.md
Normal file
375
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/01-门店前置链路.md
Normal file
@@ -0,0 +1,375 @@
|
||||
# B01 门店前置链路
|
||||
|
||||
## 1. 批次目标
|
||||
|
||||
本批次只解决一件事：
|
||||
|
||||
在顾客真正开始点餐之前，哪些租户管理员配置会决定“能不能下单、在哪下单、按什么场景下单、费用和履约规则怎么感知”。
|
||||
|
||||
这一批覆盖的不是“商品怎么卖”，而是“顾客能不能进入正确的点餐上下文”。
|
||||
|
||||
---
|
||||
|
||||
## 2. 证据源
|
||||
|
||||
### 后台真实来源
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/merchant/center`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/list`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/hours`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/delivery`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/pickup`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/fees`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/dine-in`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/staff`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/merchant`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/store*`
|
||||
|
||||
### 旧版小程序参考
|
||||
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/07-页面规格/01-Tab-首页.md`
|
||||
- `docs/07-页面规格/05-门店选择页.md`
|
||||
- `docs/07-页面规格/06-地址管理页.md`
|
||||
- `docs/07-页面规格/09-结算确认页.md`
|
||||
- `docs/07-页面规格/24-堂食扫码确认页.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 后台真实功能清单
|
||||
|
||||
| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 商户中心 | 商户名称、经营模式、联系电话、邮箱、注册地址、地理定位、门店关联 | 部分可感知 | 首页品牌信息、门店信息、帮助中心/联系商家 | 间接支撑为主 |
|
||||
| 门店列表 | 门店名称、地址、负责人、联系方式、封面图、营业状态、审核状态、服务方式 | 是 | 首页当前门店、门店选择页、点餐页头部 | 直接承接 |
|
||||
| 营业时间 | 每周营业时段、配送时段、自提时段、节假日/特殊营业 | 是 | 首页服务摘要、门店选择页、点餐页头部、结算页 | 直接承接 |
|
||||
| 配送设置 | `polygon/radius` 两种配送模式，范围、梯度、配送费、起送门槛、ETA、容量、最大距离 | 是 | 门店选择页、地址管理、结算页、首页服务摘要 | 直接承接 |
|
||||
| 自提设置 | 基础规则、`big/fine` 两种时间模式、预约天数、同日自提、容量、截止时间、预览时段 | 是 | 首页服务摘要、结算页自提时间、点餐前场景可用性 | 直接承接 |
|
||||
| 费用设置 | 起送价、基础配送费、免配送门槛、包装费模式、包装费阶梯、餐具费、其他费用 | 是，但不是全部字段都直出 | 首页摘要、结算页费用明细 | 部分直接承接 |
|
||||
| 堂食管理 | 堂食开关、默认用餐时长、超时提醒、区域、桌位、批量生成桌位 | 是 | 堂食扫码确认页、堂食点餐页头部、结算页堂食信息卡 | 直接承接 |
|
||||
| 员工排班 | 员工、班次模板、周排班、复制排班 | 否 | 无独立页面，仅影响 ETA/服务稳定性 | 间接支撑 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 后台字段到 C 端的映射结论
|
||||
|
||||
### 4.1 可以直接前置给顾客的字段
|
||||
|
||||
- 门店名称
|
||||
- 门店地址
|
||||
- 联系电话
|
||||
- 当前营业状态
|
||||
- 当前支持的服务方式：`delivery / pickup / dine_in`
|
||||
- 当前场景下的营业时间或可用时段
|
||||
- 当前场景下的履约信息：
|
||||
- 外卖：配送范围、预计送达、起送门槛、配送费
|
||||
- 自提：可预约时间、是否支持当天自提
|
||||
- 堂食：门店、桌号、是否可入桌
|
||||
- 费用相关顾客可见项：
|
||||
- 起送金额
|
||||
- 配送费
|
||||
- 打包费
|
||||
- 餐具费
|
||||
|
||||
### 4.2 只作为计算或状态支撑，不直接裸露给顾客的字段
|
||||
|
||||
- 门店审核状态 `draft / pending / rejected`
|
||||
- 地理定位失败原因、后台重试定位动作
|
||||
- 配送容量上限 `hourlyCapacityLimit`
|
||||
- 配送模式实现细节 `polygonGeoJson`
|
||||
- 平台服务费率 `platformServiceRate`
|
||||
- 员工权限、班次模板、周排班结构
|
||||
|
||||
### 4.3 当前不应直接做成顾客功能的能力
|
||||
|
||||
- 商户合同
|
||||
- 商户审核日志 / 变更日志
|
||||
- 员工排班页面
|
||||
- 堂食桌位批量生成
|
||||
|
||||
---
|
||||
|
||||
## 5. 小程序页面重映射
|
||||
|
||||
## 5.1 `T01 首页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 当前商户品牌信息
|
||||
- 当前门店摘要
|
||||
- 当前可用场景切换
|
||||
- 当前场景下的简版服务信息
|
||||
- 进入点餐、切店、看活动的导流动作
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 首页场景切换不能固定死为三个按钮，而应由当前门店的 `serviceTypes` 决定
|
||||
- 首页只显示“当前场景相关”的一层摘要：
|
||||
- 外卖：营业状态、预计送达、起送价、配送费
|
||||
- 自提：营业状态、最近可约时段、是否支持当日取餐
|
||||
- 堂食：营业状态、是否支持扫码入桌
|
||||
- 详细规则不要整块堆在首页，统一进入一个“门店服务详情抽屉”或“门店详情页”
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应同时完整展开配送、自提、堂食三套规则
|
||||
- 不应展示后台式字段，如平台服务费率、排班信息、审核信息
|
||||
|
||||
## 5.2 `P01 门店选择页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 切换当前门店
|
||||
- 在当前场景下判断门店是否可下单
|
||||
- 给出最关键的履约摘要
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 外卖场景下，门店卡必须结合当前地址或定位结果判断：
|
||||
- 是否可配送
|
||||
- 预计送达
|
||||
- 配送费
|
||||
- 起送门槛
|
||||
- 自提场景下，门店卡需要展示：
|
||||
- 当前是否营业
|
||||
- 是否支持自提
|
||||
- 最早可预约时段
|
||||
- 堂食场景下，门店选择不是主入口，默认应由扫码绑定；手动选店只作为兜底
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应把后台审核状态直接翻译给顾客看
|
||||
- 不应只展示门店名字和距离，然后默认认为“可下单”
|
||||
|
||||
## 5.3 `P02 地址管理页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 管理顾客地址
|
||||
- 让顾客知道“这个地址对当前门店是否可配送”
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 地址项上的“适用范围提示”不是可选项，而是核心状态
|
||||
- 至少需要支持：
|
||||
- 可配送
|
||||
- 超出最大距离
|
||||
- 不在配送区域
|
||||
- 未达到门店服务条件时的提示
|
||||
- 从结算进入时，应支持“选择用于本次订单”并立即回传配送结果
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应只做通用通讯录
|
||||
- 不应把配送范围校验延迟到最后支付前才告诉用户
|
||||
|
||||
## 5.4 `T02 点餐页头部`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 当前门店
|
||||
- 当前场景
|
||||
- 当前场景可售状态
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 头部需要给出顾客当前上下文：
|
||||
- 外卖：配送到哪、是否可送
|
||||
- 自提：当前门店、所选取餐方式
|
||||
- 堂食：门店 + 桌号
|
||||
- 这部分是交易上下文，不是纯视觉标题
|
||||
|
||||
## 5.5 `P03 结算确认页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 把门店规则翻译成顾客能确认的履约信息和费用信息
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 外卖：
|
||||
- 展示选中的地址
|
||||
- 展示当前配送费、预计送达、是否满足起送
|
||||
- 自提：
|
||||
- 不做自由文本时间输入
|
||||
- 必须基于后台 `previewDays` / 时段配置生成顾客可选时间
|
||||
- 堂食：
|
||||
- 展示门店与桌号
|
||||
- 不展示配送相关模块
|
||||
- 费用明细只展示顾客应理解的金额项，不展示后台结算字段
|
||||
|
||||
## 5.6 `P18 堂食扫码确认页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 确认扫码得到的门店、区域、桌号是否有效
|
||||
- 把用户送进堂食点餐上下文
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 必须围绕后台已有能力展示：
|
||||
- 门店名称
|
||||
- 桌号
|
||||
- 桌位状态是否可用
|
||||
- 堂食是否开启
|
||||
- 如当前桌不可用，应给出明确兜底动作：
|
||||
- 重新扫码
|
||||
- 联系门店
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应承诺后台当前并不存在的规则，如“是否先付款”“是否支持合单”“是否支持加菜”
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前发现的不合理设计点
|
||||
|
||||
### 6.1 首页固定提供 `外卖 / 自提 / 堂食` 三个场景，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台门店是按 `serviceTypes` 配置场景支持范围
|
||||
- 不是所有门店都同时支持三种场景
|
||||
|
||||
调整：
|
||||
|
||||
- 首页和点餐页头部的场景切换必须动态生成
|
||||
- 不支持的场景不展示，或展示为禁用并给出原因
|
||||
|
||||
### 6.2 首页把配送、自提、堂食规则一起堆在“门店服务信息区”，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台这三套规则已经足够复杂
|
||||
- 同时平铺会把首页做成“规则展示页”，而不是导流页
|
||||
|
||||
调整：
|
||||
|
||||
- 首页只保留当前场景摘要
|
||||
- 增加统一的“门店服务详情”承接更完整规则
|
||||
|
||||
### 6.3 地址管理页把“适用范围提示”写成可选，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台配送有 `polygon/radius` 模式、最大距离、起送门槛、梯度费用
|
||||
- 地址是否能送，是点单前置条件，不是附加说明
|
||||
|
||||
调整：
|
||||
|
||||
- 地址列表必须内建配送可用性判断
|
||||
- 结算页也必须复用同一套校验结果
|
||||
|
||||
### 6.4 结算页把自提时间理解成普通字段，不够准确
|
||||
|
||||
原因：
|
||||
|
||||
- 后台自提不是简单时间输入，而是两种配置模式：
|
||||
- `big` 大时段
|
||||
- `fine` 精细时段
|
||||
- 还带有预约天数、同日自提、容量和截止时间
|
||||
|
||||
调整：
|
||||
|
||||
- 结算页应做“可选时段选择器”
|
||||
- 时间数据必须由后台可预约结果驱动，不能前端自造
|
||||
|
||||
### 6.5 堂食扫码确认页包含“先付款/合单/加菜”等规则说明，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 当前后台堂食管理只提供：
|
||||
- 开关
|
||||
- 默认用餐时长
|
||||
- 超时提醒
|
||||
- 区域
|
||||
- 桌位
|
||||
- 没有“先付款/合单/加菜”配置来源
|
||||
|
||||
调整：
|
||||
|
||||
- 本期删除这类说明
|
||||
- 需要时作为后续堂食业务增强单独规划
|
||||
|
||||
### 6.6 费用设置中的 `platformServiceRate` 不应前置给顾客
|
||||
|
||||
原因：
|
||||
|
||||
- 这是后台经营或结算字段，不是顾客决策字段
|
||||
- 顾客只需要理解最终产生的费用项
|
||||
|
||||
调整：
|
||||
|
||||
- 小程序只承接：
|
||||
- 起送价
|
||||
- 配送费
|
||||
- 打包费
|
||||
- 餐具费
|
||||
- 其他真实对顾客收费的项目
|
||||
|
||||
### 6.7 员工排班不应映射为顾客页面能力
|
||||
|
||||
原因：
|
||||
|
||||
- 顾客不需要看到后台排班结构
|
||||
- 它只影响服务稳定性和等待感知
|
||||
|
||||
调整：
|
||||
|
||||
- 仅作为 ETA、门店忙闲提示或帮助说明的间接输入
|
||||
- 不建设“排班相关前台页”
|
||||
|
||||
### 6.8 门店选择页“点击门店即切换并返回”过于理想化
|
||||
|
||||
原因：
|
||||
|
||||
- 外卖场景下还要结合当前地址是否可配送
|
||||
- 全局规则里已约束：切店、切场景可能导致购物车清空
|
||||
|
||||
调整：
|
||||
|
||||
- 当存在购物车或地址不兼容时，必须加确认和结果提示
|
||||
- 不能默认无条件返回
|
||||
|
||||
---
|
||||
|
||||
## 7. 本批次冻结后的映射结论
|
||||
|
||||
### 7.1 直接承接
|
||||
|
||||
- 商户品牌基础信息
|
||||
- 门店选择与门店状态
|
||||
- 场景可用性
|
||||
- 营业时间和特殊营业状态
|
||||
- 配送范围、费用、ETA、起送门槛
|
||||
- 自提可预约时段与规则摘要
|
||||
- 堂食门店与桌号有效性
|
||||
- 顾客可见费用项
|
||||
|
||||
### 7.2 间接支撑
|
||||
|
||||
- 商户定位状态
|
||||
- 门店审核状态
|
||||
- 配送容量上限
|
||||
- 员工排班
|
||||
- 后台复制配置能力
|
||||
|
||||
### 7.3 本批次新增约束
|
||||
|
||||
- 首页仍然是导流页，不变成规则总览页
|
||||
- 场景切换必须受门店配置约束
|
||||
- 地址可配送性必须前置
|
||||
- 自提时间必须来源于后台可预约结果
|
||||
- 堂食扫码确认页只承接后台真实存在的配置
|
||||
|
||||
---
|
||||
|
||||
## 8. 对下一批的依赖
|
||||
|
||||
下一批做商品链路时，需要直接继承本批次的前提：
|
||||
|
||||
- 点餐页先有正确的门店和场景上下文，再谈商品可售
|
||||
- 商品的“不可售”状态要能接住本批次的门店/时段/场景限制
|
||||
- 购物车只能绑定一个门店 + 一个场景
|
||||
360
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md
Normal file
360
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md
Normal file
@@ -0,0 +1,360 @@
|
||||
# B02 菜单浏览与加购链路
|
||||
|
||||
## 1. 批次目标
|
||||
|
||||
本批次解决的是：
|
||||
|
||||
顾客进入点餐页后，商品该如何按场景展示、按什么规则可售、什么情况下允许快速加购、什么情况下必须进商品详情抽屉，以及购物车抽屉到底该承接哪些动作。
|
||||
|
||||
这一批不处理支付、优惠结算和订单状态，只处理“能买什么、怎么买进购物车”。
|
||||
|
||||
---
|
||||
|
||||
## 2. 证据源
|
||||
|
||||
### 后台真实来源
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/list`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/detail`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/category`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/specs`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/addons`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/labels`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/schedule`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/batch`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/product`
|
||||
|
||||
### 旧版小程序参考
|
||||
|
||||
- `docs/03-全局业务规则.md`
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/07-页面规格/02-Tab-点餐页.md`
|
||||
- `docs/07-页面规格/07-商品详情抽屉.md`
|
||||
- `docs/07-页面规格/08-购物车抽屉.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 后台真实功能清单
|
||||
|
||||
| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 商品列表 | 商品名称、副标题、主图、价格、划线价、月售、状态、库存、标签、分类、单品/套餐类型 | 是 | 点餐页、首页推荐商品卡 | 直接承接 |
|
||||
| 商品详情 | 多图、描述、排序、包装费、标签、规格模板、加料组、SKU、套餐分组、上下架/定时上架、沽清信息 | 部分直接可感知 | 商品详情抽屉、购物车、结算前价格计算 | 直接承接为主 |
|
||||
| 分类管理 | 分类名称、排序、启停、图标、描述、商品绑定、展示渠道 `wm/pickup/dine_in` | 是 | 点餐页分类导航 | 直接承接 |
|
||||
| 规格做法 | `spec/method` 模板、单选/多选、是否必选、选项加价、关联商品 | 是 | 商品详情抽屉、SKU定价 | 直接承接 |
|
||||
| 加料管理 | 加料组、必选/非必选、最少/最多可选、选项价格与库存、关联商品 | 是 | 商品详情抽屉、购物车规格摘要 | 直接承接 |
|
||||
| 商品标签 | 标签名称、颜色、排序、启停 | 是 | 商品卡、商品详情抽屉、首页推荐卡 | 直接承接 |
|
||||
| 时段供应 | 规则名称、开始结束时间、星期、启停、关联商品；未被规则覆盖商品默认全天供应 | 是 | 点餐页商品可售状态、商品详情抽屉 | 直接承接 |
|
||||
| 批量工具 | 批量调价、上下架、移动分类、多门店同步、导入导出 | 否 | 无独立前台承接 | 间接支撑 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 后台字段到 C 端的映射结论
|
||||
|
||||
### 4.1 可以直接前置给顾客的字段
|
||||
|
||||
- 商品名称
|
||||
- 商品副标题或摘要描述
|
||||
- 商品主图与附图
|
||||
- 当前售价与划线价
|
||||
- 商品标签
|
||||
- 月售等弱经营数据
|
||||
- 商品类型：单品 / 套餐
|
||||
- 当前可选规格、做法、加料
|
||||
- SKU 对应的价格与库存结果
|
||||
- 套餐分组与每组可选规则
|
||||
- 商品是否可售及原因：
|
||||
- 下架
|
||||
- 售罄
|
||||
- 临时沽清
|
||||
- 当前场景不可售
|
||||
- 当前时段不可售
|
||||
- 商品级包装费提示（如最终确实影响顾客支付）
|
||||
|
||||
### 4.2 只作为计算或后台配置支撑，不直接裸露给顾客的字段
|
||||
|
||||
- `spuCode`
|
||||
- `sortWeight`
|
||||
- `warningStock`
|
||||
- `notifyManager`
|
||||
- `syncToPlatform`
|
||||
- SKU 异步保存任务状态
|
||||
- 后台批量工具范围、预览、导入导出能力
|
||||
|
||||
### 4.3 当前不应直接做成顾客功能的能力
|
||||
|
||||
- 批量调价
|
||||
- 批量上下架
|
||||
- 批量移动分类
|
||||
- 多门店同步商品
|
||||
- Excel 导入导出
|
||||
|
||||
---
|
||||
|
||||
## 5. 小程序页面重映射
|
||||
|
||||
## 5.1 `T02 点餐页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 基于当前门店 + 当前场景展示可售分类和商品
|
||||
- 快速浏览价格、标签、基本卖点
|
||||
- 对“可直接加购”和“必须先选配”的商品做分流
|
||||
- 提供搜索、分类切换、打开商品详情、打开购物车
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 分类导航不能是全场景通用一套，必须受后台分类 `channels` 约束：
|
||||
- `wm` 对应外卖
|
||||
- `pickup` 对应自提
|
||||
- `dine_in` 对应堂食
|
||||
- 商品列表至少要区分三种可购买形态：
|
||||
- 无规格无加料的单品：允许直接步进器加购
|
||||
- 有规格/做法/加料的单品：点击加购先打开商品详情抽屉
|
||||
- 套餐商品：默认进入商品详情抽屉做套餐分组选择
|
||||
- 商品卡上的“可售状态”不能只显示“售罄”：
|
||||
- 要区分当前不可售原因
|
||||
- 顾客需要知道是时段问题、场景问题还是库存问题
|
||||
- 搜索结果也必须遵守当前门店、当前场景、当前时段的可售口径
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应把营销活动条作为商品域主结构核心
|
||||
- 不应把复杂优惠解释塞进商品列表主区
|
||||
- 不应对所有商品一律显示“+”并默认快速加购
|
||||
|
||||
## 5.2 `C01 商品详情抽屉`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 完成商品选配
|
||||
- 让顾客在一个上下文里看清楚价格、选项、库存结果
|
||||
- 把正确的商品组合加入购物车
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 抽屉需要覆盖三种商品配置形态：
|
||||
- 单品 + 规格做法
|
||||
- 单品 + 加料组
|
||||
- 套餐 + 套餐分组 + 规格/加料组合
|
||||
- 规格做法区必须继承后台模板配置：
|
||||
- `spec`
|
||||
- `method`
|
||||
- `single / multi`
|
||||
- `isRequired`
|
||||
- 加料区必须继承后台约束：
|
||||
- `required`
|
||||
- `minSelect`
|
||||
- `maxSelect`
|
||||
- 选项价格
|
||||
- 选项库存
|
||||
- 价格显示必须实时跟随 SKU 和加料变化
|
||||
- 如果商品有多图，可以轮播；但重点仍是“选择并加购”，不是做详情长页
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应保留“立即购买”分支作为默认设计
|
||||
- 不应只支持“规格 + 加料”两种模型，遗漏套餐分组
|
||||
- 不应把后台字段如 `SPU`、同步平台、预警库存暴露给顾客
|
||||
|
||||
## 5.3 `C02 购物车抽屉`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 汇总当前门店 + 当前场景下已选商品
|
||||
- 允许快速修改数量
|
||||
- 暴露失效商品并做清理
|
||||
- 提供唯一的“去结算”主路径
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 商品行至少需要显示：
|
||||
- 商品名
|
||||
- 规格摘要
|
||||
- 加料摘要
|
||||
- 套餐选择摘要
|
||||
- 单价
|
||||
- 数量
|
||||
- 如果某个购物车商品因状态变化失效，要能标出原因：
|
||||
- 已下架
|
||||
- 已售罄
|
||||
- 当前时段不可售
|
||||
- 当前场景不可售
|
||||
- 购物车里的提示应以“凑单 / 起送 / 失效清理”为主
|
||||
- 去结算按钮只保留一个主动作，不再在购物车里做复杂分流
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应把它做成优惠券和营销活动的主战场
|
||||
- 不应在这里承接与商品选择无关的大量说明文字
|
||||
|
||||
## 5.4 首页推荐商品区
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 做轻量商品导流
|
||||
- 展示少量代表性商品卡
|
||||
- 把顾客送入点餐页或商品详情抽屉
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 首页推荐卡只展示摘要，不复刻点餐页分类与筛选能力
|
||||
- 如果商品需要选配，应直接拉起商品详情抽屉或跳转点餐页对应商品
|
||||
- 首页推荐商品卡上的标签必须来自后台启用状态的商品标签，不应手写运营词
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前发现的不合理设计点
|
||||
|
||||
### 6.1 点餐页把分类理解成一套固定菜单，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台分类管理已经有展示渠道 `wm / pickup / dine_in`
|
||||
- 同一门店不同场景下，不一定展示同一套分类
|
||||
|
||||
调整：
|
||||
|
||||
- 点餐页分类必须按当前场景过滤
|
||||
- 前台展示文案统一使用 `外卖 / 自提 / 堂食`，不要直接暴露后台渠道值
|
||||
|
||||
### 6.2 旧文档默认“直接点击步进器可快速加购默认 SKU”，范围过宽
|
||||
|
||||
原因：
|
||||
|
||||
- 后台商品存在：
|
||||
- 多规格 SKU
|
||||
- 加料组
|
||||
- 套餐分组
|
||||
- 这些商品并没有安全的“默认组合”
|
||||
|
||||
调整：
|
||||
|
||||
- 只有无规格、无加料、非套餐商品允许直接加购
|
||||
- 其余情况统一先开商品详情抽屉
|
||||
|
||||
### 6.3 商品详情抽屉只写“规格做法 + 加料”，遗漏套餐分组，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台商品明确支持 `combo`
|
||||
- 套餐有 `comboGroups`、每组 `minSelect/maxSelect`
|
||||
|
||||
调整：
|
||||
|
||||
- 商品详情抽屉必须增加套餐分组选择区
|
||||
- 套餐商品不能套用普通单品详情结构
|
||||
|
||||
### 6.4 点餐页把“活动提示条”放成主区块，职责混杂
|
||||
|
||||
原因：
|
||||
|
||||
- 活动命中结果来自营销域，不是商品域本身
|
||||
- 商品域本批次要先把可售性、分类、选配、加购做稳
|
||||
|
||||
调整：
|
||||
|
||||
- 点餐页允许保留轻量活动摘要
|
||||
- 但不把它当成页面主结构，不影响商品主区的信息组织
|
||||
|
||||
### 6.5 购物车抽屉把“已命中活动摘要”作为核心结构，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 购物车的首要任务是确认已选商品和失效项
|
||||
- 真正完整的优惠选择与命中结果应该在结算页收口
|
||||
|
||||
调整：
|
||||
|
||||
- 购物车只保留轻量凑单与命中提示
|
||||
- 复杂优惠解释延后到结算与支付批次处理
|
||||
|
||||
### 6.6 商品不可售规则写得过粗，不够贴近后台真实状态
|
||||
|
||||
原因：
|
||||
|
||||
- 后台有 `on_sale / off_shelf / sold_out`
|
||||
- 还有 `today / timed / permanent` 等沽清模式
|
||||
- 再叠加时段供应和场景分类限制
|
||||
|
||||
调整：
|
||||
|
||||
- 前台要统一翻译成顾客能理解的几类原因
|
||||
- 但底层仍需保留不同不可售来源，避免错误加购
|
||||
|
||||
### 6.7 商品标签不能被当成任意运营文案插槽
|
||||
|
||||
原因：
|
||||
|
||||
- 后台标签是独立配置域，带启停、排序、颜色
|
||||
- 如果前台随意自造标签，会和后台配置失真
|
||||
|
||||
调整：
|
||||
|
||||
- 商品卡和详情页只展示启用状态的有效标签
|
||||
- 推荐区与点餐页共用同一套标签来源
|
||||
|
||||
### 6.8 商品详情抽屉的“立即购买”在当前链路里不合适
|
||||
|
||||
原因：
|
||||
|
||||
- 当前全局规则强调单门店 + 单场景购物车上下文
|
||||
- 规格、加料、套餐、起送和费用都需要进入统一结算链路
|
||||
|
||||
调整：
|
||||
|
||||
- V1 去掉“立即购买”
|
||||
- 主动作统一为“加入购物车”
|
||||
|
||||
### 6.9 批量工具不该继续出现在任何 C 端映射里
|
||||
|
||||
原因：
|
||||
|
||||
- 它们只服务商家运营效率
|
||||
- 对顾客没有直接任务价值
|
||||
|
||||
调整：
|
||||
|
||||
- 从顾客映射中明确降级为“纯间接支撑”
|
||||
|
||||
---
|
||||
|
||||
## 7. 本批次冻结后的映射结论
|
||||
|
||||
### 7.1 直接承接
|
||||
|
||||
- 商品列表与基础商品卡
|
||||
- 场景化分类导航
|
||||
- 规格做法选择
|
||||
- 加料选择
|
||||
- 套餐分组选择
|
||||
- 商品标签
|
||||
- 商品可售状态与原因提示
|
||||
- 购物车商品汇总与失效清理
|
||||
|
||||
### 7.2 间接支撑
|
||||
|
||||
- 商品排序权重
|
||||
- 预警库存
|
||||
- 沽清同步平台、通知店长等后台动作
|
||||
- 批量工具
|
||||
- SKU 异步保存机制
|
||||
|
||||
### 7.3 本批次新增约束
|
||||
|
||||
- 分类展示必须受场景渠道约束
|
||||
- 只有简单单品可以直接快速加购
|
||||
- 套餐必须有独立选择模型
|
||||
- 购物车抽屉优先解决商品确认，不承接复杂优惠解释
|
||||
- 商品不可售原因必须能被顾客理解
|
||||
|
||||
---
|
||||
|
||||
## 8. 对下一批的依赖
|
||||
|
||||
下一批做结算与支付链路时，需要直接继承本批次前提：
|
||||
|
||||
- 购物车中的商品组合已经是合法组合
|
||||
- 每个购物车项都有明确的规格、加料、套餐选择结果
|
||||
- 商品可售校验结果需要继续传递到结算页
|
||||
- 商品级包装费如果参与支付金额，需要在结算页统一解释清楚
|
||||
394
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/03-结算与支付链路.md
Normal file
394
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/03-结算与支付链路.md
Normal file
@@ -0,0 +1,394 @@
|
||||
# B03 结算与支付链路
|
||||
|
||||
## 1. 批次目标
|
||||
|
||||
本批次解决的是：
|
||||
|
||||
顾客从购物车进入结算后，哪些信息必须确认、哪些优惠和资产应该手动选择、哪些只是后台自动命中结果、支付方式应该如何收口，以及支付成功页该如何承接后续动作。
|
||||
|
||||
这一批不处理订单列表和售后，也不再讨论商品怎么选配，只处理“怎么结算、怎么支付、支付后看到什么”。
|
||||
|
||||
---
|
||||
|
||||
## 2. 证据源
|
||||
|
||||
### 后台真实来源
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/order`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/index`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/full-reduction`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/new-customer`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/punch-card`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/index`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/stored-card`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/points-mall`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/store-fees`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/coupon`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/full-reduction`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/new-customer`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/punch-card`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/list`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/stored-card`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/points-mall`
|
||||
|
||||
### 已完成批次依赖
|
||||
|
||||
- `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`
|
||||
|
||||
### 旧版小程序参考
|
||||
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/07-页面规格/09-结算确认页.md`
|
||||
- `docs/07-页面规格/10-支付成功页.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 后台真实功能清单
|
||||
|
||||
| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 门店费用设置 | 起送价、基础配送费、免配送门槛、包装费模式、餐具费、其他费用 | 是 | 结算页费用明细、购物车凑单提示 | 直接承接 |
|
||||
| 优惠券 | 券类型 `amount_off / discount / free_delivery`、门槛、有效期、渠道、门店范围、每人限领 | 是 | 领券中心、结算页优惠选择 | 直接承接 |
|
||||
| 满减活动 | 满减/满赠/第二份优惠、适用渠道、门店范围、商品范围、是否与券叠加 | 结果可感知 | 结算页自动命中结果、商品页轻量摘要 | 直接承接为主 |
|
||||
| 新客有礼 | 新客券包、直减、邀请奖励、欢迎券、分享渠道 | 结果可感知 | 首页新客入口、结算页自动命中结果 | 直接承接为主 |
|
||||
| 会员等级权益 | 折扣、积分倍率、生日券、每月券、免配送费、优先配送、会员日额外折扣 | 部分可感知 | 结算页权益提示、会员中心 | 直接承接为主 |
|
||||
| 储值卡 | 充值方案、余额资产、充值记录、支付方式记录 | 是 | 结算页余额支付、储值充值页、我的资产摘要 | 直接承接 |
|
||||
| 积分商城 | 积分规则、兑换商品、兑换记录 | 主要用于兑换，不是明确订单抵扣契约 | 积分商城页、我的资产摘要 | 间接支撑为主 |
|
||||
| 次卡 | 次卡模板、适用范围、使用上限、额外补差、使用记录 | 是，但使用条件强依赖商品范围 | 结算页次卡可用提示/核销、次卡页 | 直接承接为主 |
|
||||
| 订单支付结果 | 订单金额、优惠金额、配送费、支付方式、支付时间、订单时间线 | 是 | 支付成功页、订单详情页 | 直接承接 |
|
||||
| 支付方式口径 | 订单/交易记录中已有 `wechat / alipay / balance / card / cash` 等类型 | 部分可感知 | 小程序支付方式弹层 | 有限直接承接 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 后台字段到 C 端的映射结论
|
||||
|
||||
### 4.1 可以直接前置给顾客并允许手动操作的项
|
||||
|
||||
- 配送地址 / 自提时间 / 堂食桌号确认
|
||||
- 订单备注
|
||||
- 餐具费相关选项
|
||||
- 优惠券选择
|
||||
- 储值余额支付开关或选择
|
||||
- 次卡核销选择
|
||||
- 支付方式选择
|
||||
|
||||
### 4.2 可以前置给顾客，但更适合作为自动命中结果展示的项
|
||||
|
||||
- 满减活动命中结果
|
||||
- 新客有礼命中结果
|
||||
- 会员等级折扣
|
||||
- 会员免配送费权益
|
||||
- 会员日额外折扣
|
||||
|
||||
这些能力可以在结算页展示“已为你优惠多少”或“已享受某权益”，但不应都做成用户手动逐个开关。
|
||||
|
||||
### 4.3 当前证据不足，不应先写成确定可用的前台能力
|
||||
|
||||
- 订单级积分抵扣
|
||||
|
||||
原因：
|
||||
|
||||
- 当前能看到的积分后台主要是“积分获取规则 + 积分商城兑换”
|
||||
- 还没有看到明确的“订单结算抵扣积分”契约
|
||||
|
||||
结论：
|
||||
|
||||
- 结算页可以保留“积分权益提示”预留位
|
||||
- 但不要在当前梳理中把它冻结成确定的 `C04` 手动抵扣能力
|
||||
|
||||
### 4.4 不应直接暴露给顾客的后台字段
|
||||
|
||||
- 券模板编辑状态
|
||||
- 活动统计指标
|
||||
- 存储卡充值后台写入记录结构
|
||||
- 会员等级升级规则阈值明细
|
||||
- 次卡后台通知渠道和过期策略内部字段
|
||||
- 订单后台筛选值和财务结算渠道字段
|
||||
|
||||
---
|
||||
|
||||
## 5. 小程序页面重映射
|
||||
|
||||
## 5.1 `P03 结算确认页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 承接门店、场景、商品组合后的最终确认
|
||||
- 向顾客清楚解释“你为什么付这个金额”
|
||||
- 只暴露必要的可操作资产和支付动作
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 场景信息区继续继承第 1 批结论：
|
||||
- 外卖：地址、预计送达、配送费、起送校验
|
||||
- 自提：门店、自提时间、取餐人信息
|
||||
- 堂食：门店、桌号
|
||||
- 商品清单区继续继承第 2 批结果：
|
||||
- 商品
|
||||
- 规格
|
||||
- 加料
|
||||
- 套餐选择摘要
|
||||
- 商品小计
|
||||
- 优惠资产区要按“手动选择”和“自动命中”分层：
|
||||
- 手动选择：
|
||||
- 优惠券
|
||||
- 储值余额支付
|
||||
- 次卡核销
|
||||
- 自动命中结果：
|
||||
- 满减
|
||||
- 新客有礼
|
||||
- 会员折扣
|
||||
- 免配送费权益
|
||||
- 费用明细区必须拆清楚：
|
||||
- 商品金额
|
||||
- 包装费
|
||||
- 餐具费
|
||||
- 配送费
|
||||
- 自动优惠减免
|
||||
- 手动资产减免
|
||||
- 实付金额
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应把所有优惠都做成同等级可切换入口
|
||||
- 不应在金额区只给结果，不解释来源
|
||||
- 不应在当前证据不足时直接加入“积分抵扣”主流程
|
||||
|
||||
## 5.2 `C04 优惠选择弹层`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 只承接少数真正需要“由顾客主动选择”的资产
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 第一层只做三类能力：
|
||||
- 优惠券
|
||||
- 储值余额支付
|
||||
- 次卡核销
|
||||
- 每一类都需要展示不可用原因：
|
||||
- 不适用当前门店
|
||||
- 不适用当前场景
|
||||
- 不适用当前商品
|
||||
- 未达到门槛
|
||||
- 已过期 / 已用完
|
||||
- 自动命中的活动不要塞进这个弹层让用户手动勾选
|
||||
|
||||
### 当前冻结结论
|
||||
|
||||
- `积分抵扣` 暂不在本弹层冻结为正式能力
|
||||
|
||||
## 5.3 `C05 支付方式弹层`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 在用户点击“提交订单并支付”后，给出支付方式的最终确认
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 当前小程序优先只承接：
|
||||
- 微信支付
|
||||
- 余额支付
|
||||
- `alipay / cash / card` 虽然出现在后台交易口径里，但不应默认带入微信小程序支付方式选择
|
||||
- 如余额不足，要明确回退到微信支付或提示充值
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应展开后台财务通道配置说明
|
||||
- 不应做成复杂收银台
|
||||
|
||||
## 5.4 `P04 支付成功页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 明确支付完成
|
||||
- 把顾客送往下一步最关键动作
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 订单摘要必须包含：
|
||||
- 订单号
|
||||
- 门店名
|
||||
- 支付金额
|
||||
- 支付方式
|
||||
- 场景关键信息要继续继承结算结果：
|
||||
- 外卖：预计送达
|
||||
- 自提：取餐时间 / 取餐提示
|
||||
- 堂食：桌号 / 当前用餐上下文
|
||||
- CTA 只保留高价值动作：
|
||||
- 查看订单详情
|
||||
- 继续点餐 / 再逛逛
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应停留在空泛“支付成功”文案
|
||||
- 不应再重新解释一整套优惠计算过程
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前发现的不合理设计点
|
||||
|
||||
### 6.1 旧结算页把“优惠券 / 积分 / 储值 / 次卡”并列成同级手动入口，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 当前后台证据显示：
|
||||
- 优惠券有明确模板和选择逻辑
|
||||
- 储值余额有明确资产属性
|
||||
- 次卡有明确适用范围和使用记录
|
||||
- 积分当前更偏“积分商城兑换”而不是明确订单抵扣
|
||||
|
||||
调整：
|
||||
|
||||
- 手动入口先收敛为：
|
||||
- 优惠券
|
||||
- 储值余额
|
||||
- 次卡
|
||||
- 积分不在本批次冻结为确定抵扣能力
|
||||
|
||||
### 6.2 满减、新客有礼、会员折扣不该都做成顾客手动选择项
|
||||
|
||||
原因：
|
||||
|
||||
- 这些能力在后台更像规则命中
|
||||
- 顾客真正需要的是“命中了什么、少了多少钱”，不是自己配置规则优先级
|
||||
|
||||
调整：
|
||||
|
||||
- 统一在结算页做自动命中展示
|
||||
- 只在必要时说明不可叠加或已自动选择最优方案
|
||||
|
||||
### 6.3 结算页“优惠资产区”职责太宽，容易变成规则堆场
|
||||
|
||||
原因：
|
||||
|
||||
- 旧文档没有区分：
|
||||
- 用户主动选择
|
||||
- 系统自动命中
|
||||
- 仅提示的会员权益
|
||||
|
||||
调整：
|
||||
|
||||
- 分成三个层次：
|
||||
- 手动资产
|
||||
- 自动优惠
|
||||
- 权益提示
|
||||
|
||||
### 6.4 `C05` 不能直接展开成通用多支付方式收银台
|
||||
|
||||
原因：
|
||||
|
||||
- 当前小程序信息架构明确写的是 `微信支付 / 余额支付`
|
||||
- 后台记录里虽然存在 `alipay / cash / card`，但那是后台订单/交易口径，不等于小程序都支持
|
||||
|
||||
调整：
|
||||
|
||||
- 小程序支付方式先收敛到微信支付和余额支付
|
||||
- 其他支付方式只保留后台记录兼容，不前置到小程序
|
||||
|
||||
### 6.5 次卡不应在结算页做成“无差别通用抵扣”
|
||||
|
||||
原因：
|
||||
|
||||
- 后台次卡有明确适用范围：
|
||||
- 全部
|
||||
- 分类
|
||||
- 商品
|
||||
- 标签
|
||||
- 还带单日上限、单单上限、补差金额
|
||||
|
||||
调整：
|
||||
|
||||
- 结算页只在命中商品时展示可用次卡
|
||||
- 并明确“使用后剩余次数 / 是否需要补差”
|
||||
|
||||
### 6.6 会员等级权益不应只在会员中心展示，不进入结算
|
||||
|
||||
原因：
|
||||
|
||||
- 后台会员权益明确包含：
|
||||
- 折扣
|
||||
- 免配送费
|
||||
- 月券
|
||||
- 生日券
|
||||
- 会员日额外折扣
|
||||
|
||||
调整：
|
||||
|
||||
- 会员中心解释规则
|
||||
- 结算页展示当前订单已享受的权益结果
|
||||
|
||||
### 6.7 结算页如果不解释金额来源，会和前两批链路断裂
|
||||
|
||||
原因：
|
||||
|
||||
- 第 1 批已经确认门店费用会影响支付金额
|
||||
- 第 2 批已经确认商品级包装费和商品组合会影响金额
|
||||
- 如果结算页只显示一个总价，顾客无法理解为什么变了
|
||||
|
||||
调整：
|
||||
|
||||
- 费用明细必须把门店费用、商品费用、优惠减免拆清楚
|
||||
|
||||
### 6.8 支付成功页过于轻，会丢失场景关键上下文
|
||||
|
||||
原因：
|
||||
|
||||
- 自提用户需要立即知道取餐时间
|
||||
- 堂食用户需要回到当前桌号上下文
|
||||
- 外卖用户最关心预计送达
|
||||
|
||||
调整：
|
||||
|
||||
- 支付成功页必须按场景给出下一步最关键的信息
|
||||
|
||||
---
|
||||
|
||||
## 7. 本批次冻结后的映射结论
|
||||
|
||||
### 7.1 直接承接
|
||||
|
||||
- 结算页履约信息确认
|
||||
- 商品清单与费用明细
|
||||
- 优惠券选择
|
||||
- 储值余额支付
|
||||
- 次卡核销
|
||||
- 自动优惠命中结果
|
||||
- 微信支付 / 余额支付
|
||||
- 支付成功结果页
|
||||
|
||||
### 7.2 间接支撑
|
||||
|
||||
- 满减活动配置细节
|
||||
- 新客有礼邀请机制
|
||||
- 会员等级升级规则
|
||||
- 后台财务支付渠道与记账口径
|
||||
- 储值卡充值后台记录结构
|
||||
|
||||
### 7.3 暂不冻结为正式前台能力
|
||||
|
||||
- 订单级积分抵扣
|
||||
|
||||
需要后续补充明确的订单侧接口或规则来源后，再决定是否进入结算主流程。
|
||||
|
||||
### 7.4 本批次新增约束
|
||||
|
||||
- 结算页必须区分手动资产和自动优惠
|
||||
- 小程序支付方式先收敛为微信支付和余额支付
|
||||
- 次卡只在命中商品范围时出现
|
||||
- 会员权益主要展示“已享受结果”，不是让用户手动配置
|
||||
- 金额明细必须可解释
|
||||
|
||||
---
|
||||
|
||||
## 8. 对下一批的依赖
|
||||
|
||||
下一批做履约、订单、售后链路时，需要直接继承本批次前提：
|
||||
|
||||
- 订单详情里要能回看支付方式、支付时间、优惠金额和实付金额
|
||||
- 订单状态页要能承接支付成功后的不同场景信息
|
||||
- 待支付订单要沿用本批次支付方式口径
|
||||
- 退款和售后要基于本批次已经确定的金额结构做解释
|
||||
489
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md
Normal file
489
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md
Normal file
@@ -0,0 +1,489 @@
|
||||
# B04 履约、订单与售后链路
|
||||
|
||||
## 1. 批次目标
|
||||
|
||||
本批次解决的是：
|
||||
|
||||
顾客支付完成后，订单页该怎么组织、订单详情该承接哪些履约信息、退款和评价哪些能直接落到小程序页面、哪些只是后台支撑，以及旧版原型里哪些动作设计得过满、过早、过像商家后台。
|
||||
|
||||
这一批不再讨论“怎么结算”，而是讨论：
|
||||
|
||||
- 顾客怎么看自己的订单
|
||||
- 顾客能看到哪些履约状态
|
||||
- 售后结果如何承接
|
||||
- 评价入口应该收敛到什么程度
|
||||
|
||||
---
|
||||
|
||||
## 2. 证据源
|
||||
|
||||
### 后台真实来源
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/order/index.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/order-hall/index.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/transaction.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/files.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/points-mall.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/order/list`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/order/hall`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/transaction`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/points-mall`
|
||||
|
||||
### 已完成批次依赖
|
||||
|
||||
- `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
|
||||
|
||||
### 旧版小程序参考
|
||||
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/07-页面规格/03-Tab-订单页.md`
|
||||
- `docs/07-页面规格/11-订单详情页.md`
|
||||
- `docs/07-页面规格/12-退款申请页.md`
|
||||
- `docs/07-页面规格/13-退款详情页.md`
|
||||
- `docs/07-页面规格/14-评价页.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 后台真实功能清单
|
||||
|
||||
| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 全部订单列表 | 按 `storeId` 查询订单；支持 `status / channel / paymentMethod / keyword / date` 筛选；返回订单号、商品摘要、金额、下单时间、状态 | 是，但后台是商家视角、门店视角 | `T03` | 直接承接结构，但不能原样复用接口 |
|
||||
| 全部订单统计 | 返回 `totalOrders / totalAmount / averageAmount / refundCount` | 部分可感知 | `T03` 轻量统计或空态辅助 | 间接支撑为主 |
|
||||
| 全部订单详情 | 返回顾客信息、地址、商品明细、配送费、优惠金额、实付金额、支付方式、时间线、备注 | 是 | `P05` | 直接承接 |
|
||||
| 订单大厅看板 | 四列状态 `pending / making / delivering / completed`，并按 `deliveryType` 区分外卖/自提/堂食 | 结果可感知，但表达方式是商家操作视角 | `T03`、`P05` 状态翻译支撑 | 间接支撑为主 |
|
||||
| 商家履约动作 | `accept / reject / complete-preparation / confirm-delivery` | 否 | 不应直接前置 | 间接支撑 |
|
||||
| 履约辅助字段 | 看板卡片包含 `tableNo / isUrged / urgeCount`，并按履约类型展示不同状态文案 | 部分可感知 | `P05` 场景信息区、状态头图预留 | 有价值，但当前顾客侧契约不完整 |
|
||||
| 退款交易记录 | 订单统计有 `refundCount`，交易详情包含 `refundNo / refundReason` | 是，至少退款结果可见 | `P05`、`P07` | 结果承接成立 |
|
||||
| 评价图片上传 | 文件上传类型包含 `review_image` | 是 | `P08` | 直接承接 |
|
||||
| 评价奖励积分规则 | 积分规则包含 `reviewRewardPoints` | 结果可感知 | `P08` 成功反馈、`我的资产` 联动 | 间接支撑为主 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 后台字段到 C 端的映射结论
|
||||
|
||||
## 4.1 可以直接前置给顾客的信息
|
||||
|
||||
- 订单状态
|
||||
- 履约场景类型
|
||||
- 商品摘要与金额
|
||||
- 下单时间、支付时间、完成时间
|
||||
- 配送地址、收货人、联系电话
|
||||
- 优惠减免、配送费、实付金额
|
||||
- 订单时间线
|
||||
- 备注
|
||||
- 退款结果信息
|
||||
|
||||
这些信息都已经在后台订单列表、订单详情或交易详情里有明确结构，小程序可以直接承接为：
|
||||
|
||||
- `T03` 的订单卡扫读信息
|
||||
- `P05` 的详情主体内容
|
||||
- `P07` 的退款结果页
|
||||
|
||||
## 4.2 订单状态翻译规则
|
||||
|
||||
后台的订单状态本身已经比较完整，但小程序不能把商家管理口径原样扔给顾客，而要翻译成顾客任务语言。
|
||||
|
||||
| 后台来源 | 后台状态口径 | 小程序表达 | 归属页签 | 说明 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `order-hall` 状态映射 | `待付款` | `待支付` | `待支付` | 与第 3 批继续支付链路直接衔接 |
|
||||
| `order/all` 状态筛选 | `pending` | `待接单 / 商家处理中` | `进行中` | 顾客能看懂即可，不需要暴露后台枚举值 |
|
||||
| `order/all` 状态筛选 | `making` | `制作中` | `进行中` | 全场景可复用 |
|
||||
| `order/all` 状态筛选 | `delivering` | `配送中` | `进行中` | 外卖主场景 |
|
||||
| `order/all` 状态筛选 | `pickup` | `待取餐` | `进行中` | 自提主场景 |
|
||||
| `order/all` 状态筛选 | `completed` | `已完成` | `已完成` | 承接评价与复购 |
|
||||
| `order/all` 状态筛选 | `cancelled` | `已取消` | `全部` | 结果态，只读为主 |
|
||||
| `order/all` 状态筛选 | `refunded` | `退款完成 / 售后完成` | `售后` | 承接退款详情 |
|
||||
|
||||
结论：
|
||||
|
||||
- 小程序顶层筛选仍然建议保持顾客视角：`全部 / 待支付 / 进行中 / 已完成 / 售后`
|
||||
- 后台更细的 `pending / making / delivering / pickup` 用于驱动卡片文案和详情头图，不直接全部上翻为一级页签
|
||||
|
||||
## 4.3 只能作为后台支撑，不应直接复制到顾客端的能力
|
||||
|
||||
- 看板四列布局
|
||||
- 接单
|
||||
- 拒单
|
||||
- 出餐完成
|
||||
- 确认送达 / 确认取餐
|
||||
- 看板连接状态
|
||||
- 看板语音提醒
|
||||
- 今日总单数等商家运营统计
|
||||
|
||||
这些能力是商家处理订单用的，不是顾客任务。
|
||||
|
||||
小程序只需要承接这些动作执行后的结果，例如：
|
||||
|
||||
- 商家已接单
|
||||
- 商品制作中
|
||||
- 已可取餐
|
||||
- 已送达
|
||||
|
||||
而不是让顾客看到商家后台的操作按钮。
|
||||
|
||||
## 4.4 当前证据不足，不应先写成确定的前台能力
|
||||
|
||||
- 骑手轨迹
|
||||
- 精确预计送达时间
|
||||
- 自提取餐码 / 取餐号
|
||||
- 完整堂食订单详情桌号回显
|
||||
- 顾客主动催单接口
|
||||
- 顾客退款申请接口及其可退范围规则
|
||||
- 评价提交接口
|
||||
- 评价标签、匿名、商家回复等扩展契约
|
||||
|
||||
原因不是这些能力一定不存在，而是当前在 `TenantUI` 中看到的是：
|
||||
|
||||
- 商家履约结果
|
||||
- 后台订单查看结构
|
||||
- 退款交易结果
|
||||
- 评价图片上传与评价奖励规则
|
||||
|
||||
但还没有看到完整的顾客端提交契约。
|
||||
|
||||
因此本批次可以冻结“页面职责”，但不把这些扩展动作冻结成已经被后台完全证实的正式前台能力。
|
||||
|
||||
## 4.5 当前从 `TenantUI` 映射到小程序还缺的关键订单契约
|
||||
|
||||
这一步是本批最重要的一个结论：
|
||||
|
||||
`TenantUI` 的订单接口可以作为小程序设计事实源，但不能直接当成小程序最终接口复用。
|
||||
|
||||
原因有四个：
|
||||
|
||||
1. `order/all` 是商家按 `storeId` 查单，小程序应是顾客按本人订单查单
|
||||
2. 订单列表和详情当前默认建立在“后台已选门店”前提上，因此不天然携带完整门店快照
|
||||
3. 订单详情当前没有明确的顾客动作标记，例如：
|
||||
- 是否还能继续支付
|
||||
- 是否允许退款
|
||||
- 是否已评价 / 可评价
|
||||
4. 场景补充字段还不完整，例如：
|
||||
- 自提的取餐号
|
||||
- 堂食的桌号回显
|
||||
- 外卖的配送进度扩展信息
|
||||
|
||||
所以本批次对小程序的正确做法不是“照搬后台接口”，而是：
|
||||
|
||||
- 沿用后台已确认的数据结构和状态口径
|
||||
- 补一层顾客视角的聚合与动作字段
|
||||
- 让 `T03 / P05 / P06 / P07 / P08` 围绕顾客任务建模，而不是围绕商家查单表建模
|
||||
|
||||
---
|
||||
|
||||
## 5. 小程序页面重映射
|
||||
|
||||
## 5.1 `T03 订单页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 让顾客快速找到自己的订单
|
||||
- 先看懂“现在进行到哪一步”
|
||||
- 再决定下一步动作
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 顶部主筛选建议固定为：
|
||||
- 全部
|
||||
- 待支付
|
||||
- 进行中
|
||||
- 已完成
|
||||
- 售后
|
||||
- 场景筛选 `外卖 / 自提 / 堂食` 可以保留，但应该是二级过滤，不是主信息架构
|
||||
- 订单卡片至少展示：
|
||||
- 门店名称
|
||||
- 订单状态
|
||||
- 场景标签
|
||||
- 商品摘要
|
||||
- 订单金额
|
||||
- 下单时间
|
||||
- 卡片动作必须按状态收敛：
|
||||
- `待支付`：继续支付、取消订单
|
||||
- `进行中`：查看详情
|
||||
- `已完成`：去评价、再来一单
|
||||
- `售后`：查看退款详情
|
||||
|
||||
### 这一页不该承担什么
|
||||
|
||||
- 不应直接复制商家后台的 `待接单 / 制作中 / 配送中 / 待取餐` 四列看板
|
||||
- 不应把后台 `支付方式`、`日期区间`、`关键字` 等管理筛选照搬给顾客
|
||||
- 不应把 `催单 / 取餐码 / 再来一单` 做成所有订单都出现的固定按钮
|
||||
|
||||
## 5.2 `P05 订单详情页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 把订单完整讲清楚
|
||||
- 让顾客理解当前状态
|
||||
- 给出当前状态下唯一有价值的动作
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 顶部状态头图区必须明确表达当前状态，不用后台术语堆字典
|
||||
- 履约信息区按场景拆开：
|
||||
- 外卖：
|
||||
- 收货地址
|
||||
- 收货人
|
||||
- 联系方式
|
||||
- 状态时间线
|
||||
- 自提：
|
||||
- 门店信息
|
||||
- 取餐提示
|
||||
- 状态时间线
|
||||
- 堂食：
|
||||
- 门店信息
|
||||
- 桌号回显
|
||||
- 状态时间线
|
||||
- 商品区、费用区、订单基础信息区继续继承第 3 批结论：
|
||||
- 商品明细
|
||||
- 优惠减免
|
||||
- 配送费
|
||||
- 实付金额
|
||||
- 支付方式
|
||||
- 支付时间
|
||||
- 备注
|
||||
- 底部操作栏按状态与场景组合判断：
|
||||
- `待支付`：继续支付、取消订单
|
||||
- `进行中`：查看履约信息
|
||||
- `已完成`：去评价、再来一单
|
||||
- `售后`：查看退款进度
|
||||
|
||||
### 当前必须收住的地方
|
||||
|
||||
- 外卖详情页不要先冻结成“骑手轨迹页”
|
||||
- 自提详情页不要强制写死“取餐码一定存在”
|
||||
- 堂食详情页不要重新引入“继续加菜 / 合单 / 先付款”这类第 1 批已判定不稳的能力
|
||||
- 订单详情页不要复用商家侧 `接单 / 拒单 / 出餐完成 / 确认送达` 按钮逻辑
|
||||
|
||||
## 5.3 `P06 退款申请页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 在订单允许申请售后时，低阻力提交一份退款申请
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 页面内容先收敛到最小闭环：
|
||||
- 可退款订单摘要
|
||||
- 可退金额
|
||||
- 退款原因
|
||||
- 补充说明
|
||||
- 提交按钮
|
||||
- 图片凭证上传可以保留预留位，但当前不冻结为必做
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- `P06` 可以保留为正式页面
|
||||
- 但退款原因枚举、部分退款、按商品逐项退款、处理 SLA 等复杂规则，当前不冻结
|
||||
- 页面是否显示入口，应由订单详情里的状态和后端能力标记决定
|
||||
|
||||
## 5.4 `P07 退款详情页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 给顾客一个稳定的退款结果查看页
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 结果页至少包括：
|
||||
- 退款状态
|
||||
- 退款金额
|
||||
- 退款原因
|
||||
- 处理时间线
|
||||
- 关联订单信息
|
||||
- 如果后端后续补充驳回原因，应直接进入该页展示
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- `P07` 是可以成立的，因为后台已经有：
|
||||
- 退款统计
|
||||
- 退款交易明细
|
||||
- 退款单号 / 退款原因
|
||||
- 但时间线节点名称和处理阶段数量暂时不写死
|
||||
|
||||
## 5.5 `P08 评价页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 让顾客在订单完成后提交最小可用评价
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 当前最稳妥的页面能力是：
|
||||
- 订单摘要
|
||||
- 评分
|
||||
- 文本评价
|
||||
- 晒图上传
|
||||
- 提交按钮
|
||||
- 评价成功后可以轻提示“获得积分奖励”，但不能让奖励提示反过来主导页面
|
||||
|
||||
### 当前必须收住的地方
|
||||
|
||||
- 快捷评价标签不冻结为必做
|
||||
- 匿名开关不冻结为必做
|
||||
- 商家回复闭环不冻结为本批范围
|
||||
- 评价成功奖励样式可以做轻提示，但不应做成复杂营销弹窗
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前发现的不合理设计点
|
||||
|
||||
### 6.1 旧订单页把顾客页做得太像商家订单看板，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 商家关心的是处理效率
|
||||
- 顾客关心的是“我这单现在怎么样、下一步做什么”
|
||||
|
||||
调整：
|
||||
|
||||
- 小程序订单页用顾客任务语言分组
|
||||
- 更细的履约阶段下沉到卡片文案和详情页
|
||||
|
||||
### 6.2 商家履约动作不应进入顾客端动作栏
|
||||
|
||||
原因：
|
||||
|
||||
- `接单 / 拒单 / 出餐完成 / 确认送达` 都是商家动作
|
||||
|
||||
调整：
|
||||
|
||||
- 顾客只看结果，不看操作按钮
|
||||
|
||||
### 6.3 旧订单详情把外卖、自提、堂食能力写得过满
|
||||
|
||||
原因：
|
||||
|
||||
- 当前真实详情结构没有完全覆盖：
|
||||
- 骑手轨迹
|
||||
- 自提码
|
||||
- 堂食桌号
|
||||
|
||||
调整：
|
||||
|
||||
- 先冻结“场景信息区必须有”
|
||||
- 但具体字段以当前已证实结构和后续补充契约为准
|
||||
|
||||
### 6.4 `T03` 不能直接照搬后台筛选器
|
||||
|
||||
原因：
|
||||
|
||||
- 后台筛选器服务的是商家查单
|
||||
- 小程序订单页服务的是顾客找单
|
||||
|
||||
调整：
|
||||
|
||||
- 小程序主筛选只保留高频状态页签
|
||||
- 管理型筛选全部收掉
|
||||
|
||||
### 6.5 `order/all` 的 `storeId` 查询前提，不适合直接当 C 端查单接口
|
||||
|
||||
原因：
|
||||
|
||||
- 顾客会跨门店下单
|
||||
- 订单页必须能展示门店名称
|
||||
- 顾客不应该先选门店再查自己的订单
|
||||
|
||||
调整：
|
||||
|
||||
- 小程序订单接口应改为顾客维度聚合查询
|
||||
- 后台现有结构只作为字段和状态参考
|
||||
|
||||
### 6.6 退款页当前不能写成完整售后系统
|
||||
|
||||
原因：
|
||||
|
||||
- 现有后台证据更偏向退款结果记录
|
||||
- 还没看到完整顾客退款申请契约
|
||||
|
||||
调整：
|
||||
|
||||
- `P06 / P07` 保留
|
||||
- 但页面职责收敛到“申请入口 + 结果查看”
|
||||
|
||||
### 6.7 评价页当前不能预设太多运营玩法
|
||||
|
||||
原因：
|
||||
|
||||
- 当前能确认的是：
|
||||
- 可上传评价图片
|
||||
- 可配置评价奖励积分
|
||||
- 不能确认的是：
|
||||
- 评价提交结构
|
||||
- 标签体系
|
||||
- 匿名规则
|
||||
- 商家回复
|
||||
|
||||
调整：
|
||||
|
||||
- `P08` 先做最小评价闭环
|
||||
- 扩展玩法后补
|
||||
|
||||
### 6.8 `催单 / 取餐信息 / 再来一单` 不能做成固定动作
|
||||
|
||||
原因：
|
||||
|
||||
- 这些动作强依赖订单状态和场景
|
||||
- 有些还有接口契约缺口
|
||||
|
||||
调整：
|
||||
|
||||
- 所有动作都由状态机控制显示
|
||||
- 不做“每张卡片一套固定按钮”
|
||||
|
||||
---
|
||||
|
||||
## 7. 本批次冻结后的映射结论
|
||||
|
||||
## 7.1 直接承接
|
||||
|
||||
- 订单页顾客视角筛选与订单卡
|
||||
- 订单详情的状态、商品、金额、时间线、支付信息
|
||||
- 退款结果页
|
||||
- 最小评价提交页
|
||||
- 基于状态的继续支付 / 去评价 / 查看退款详情
|
||||
|
||||
## 7.2 间接支撑
|
||||
|
||||
- 商家订单看板四列与履约统计
|
||||
- 商家接单、拒单、出餐、确认动作
|
||||
- 催单状态痕迹
|
||||
- 退款交易明细结构
|
||||
- 评价奖励积分规则
|
||||
|
||||
## 7.3 暂不冻结为正式前台能力
|
||||
|
||||
- 骑手轨迹
|
||||
- 精确送达时间
|
||||
- 自提码 / 取餐号
|
||||
- 顾客催单
|
||||
- 复杂退款规则
|
||||
- 评价标签、匿名、商家回复
|
||||
|
||||
其中堂食桌号回显属于“业务上应该有，但当前详情契约证据不足”的字段，后续需要补到顾客侧订单详情结构中。
|
||||
|
||||
## 7.4 本批次新增约束
|
||||
|
||||
- `T03` 必须用顾客任务语言分组，不镜像商家看板
|
||||
- `P05` 动作栏必须由状态和场景共同决定
|
||||
- `P05` 要能回看第 3 批已冻结的支付与金额结构
|
||||
- `P06 / P07 / P08` 可以保留正式页面，但先做轻量闭环
|
||||
- 小程序订单能力应基于顾客维度聚合，不直接照搬后台 `storeId` 查单模式
|
||||
|
||||
---
|
||||
|
||||
## 8. 对下一批的依赖
|
||||
|
||||
下一批做“我的、资产、消息、复购链路”时，需要直接继承本批次结论：
|
||||
|
||||
- 我的页要能承接最近订单、退款结果、待评价入口
|
||||
- 资产页里的积分奖励提示要和评价结果联动
|
||||
- 消息中心如果后续承接履约通知、退款通知，要沿用本批次订单状态翻译口径
|
||||
- 如果后续补齐顾客侧订单契约，应优先补：
|
||||
- 门店快照
|
||||
- 顾客动作标记
|
||||
- 自提 / 堂食补充字段
|
||||
- 退款 / 评价状态字段
|
||||
620
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md
Normal file
620
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md
Normal file
@@ -0,0 +1,620 @@
|
||||
# B05 我的、资产、消息与复购链路
|
||||
|
||||
## 1. 批次目标
|
||||
|
||||
本批次解决的是：
|
||||
|
||||
顾客进入“我的”之后，哪些内容应该作为身份与资产总览集中展示，哪些资产页可以独立成立，哪些消息与服务入口现在只能保留轻入口，哪些复购信息可以直接承接，哪些还只是后台运营或客户分析能力，不能直接写成小程序正式页面契约。
|
||||
|
||||
这一批不讨论活动导购和拉新曝光，那部分留给下一批。
|
||||
|
||||
本批重点处理：
|
||||
|
||||
- `T04 我的页`
|
||||
- 会员中心
|
||||
- 积分商城
|
||||
- 储值充值
|
||||
- 次卡页
|
||||
- 消息中心入口与页面边界
|
||||
- “最近订单 / 常点商品 / 再来一单”这一类复购承接
|
||||
|
||||
---
|
||||
|
||||
## 2. 证据源
|
||||
|
||||
### 后台真实来源
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/index.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/stored-card.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/points-mall.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/message-reach.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/index.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/punch-card.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/list`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/stored-card`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/points-mall`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/message-reach`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/coupon`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/punch-card`
|
||||
|
||||
### 辅助来源
|
||||
|
||||
以下来源不是本批主源，但对“成长值”和“复购推荐”有补充价值：
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/customer/index.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/customer/profile`
|
||||
|
||||
### 已完成批次依赖
|
||||
|
||||
- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md`
|
||||
|
||||
### 旧版小程序参考
|
||||
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/07-页面规格/04-Tab-我的页.md`
|
||||
- `docs/07-页面规格/18-会员中心页.md`
|
||||
- `docs/07-页面规格/19-积分商城页.md`
|
||||
- `docs/07-页面规格/20-储值充值页.md`
|
||||
- `docs/07-页面规格/21-次卡页.md`
|
||||
- `docs/07-页面规格/22-消息中心页.md`
|
||||
- `docs/07-页面规格/23-帮助中心页.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 后台真实功能清单
|
||||
|
||||
| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 会员详情 | 会员名、入会时间、等级、积分余额、储值余额、最近订单、累计消费、标签 | 是 | `T04`、会员中心、复购区 | 直接承接 |
|
||||
| 会员等级体系 | 等级列表、升级规则、折扣、积分倍率、生日券、每月赠券、免配送费、优先配送、会员日 | 是 | 会员中心、结算权益提示 | 直接承接为主 |
|
||||
| 储值卡方案 | 充值金额、赠送金额、到账金额、状态、排序、统计 | 是 | 储值充值页 | 直接承接 |
|
||||
| 储值充值记录 | 会员、充值金额、赠送金额、到账金额、支付方式、时间 | 是 | 储值充值页、资产记录 | 直接承接 |
|
||||
| 积分规则 | 消费赠分、评价赠分、注册赠分、签到赠分、有效期规则 | 规则可感知 | 积分商城说明、评价后奖励提示 | 直接承接为主 |
|
||||
| 积分商城商品 | 兑换商品、兑换类型 `coupon / product / physical`、兑换方式 `points / mixed`、库存、限购 | 是 | 积分商城页 | 直接承接 |
|
||||
| 积分兑换记录 | 兑换记录、状态、核销方式、核销备注 | 是 | 积分商城页记录 Tab | 直接承接 |
|
||||
| 消息触达 | 消息模板、发送渠道 `inapp / sms / wechat-mini`、目标人群、发送状态、阅读率、转化率 | 顾客最终可能感知，但当前看到的是运营发送后台 | 消息中心来源层 / 未来扩展 | 间接支撑为主 |
|
||||
| 优惠券模板 | 券类型、门槛、有效期、适用门店、适用渠道、限领规则 | 顾客可感知结果，但当前主要是模板管理 | 我的页券入口、领券中心入口 | 间接支撑为主 |
|
||||
| 次卡模板 | 售价、总次数、适用范围、有效期、可转赠、补差规则 | 是 | 次卡页、结算页次卡选择 | 直接承接为主 |
|
||||
| 次卡使用记录 | 次卡实例号、使用商品、剩余次数、使用时间、补差金额 | 是 | 次卡记录页 / 订单联动 | 结果承接成立 |
|
||||
| 客户画像辅助信息 | 成长值、常购商品、复购率、偏好、最近订单 | 是，但来源属于客户分析域 | `T04` 复购区、会员成长说明 | 辅助支撑 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 后台字段到 C 端的映射结论
|
||||
|
||||
## 4.1 `T04 我的页` 应该是聚合页，不是资产真源
|
||||
|
||||
这是本批最重要的一个结构结论。
|
||||
|
||||
“我的页”不应该自己定义一套完整资产规则，它真正的职责是：
|
||||
|
||||
- 汇总当前身份
|
||||
- 汇总高频资产
|
||||
- 汇总订单快捷入口
|
||||
- 汇总高价值服务入口
|
||||
- 汇总复购入口
|
||||
|
||||
也就是说：
|
||||
|
||||
- 会员等级信息来自会员域
|
||||
- 积分与积分商品来自积分商城域
|
||||
- 储值余额与充值方案来自储值卡域
|
||||
- 次卡信息来自次卡域
|
||||
- 订单快捷入口来自订单域
|
||||
- 消息和帮助更像服务入口，不是“我的页”自己拥有的数据模型
|
||||
|
||||
因此：
|
||||
|
||||
- `T04` 只做“聚合 + 导航 + 轻摘要”
|
||||
- 不做复杂规则解释页
|
||||
- 不做完整记录页
|
||||
- 不做后台配置镜像
|
||||
|
||||
## 4.2 当前可以直接前置给顾客的信息
|
||||
|
||||
- 当前会员等级
|
||||
- 入会时间
|
||||
- 积分余额
|
||||
- 储值余额
|
||||
- 储值实充 / 赠送拆分
|
||||
- 最近订单
|
||||
- 当前可享会员权益
|
||||
- 积分商城商品与兑换记录
|
||||
- 储值充值方案与充值记录
|
||||
- 次卡模板信息
|
||||
- 次卡使用结果信息
|
||||
|
||||
这些信息都已经在后台接口或辅助画像接口里有较清晰结构，小程序可以直接承接成：
|
||||
|
||||
- `T04` 的头部摘要与入口区
|
||||
- 会员中心页
|
||||
- 积分商城页
|
||||
- 储值充值页
|
||||
- 次卡页中的模板与记录区
|
||||
|
||||
## 4.3 当前只能保留入口或摘要，不应先冻结数量/明细的项
|
||||
|
||||
- 优惠券数量
|
||||
- 我的优惠券列表
|
||||
- 我的次卡实例列表
|
||||
- 我的次卡剩余次数总览
|
||||
- 订单快捷入口上的状态角标数量
|
||||
- 消息未读数
|
||||
|
||||
原因：
|
||||
|
||||
- 当前后台能看到的是优惠券模板，不是顾客已领取券包
|
||||
- 当前后台能看到的是次卡模板和使用记录，不是顾客持有的完整实例清单
|
||||
- 当前后台订单域已支持列表和详情，但还没有顾客维度的快捷计数摘要
|
||||
- 当前后台消息触达是发送中心，不是顾客 inbox
|
||||
|
||||
因此：
|
||||
|
||||
- `T04` 可以保留这些入口
|
||||
- 但不要先把数量角标冻结为正式能力
|
||||
|
||||
## 4.4 当前从 `TenantUI` 映射到小程序，还缺的关键聚合契约
|
||||
|
||||
如果未来要把 `T04` 做稳，至少还需要一层“顾客资产聚合接口”。
|
||||
|
||||
理想上需要补出的字段包括：
|
||||
|
||||
- 顾客基础信息：
|
||||
- 昵称 / 展示名
|
||||
- 头像
|
||||
- 当前会员等级
|
||||
- 入会时间
|
||||
- 资产摘要：
|
||||
- couponCount
|
||||
- pointsBalance
|
||||
- storedBalance
|
||||
- storedGiftBalance
|
||||
- punchCardCount
|
||||
- punchCardRemainSummary
|
||||
- 订单快捷摘要：
|
||||
- pendingPayCount
|
||||
- inProgressCount
|
||||
- completedCount
|
||||
- afterSaleCount
|
||||
- 服务摘要：
|
||||
- unreadMessageCount
|
||||
- 复购摘要：
|
||||
- recentOrders
|
||||
- topProducts
|
||||
|
||||
在当前证据下：
|
||||
|
||||
- 会员、积分、储值、最近订单分别都有来源
|
||||
- 但它们分散在多个后台页面和业务域里
|
||||
- 还没有一个面向顾客的统一聚合契约
|
||||
|
||||
## 4.5 会员成长值与升级进度，当前不能写得太满
|
||||
|
||||
旧原型把会员中心写成：
|
||||
|
||||
- 当前等级
|
||||
- 成长值
|
||||
- 距离下一等级差值
|
||||
- 升级路径说明
|
||||
|
||||
这里需要收住。
|
||||
|
||||
当前已确认的事实是：
|
||||
|
||||
- 会员域有等级规则和等级权益
|
||||
- 客户画像辅助域里有 `growthValue`
|
||||
- 会员详情里有当前等级与入会时间
|
||||
|
||||
但当前没有看到一个专门面向顾客的“当前进度 -> 下一等级差多少”的成型契约。
|
||||
|
||||
所以本批次冻结为：
|
||||
|
||||
- 会员中心一定可以展示当前等级和当前权益
|
||||
- 升级规则可以展示为等级体系说明
|
||||
- “距离下一等级还差多少”保留为可扩展能力，不冻结为强必做
|
||||
|
||||
## 4.6 消息触达不等于顾客消息中心
|
||||
|
||||
这是本批第二个必须写死的边界。
|
||||
|
||||
`member/message-reach` 当前真实表达的是：
|
||||
|
||||
- 运营人员创建消息
|
||||
- 选择渠道
|
||||
- 选择目标人群
|
||||
- 定时或立即发送
|
||||
- 看送达、阅读、转化结果
|
||||
|
||||
这和顾客在小程序里看到的“消息中心”不是一回事。
|
||||
|
||||
顾客端真正需要的是：
|
||||
|
||||
- 收到什么消息
|
||||
- 有没有未读
|
||||
- 点开后跳去哪个业务页面
|
||||
|
||||
而不是：
|
||||
|
||||
- 消息发送状态
|
||||
- 受众估算
|
||||
- 模板分类
|
||||
- 阅读率、转化率
|
||||
|
||||
所以：
|
||||
|
||||
- `P16 消息中心` 这个页面可以保留
|
||||
- 但不能拿 `message-reach` 页面直接映射过去
|
||||
- `message-reach` 只能作为未来消息内容来源、通知渠道来源和后台运营配置来源
|
||||
|
||||
## 4.7 帮助中心当前没有明确后台事实源
|
||||
|
||||
当前在 `TenantUI` 中没有看到成型的：
|
||||
|
||||
- FAQ 配置
|
||||
- 帮助分类配置
|
||||
- 客服联系方式配置
|
||||
- 帮助文章 CMS
|
||||
|
||||
因此：
|
||||
|
||||
- 帮助中心在信息架构上可以保留为服务兜底页
|
||||
- 但本批次不能把它写成有完整后台支撑的正式能力
|
||||
|
||||
## 4.8 领券中心完整导购链路不在本批冻结
|
||||
|
||||
`T04` 可以有领券入口，但本批不展开完整领券中心细节。
|
||||
|
||||
原因：
|
||||
|
||||
- 本批是“我的 / 资产 / 消息 / 复购”
|
||||
- 领券中心更偏“活动导购与增长”
|
||||
- 当前后台能确认的是券模板和发券规则
|
||||
- 顾客已领取券包、券资产角标、券使用闭环，还没有在本批作为稳定主线收口
|
||||
|
||||
结论：
|
||||
|
||||
- `T04` 保留领券入口
|
||||
- 完整领券中心映射继续放在下一批处理
|
||||
|
||||
---
|
||||
|
||||
## 5. 小程序页面重映射
|
||||
|
||||
## 5.1 `T04 我的页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 身份摘要
|
||||
- 资产摘要
|
||||
- 订单快捷入口
|
||||
- 服务入口
|
||||
- 复购入口
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 头部卡先展示最稳的身份信息：
|
||||
- 头像
|
||||
- 展示名
|
||||
- 当前会员等级
|
||||
- 入会信息
|
||||
- 资产总览区先收敛到已证实的项：
|
||||
- 积分
|
||||
- 储值余额
|
||||
- 会员权益入口
|
||||
- 订单快捷入口直接继承第 4 批：
|
||||
- 待支付
|
||||
- 进行中
|
||||
- 已完成
|
||||
- 售后
|
||||
- 服务入口以跳转为主：
|
||||
- 地址管理
|
||||
- 消息中心
|
||||
- 帮助中心
|
||||
- 复购区以轻推荐为主：
|
||||
- 最近订单
|
||||
- 常点商品
|
||||
- 再来一单
|
||||
|
||||
### 当前必须收住的地方
|
||||
|
||||
- 不要把“优惠券数量 / 次卡数量 / 未读消息数”全都写死在首页
|
||||
- 不要把“我的页”做成每个资产的完整记录页
|
||||
- 不要在头部卡过度强调成长值进度条
|
||||
|
||||
## 5.2 会员中心
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 告诉顾客自己现在是什么等级
|
||||
- 告诉顾客当前能享受什么权益
|
||||
- 告诉顾客等级体系如何运作
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 头部区：
|
||||
- 当前等级
|
||||
- 等级标识
|
||||
- 入会时间
|
||||
- 权益区：
|
||||
- 折扣权益
|
||||
- 积分倍率
|
||||
- 生日权益
|
||||
- 每月赠券
|
||||
- 免配送费
|
||||
- 优先配送
|
||||
- 会员日额外权益
|
||||
- 规则说明区：
|
||||
- 升级条件
|
||||
- 降级窗口
|
||||
- 各等级权益差异
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- 当前等级与权益是确定能力
|
||||
- 会员日和生日权益是确定能力
|
||||
- “距离下一等级还差多少”暂不冻结为强必做
|
||||
|
||||
## 5.3 积分商城
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 展示积分余额
|
||||
- 展示积分能换什么
|
||||
- 展示已经换过什么
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 顶部先说明：
|
||||
- 当前积分余额
|
||||
- 积分获取方式摘要
|
||||
- 商品列表承接真实商品模型：
|
||||
- 商品兑换
|
||||
- 券兑换
|
||||
- 实物兑换
|
||||
- 记录页承接真实记录模型：
|
||||
- 兑换时间
|
||||
- 兑换内容
|
||||
- 积分消耗
|
||||
- 当前状态
|
||||
|
||||
### 当前必须收住的地方
|
||||
|
||||
- 核销动作是商家侧能力，不是顾客侧主操作
|
||||
- `notifyChannels` 是通知渠道配置，不是顾客手动设置项
|
||||
- 积分商城不要反向扩成“订单积分抵扣总入口”
|
||||
|
||||
## 5.4 储值充值
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 展示当前储值资产
|
||||
- 让顾客选择充值方案
|
||||
- 回看充值记录
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 顶部余额区展示：
|
||||
- 总储值余额
|
||||
- 实充余额
|
||||
- 赠送余额
|
||||
- 方案区展示：
|
||||
- 充值金额
|
||||
- 赠送金额
|
||||
- 到账金额
|
||||
- 记录区展示：
|
||||
- 充值时间
|
||||
- 支付方式
|
||||
- 到账金额
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- 页面结构可以正式成立
|
||||
- 但后台记录里的 `alipay / cash / card / balance / wechat` 不是小程序前台支付方式全量清单
|
||||
- 从小程序场景推断，充值前台支付应先收敛，不能直接镜像后台记账方式
|
||||
|
||||
## 5.5 次卡页
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 解释当前有哪些次卡
|
||||
- 解释次卡适用范围和使用规则
|
||||
- 查看已发生的使用结果
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 可购买次卡区可以承接：
|
||||
- 卡名称
|
||||
- 售价
|
||||
- 次数
|
||||
- 适用范围
|
||||
- 有效期
|
||||
- 记录区可以承接：
|
||||
- 使用商品
|
||||
- 使用时间
|
||||
- 剩余次数
|
||||
- 补差金额
|
||||
|
||||
### 当前必须收住的地方
|
||||
|
||||
- “我的次卡实例列表”当前没有完整后台事实源
|
||||
- 转赠、退款、购买后实例详情不要先写满
|
||||
- 次卡页可以保留，但不要把“我的次卡”部分冻结得比证据更重
|
||||
|
||||
## 5.6 消息中心
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 顾客查看自己收到的订单、营销、系统消息
|
||||
|
||||
### 当前正确结论
|
||||
|
||||
- 信息架构上可以保留该页
|
||||
- 但当前后台证据不足以支撑：
|
||||
- 顾客消息列表
|
||||
- 未读已读状态
|
||||
- 消息点击跳转规则
|
||||
- `message-reach` 只能作为未来内容源，不是这个页面本身
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- `T04` 可以保留消息入口
|
||||
- `P16` 页面职责保留
|
||||
- 但具体字段和交互暂不冻结为正式契约
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前发现的不合理设计点
|
||||
|
||||
### 6.1 旧“我的页”把所有资产都当成已存在且可精确计数，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 当前后台事实源是分散的
|
||||
- 有些是模板
|
||||
- 有些是记录
|
||||
- 有些是后台运营页
|
||||
- 不是所有项都已经形成顾客资产摘要
|
||||
|
||||
调整：
|
||||
|
||||
- `T04` 先做聚合入口
|
||||
- 数量角标只对已证实字段开放
|
||||
|
||||
### 6.2 旧会员中心把成长值升级路径写得太满
|
||||
|
||||
原因：
|
||||
|
||||
- 当前能稳定确认的是等级规则和权益
|
||||
- 当前用户成长进度的顾客侧契约并不完整
|
||||
|
||||
调整：
|
||||
|
||||
- 会员中心重心放在“当前等级 + 当前权益 + 等级说明”
|
||||
- 升级进度条不先写成强依赖
|
||||
|
||||
### 6.3 旧消息中心容易和后台“消息触达”混淆
|
||||
|
||||
原因：
|
||||
|
||||
- 一个是后台发消息
|
||||
- 一个是顾客收消息
|
||||
|
||||
调整：
|
||||
|
||||
- 明确拆成“发送中心”和“收件中心”两套模型
|
||||
- 当前只确认前者存在
|
||||
|
||||
### 6.4 旧储值充值页如果照搬后台支付方式，会让前台收银口径失控
|
||||
|
||||
原因：
|
||||
|
||||
- 后台支付方式同时承担记账兼容
|
||||
- 小程序前台支付方式应该更收敛
|
||||
|
||||
调整：
|
||||
|
||||
- 充值页承接充值方案和充值记录
|
||||
- 支付方式前台不镜像后台枚举
|
||||
|
||||
### 6.5 旧次卡页把“可购买次卡”和“我的次卡”都写成已完全成型，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 当前模板和使用记录是清楚的
|
||||
- 但顾客实例清单和购买契约没有在后台页中清晰暴露
|
||||
|
||||
调整：
|
||||
|
||||
- 次卡页保留
|
||||
- 但先以模板说明和结果记录为主
|
||||
|
||||
### 6.6 旧“我的页”复购区过像推荐系统首页，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 当前最稳的是：
|
||||
- 最近订单
|
||||
- 常购商品
|
||||
- 不是复杂算法推荐
|
||||
|
||||
调整：
|
||||
|
||||
- 复购区先做“最近买过什么、再来一单”
|
||||
- 不先做复杂推荐解释
|
||||
|
||||
### 6.7 帮助中心和客服入口当前缺少真实后台来源
|
||||
|
||||
原因：
|
||||
|
||||
- 没有看到帮助内容管理或客服配置
|
||||
|
||||
调整：
|
||||
|
||||
- 先作为静态或轻运营页看待
|
||||
- 不把它写成后台强支撑能力
|
||||
|
||||
### 6.8 `T04` 上的领券入口与领券中心详细页，不应在本批混做一件事
|
||||
|
||||
原因：
|
||||
|
||||
- 我的页上的领券入口是资产/增长入口
|
||||
- 领券中心本身更偏活动导购与拉新
|
||||
|
||||
调整：
|
||||
|
||||
- 本批只冻结入口位置和摘要边界
|
||||
- 下一批再冻结完整领券导购页
|
||||
|
||||
---
|
||||
|
||||
## 7. 本批次冻结后的映射结论
|
||||
|
||||
## 7.1 直接承接
|
||||
|
||||
- 我的页作为聚合页
|
||||
- 会员等级与权益页
|
||||
- 积分商城商品与兑换记录
|
||||
- 储值充值方案与充值记录
|
||||
- 最近订单 / 常购商品 / 再来一单
|
||||
|
||||
## 7.2 间接支撑
|
||||
|
||||
- 优惠券模板配置
|
||||
- 次卡模板配置与后台使用记录
|
||||
- 消息触达后台
|
||||
- 客户画像里的成长值、偏好、复购率
|
||||
|
||||
## 7.3 暂不冻结为正式前台能力
|
||||
|
||||
- 优惠券数量与我的券包详情
|
||||
- 我的次卡实例详情
|
||||
- 订单快捷角标数量
|
||||
- 未读消息数与完整 inbox
|
||||
- 到下一等级的精确差值展示
|
||||
- 帮助中心的后台动态内容
|
||||
|
||||
## 7.4 本批次新增约束
|
||||
|
||||
- `T04` 只能做聚合摘要，不做资产真源
|
||||
- 消息中心不能拿后台 `message-reach` 直接复用
|
||||
- 会员中心先强调当前权益，不强调复杂成长值进度
|
||||
- 次卡页先强调模板与记录，不夸大“我的次卡实例”
|
||||
- 领券中心完整导购留到下一批，不在本批冻结
|
||||
|
||||
---
|
||||
|
||||
## 8. 对下一批的依赖
|
||||
|
||||
下一批做“活动导购与增长链路”时，需要直接继承本批结论：
|
||||
|
||||
- 我的页上的领券入口只负责导流，不负责解释完整活动规则
|
||||
- 会员权益里赠券、免配送费、新客礼等增长能力，需要和活动页统一口径
|
||||
- 消息触达如果后续要给活动页做通知承接，应沿用“后台发送中心 vs 顾客消息中心”分层
|
||||
- 如果要把我的页资产卡做完整，还需要后续补：
|
||||
- 顾客券包聚合
|
||||
- 顾客次卡实例聚合
|
||||
- 顾客消息 inbox 聚合
|
||||
- 顾客首页资产摘要聚合
|
||||
554
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md
Normal file
554
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md
Normal file
@@ -0,0 +1,554 @@
|
||||
# B06 活动导购与增长链路
|
||||
|
||||
## 1. 批次目标
|
||||
|
||||
本批次解决的是：
|
||||
|
||||
租户后台里的营销活动，哪些应该在首页和点餐页作为“导购内容”出现，哪些值得独立成活动页，哪些只适合作为自动命中的规则结果存在，以及旧版原型里活动入口过多、页面职责过满、把后台运营能力误当前台页面的地方，应该怎么收住。
|
||||
|
||||
这一批重点处理：
|
||||
|
||||
- `T01 首页` 的活动区与快捷入口
|
||||
- `T02 点餐页` 的活动提示与活动价商品表达
|
||||
- `P09 领券中心页`
|
||||
- `P10 秒杀活动页`
|
||||
- `P11 限时折扣活动页`
|
||||
|
||||
同时会把以下能力明确放到“规则支撑”或“未来补契约”：
|
||||
|
||||
- 满减活动
|
||||
- 新客有礼
|
||||
- 营销日历
|
||||
|
||||
---
|
||||
|
||||
## 2. 证据源
|
||||
|
||||
### 后台真实来源
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/index.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/full-reduction.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/new-customer.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/seckill.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/flash-sale.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/calendar.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/coupon`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/full-reduction`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/new-customer`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/seckill`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/flash-sale`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/calendar`
|
||||
|
||||
### 已完成批次依赖
|
||||
|
||||
- `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md`
|
||||
|
||||
### 旧版小程序参考
|
||||
|
||||
- `docs/02-信息架构与路由.md`
|
||||
- `docs/03-全局业务规则.md`
|
||||
- `docs/04-核心用户流程.md`
|
||||
- `docs/07-页面规格/01-Tab-首页.md`
|
||||
- `docs/07-页面规格/02-Tab-点餐页.md`
|
||||
- `docs/07-页面规格/15-领券中心页.md`
|
||||
- `docs/07-页面规格/16-秒杀活动页.md`
|
||||
- `docs/07-页面规格/17-限时折扣活动页.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 后台真实功能清单
|
||||
|
||||
| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 优惠券模板 | 券类型、门槛、有效期、适用门店、适用渠道、每人限领、开放/暂停领取 | 是，但当前看到的是模板与总量统计，不是顾客券包 | `P09`、`T01`、`T04` 入口 | 直接承接为主 |
|
||||
| 满减活动 | `reduce / gift / second_half`，适用门店、渠道、商品范围、可否叠券 | 结果可感知 | `T02` 活动摘要、`P03` 自动命中 | 直接承接结果，不建议独立页 |
|
||||
| 新客有礼 | 欢迎礼包、直减、新客券、邀请人/被邀请人奖励、分享渠道、邀请记录 | 资格和结果可感知 | `T01` 新客入口、`P03` 自动命中、分享入口预留 | 直接承接为主，但顾客分享契约未完整 |
|
||||
| 秒杀活动 | `hourly / timed`，场次、库存、秒杀价、限购、预热、适用渠道 | 是 | `T01`、`T02`、`P10` | 直接承接 |
|
||||
| 限时折扣 | `once / recurring`，日期、时段、周几循环、折扣价、限购、适用渠道 | 是 | `T01`、`T02`、`P11` | 直接承接 |
|
||||
| 营销日历 | 汇总活动来源、活动冲突、月度排期、活动详情字段 | 否，主要是后台运营编排能力 | 首页内容编排、消息提醒节奏 | 间接支撑 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 后台字段到 C 端的映射结论
|
||||
|
||||
## 4.1 活动内容必须服从“当前门店 + 当前场景 + 当前资格”
|
||||
|
||||
这是本批最重要的冻结结论。
|
||||
|
||||
营销活动不是一个独立系统，它必须服从前面几批已经冻结的主线前提：
|
||||
|
||||
- 第 1 批已经确认：首页和点餐页的场景切换必须跟随门店真实 `serviceTypes`
|
||||
- 第 2 批已经确认：商品展示和类目展示必须按当前渠道过滤
|
||||
- 第 3 批已经确认：满减、新客、会员权益在结算侧主要以自动命中结果存在
|
||||
- 第 5 批已经确认：我的页上的领券入口只是导流，不代表顾客券包契约已经完整
|
||||
|
||||
因此在小程序里，所有活动展示都要同时满足：
|
||||
|
||||
1. 当前门店可用
|
||||
2. 当前场景可用
|
||||
3. 当前用户资格成立
|
||||
4. 当前活动状态成立
|
||||
|
||||
不能把后台营销列表里的活动直接原样铺到首页。
|
||||
|
||||
## 4.2 首页活动区必须做“动态精选”，不能做固定八宫格
|
||||
|
||||
旧版首页把：
|
||||
|
||||
- 新客有礼
|
||||
- 领券中心
|
||||
- 满减活动
|
||||
- 秒杀专区
|
||||
- 限时折扣
|
||||
- 储值充值
|
||||
- 次卡专区
|
||||
- 会员中心
|
||||
|
||||
全部做成固定入口，这个结构现在已经不合理。
|
||||
|
||||
原因有三个：
|
||||
|
||||
1. 这些入口不属于同一层级
|
||||
2. 有些是营销活动，有些是资产页，有些是服务页
|
||||
3. 当前营销后台本身就是动态活动，不应该被固定成静态菜单
|
||||
|
||||
调整后：
|
||||
|
||||
- `T01` 的活动区应该以“动态精选活动”形式出现
|
||||
- 高优先展示：
|
||||
- 当前有效的秒杀
|
||||
- 当前有效的限时折扣
|
||||
- 当前可见的新客活动
|
||||
- 当前可领取的券活动
|
||||
- 储值充值、次卡、会员中心继续留在 `T04` 为主，不再占首页核心活动位
|
||||
|
||||
## 4.3 哪些活动适合独立成页，哪些不适合
|
||||
|
||||
### 适合独立成页
|
||||
|
||||
- 秒杀
|
||||
- 限时折扣
|
||||
- 领券中心
|
||||
|
||||
原因：
|
||||
|
||||
- 秒杀本身有场次、倒计时、库存和限购，适合做活动会场
|
||||
- 限时折扣本身有周期、时段和折扣商品集合，适合做折扣会场
|
||||
- 优惠券模板天然可以聚合成“领券中心”
|
||||
|
||||
### 不适合独立成页
|
||||
|
||||
- 满减活动
|
||||
- 新客有礼
|
||||
- 营销日历
|
||||
|
||||
原因：
|
||||
|
||||
- 满减活动本质上是规则命中，不是顾客需要手动配置的活动页
|
||||
- 新客有礼本质上是资格活动和首单激励，不适合做通用长期活动页
|
||||
- 营销日历是后台排期与冲突管理能力，不是顾客看活动日历
|
||||
|
||||
## 4.4 满减活动应该“强感知、弱页面”
|
||||
|
||||
满减活动的真实后台能力很强，包括：
|
||||
|
||||
- 满减
|
||||
- 满赠
|
||||
- 第二份优惠
|
||||
- 商品范围
|
||||
- 渠道范围
|
||||
- 门店范围
|
||||
- 是否可与券叠加
|
||||
|
||||
但这类能力在顾客侧最合理的表达，不是独立页，而是：
|
||||
|
||||
- 首页活动摘要
|
||||
- 点餐页活动条摘要
|
||||
- 结算页自动命中结果
|
||||
|
||||
也就是说：
|
||||
|
||||
- 顾客应该强烈感知“现在有满减 / 第二份优惠”
|
||||
- 但不需要跳入一个复杂的“满减活动页”
|
||||
|
||||
## 4.5 新客有礼应该“强资格、弱会场”
|
||||
|
||||
新客有礼后台配置包括：
|
||||
|
||||
- 礼包类型 `coupon / direct`
|
||||
- 欢迎券
|
||||
- 邀请人券
|
||||
- 被邀请人券
|
||||
- 分享渠道
|
||||
- 邀请记录
|
||||
|
||||
这说明它更像“资格式拉新机制”，而不是一个常规会场。
|
||||
|
||||
因此顾客侧更合理的表达是：
|
||||
|
||||
- 首页只在资格成立时出现新客入口或新客 Banner
|
||||
- 点餐和结算时展示新客已命中结果
|
||||
- 已注册老用户如满足邀请机制，可看到分享入口
|
||||
|
||||
但当前还不能冻结的部分是：
|
||||
|
||||
- 邀请分享落地页
|
||||
- 邀请码 / 分享链路
|
||||
- 新客礼包领取页
|
||||
|
||||
因为当前后台看到的是配置和记录，不是完整的顾客侧分享契约。
|
||||
|
||||
## 4.6 领券中心可以成立，但“个人领取状态”不要先写死
|
||||
|
||||
后台优惠券模板里已经能确认：
|
||||
|
||||
- 券类型
|
||||
- 使用门槛
|
||||
- 有效期
|
||||
- 适用门店
|
||||
- 适用渠道
|
||||
- 每人限领
|
||||
- 开放领取 / 暂停领取
|
||||
|
||||
但当前还没有看到明确的顾客侧：
|
||||
|
||||
- 领取动作接口
|
||||
- 本人是否已领取
|
||||
- 本人剩余可领次数
|
||||
- 券包列表
|
||||
|
||||
所以：
|
||||
|
||||
- `P09` 作为“可领券模板聚合页”是成立的
|
||||
- 但 `已领取 / 去使用 / 已抢完 / 我的券包` 这类强个人状态暂时不能冻结得太重
|
||||
|
||||
## 4.7 秒杀与限时折扣的页面职责必须分开
|
||||
|
||||
这两个活动在后台里是完全不同的能力，不应在前台写成同一种“活动页”。
|
||||
|
||||
### 秒杀
|
||||
|
||||
- 有场次
|
||||
- 有库存上限
|
||||
- 有预热
|
||||
- 更强调抢购和紧迫感
|
||||
|
||||
### 限时折扣
|
||||
|
||||
- 有日期区间
|
||||
- 有时段
|
||||
- 可能按周循环
|
||||
- 更强调折扣强度和时间窗口
|
||||
|
||||
所以：
|
||||
|
||||
- `P10` 要突出场次、倒计时、库存、限购
|
||||
- `P11` 要突出折扣价、折扣力度、周期、时间窗口
|
||||
|
||||
## 4.8 秒杀和限时折扣都不能绕开主交易链路
|
||||
|
||||
即使有独立活动页，也不能演变成一套单独下单系统。
|
||||
|
||||
统一原则是：
|
||||
|
||||
- 活动商品点击后仍然进入商品详情 / 加购 / 购物车 / 结算主链路
|
||||
- 活动页只是导流页和筛选页
|
||||
- 交易解释仍回归第 2 批和第 3 批已经冻结的商品、结算、支付链路
|
||||
|
||||
## 4.9 营销日历是“编排事实源”，不是顾客页面
|
||||
|
||||
营销日历当前能够说明三件事：
|
||||
|
||||
- 后台把多个营销模块整合到了统一时间轴上
|
||||
- 后台能发现活动冲突
|
||||
- 后台活动条自带 `sourceType / sourceId / detail.fields`
|
||||
|
||||
这说明它对小程序很有价值，但价值在于：
|
||||
|
||||
- 首页活动区排序与编排
|
||||
- 同期活动冲突避免
|
||||
- 消息提醒时机
|
||||
|
||||
而不是在小程序里给顾客做一页“营销日历”。
|
||||
|
||||
---
|
||||
|
||||
## 5. 小程序页面重映射
|
||||
|
||||
## 5.1 `T01 首页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 当前门店当前场景下最值得展示的活动
|
||||
- 一条最短的进入点餐或活动会场的路径
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- Banner 区：
|
||||
- 优先展示当前有效活动，不固定写死类别
|
||||
- 可承接：
|
||||
- 秒杀会场
|
||||
- 限时折扣会场
|
||||
- 新客活动
|
||||
- 领券中心
|
||||
- 快捷入口区：
|
||||
- 从“固定菜单”改为“精选活动入口”
|
||||
- 建议最多保留少数高价值入口
|
||||
- 推荐商品区：
|
||||
- 可以插入活动商品分组
|
||||
- 但仍然只是轻摘要，不直接展开复杂规则
|
||||
|
||||
### 当前必须收住的地方
|
||||
|
||||
- 不要固定八宫格
|
||||
- 不要把储值、次卡、会员中心继续混入首页核心营销位
|
||||
- 不要把营销日历误做成顾客活动日程
|
||||
|
||||
## 5.2 `T02 点餐页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 把活动结果翻译成顾客看得懂的价格和优惠提示
|
||||
- 把活动导流回商品和结算
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 顶部活动条只承接高价值摘要：
|
||||
- 满减
|
||||
- 新客有礼
|
||||
- 秒杀进行中
|
||||
- 限时折扣进行中
|
||||
- 商品卡必须支持活动表达：
|
||||
- 秒杀价
|
||||
- 折扣价
|
||||
- 原价划线
|
||||
- 限购提示
|
||||
- 活动标签
|
||||
- 活动商品进入详情后，仍走正常选配和加购流程
|
||||
|
||||
### 当前必须收住的地方
|
||||
|
||||
- 不要把点餐页活动条做成所有活动的堆栈公告栏
|
||||
- 不要把满减和新客活动做成需要顾客手动开关的入口
|
||||
- 不要在点餐页里复刻整套活动会场逻辑
|
||||
|
||||
## 5.3 `P09 领券中心页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 集中展示当前可见的券模板
|
||||
- 引导回点餐使用
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 列表至少展示：
|
||||
- 券名称
|
||||
- 金额或折扣
|
||||
- 使用门槛
|
||||
- 有效期
|
||||
- 适用门店
|
||||
- 适用场景
|
||||
- 类型筛选可以保留：
|
||||
- 满减券
|
||||
- 折扣券
|
||||
- 免配送费券
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- 页面可以成立
|
||||
- 但用户个人领取状态和“去使用”状态不先写死
|
||||
- 领券结果最好回流到点餐页或我的页资产页，而不是停留在活动页内闭环
|
||||
|
||||
## 5.4 `P10 秒杀活动页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 承接强时效、强库存、强场次的活动会场
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 头部区强调：
|
||||
- 场次
|
||||
- 倒计时
|
||||
- 是否预热
|
||||
- 商品卡强调：
|
||||
- 秒杀价
|
||||
- 原价
|
||||
- 剩余库存 / 已抢进度
|
||||
- 每人限购
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- `P10` 是正式页面
|
||||
- 会场入口可来自首页 Banner、快捷入口、点餐页活动条
|
||||
- 但点击商品后应回到正常商品链路，不做独立活动收银台
|
||||
|
||||
## 5.5 `P11 限时折扣活动页`
|
||||
|
||||
### 这一页真正该承接什么
|
||||
|
||||
- 承接折扣商品会场
|
||||
- 让顾客快速浏览“现在买更省”的商品集合
|
||||
|
||||
### 应该怎么表达
|
||||
|
||||
- 头部区强调：
|
||||
- 活动名称
|
||||
- 日期范围
|
||||
- 时段
|
||||
- 若为循环活动则展示周几
|
||||
- 商品卡强调：
|
||||
- 折扣价
|
||||
- 原价
|
||||
- 折扣力度
|
||||
- 每人限购
|
||||
|
||||
### 当前冻结方式
|
||||
|
||||
- `P11` 是正式页面
|
||||
- 要弱化“抢”的表达，强化“省”的表达
|
||||
- 也必须回到正常商品、购物车、结算主链路
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前发现的不合理设计点
|
||||
|
||||
### 6.1 旧首页把活动入口、资产入口、服务入口混成一层，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 营销入口和资产入口不是一类任务
|
||||
- 首页活动位应优先服务转化，不应变成全站目录
|
||||
|
||||
调整：
|
||||
|
||||
- 首页只保留动态精选活动
|
||||
- 资产和服务入口回归 `T04`
|
||||
|
||||
### 6.2 旧首页固定 `外卖 / 自提 / 堂食` 下的活动内容，没有明确按渠道过滤，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台营销活动都有 `delivery / pickup / dine_in` 渠道范围
|
||||
|
||||
调整：
|
||||
|
||||
- 首页和点餐页活动必须随当前场景过滤
|
||||
|
||||
### 6.3 旧点餐页容易把活动提示条做成“营销公告栏”，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 点餐页主任务是选商品，不是读活动说明
|
||||
|
||||
调整：
|
||||
|
||||
- 活动条只显示会影响当前购买决策的摘要
|
||||
|
||||
### 6.4 旧原型容易默认“满减活动页”存在，但后台事实不支持这样做
|
||||
|
||||
原因：
|
||||
|
||||
- 满减后台是规则配置页，不是会场页
|
||||
|
||||
调整：
|
||||
|
||||
- 满减只做结果感知，不做独立会场
|
||||
|
||||
### 6.5 旧原型容易默认“新客有礼页”对所有人都成立，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 新客活动天然依赖资格
|
||||
- 邀请分享还缺完整顾客链路
|
||||
|
||||
调整：
|
||||
|
||||
- 新客入口只在资格成立时展示
|
||||
- 分享和邀请链路暂不冻结为正式页面
|
||||
|
||||
### 6.6 `P09` 不能因为后台有“开放领取 / 暂停领取”就直接假定小程序已具备完整领券状态流
|
||||
|
||||
原因：
|
||||
|
||||
- 当前看到的是模板管理和总量统计
|
||||
- 不是顾客个人券包状态
|
||||
|
||||
调整：
|
||||
|
||||
- 领券中心先聚焦“可见券模板”
|
||||
- 个人状态后补
|
||||
|
||||
### 6.7 秒杀和限时折扣不能用一套通用活动页糊过去
|
||||
|
||||
原因：
|
||||
|
||||
- 秒杀强调场次、库存、预热
|
||||
- 限时折扣强调周期、时间窗口、折扣强度
|
||||
|
||||
调整：
|
||||
|
||||
- 两页职责分开，视觉与文案重点也要分开
|
||||
|
||||
### 6.8 营销日历不应被误当前台功能页
|
||||
|
||||
原因：
|
||||
|
||||
- 它是编排后台，不是顾客任务页面
|
||||
|
||||
调整：
|
||||
|
||||
- 只把它作为首页和活动区编排依据
|
||||
|
||||
---
|
||||
|
||||
## 7. 本批次冻结后的映射结论
|
||||
|
||||
## 7.1 直接承接
|
||||
|
||||
- 首页动态活动区
|
||||
- 点餐页活动摘要与活动价商品表达
|
||||
- 领券中心
|
||||
- 秒杀活动页
|
||||
- 限时折扣活动页
|
||||
|
||||
## 7.2 间接支撑
|
||||
|
||||
- 满减规则配置
|
||||
- 新客资格与邀请配置
|
||||
- 营销日历排期与冲突信息
|
||||
|
||||
## 7.3 暂不冻结为正式前台能力
|
||||
|
||||
- 满减独立活动页
|
||||
- 新客邀请分享完整链路
|
||||
- 顾客个人领券状态与券包详情
|
||||
- 顾客营销日历页
|
||||
- 由营销消息直接驱动的顾客 inbox 交互
|
||||
|
||||
## 7.4 本批次新增约束
|
||||
|
||||
- 首页活动位必须动态化，不做固定八宫格
|
||||
- 秒杀与限时折扣都要按当前门店和场景过滤
|
||||
- 满减和新客活动主要做规则结果展示，不做重页面
|
||||
- 活动页必须导流回商品、购物车、结算主链路
|
||||
- 领券中心先展示券模板，不先夸大用户个人状态
|
||||
|
||||
---
|
||||
|
||||
## 8. 对下一批的依赖
|
||||
|
||||
下一批做“精细化运营与不前置能力”时，需要直接继承本批结论：
|
||||
|
||||
- 营销日历、客户分析、消息触达应作为首页活动编排和提醒时机的支撑层，不直接前置给顾客
|
||||
- 如果后续要把首页活动排序做得更智能，需要补：
|
||||
- 顾客资格判断
|
||||
- 顾客活动点击与领取行为
|
||||
- 顾客个性化推荐
|
||||
- 如果后续要把领券中心做完整，需要补：
|
||||
- 顾客领券接口
|
||||
- 券包查询接口
|
||||
- 个人领取状态与剩余可领次数
|
||||
443
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/07-精细化运营与不前置能力.md
Normal file
443
Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/07-精细化运营与不前置能力.md
Normal file
@@ -0,0 +1,443 @@
|
||||
# B07 精细化运营与不前置能力
|
||||
|
||||
## 1. 批次目标
|
||||
|
||||
本批次解决的是：
|
||||
|
||||
租户后台里已经存在一批很重要、但不适合直接翻译成顾客页面的能力，包括：
|
||||
|
||||
- `customer` 的客户列表、客户画像、客户分析
|
||||
- `finance` 的财务概览、交易流水、发票、到账、成本、经营报表
|
||||
- `dashboard` 的工作台、分析页
|
||||
|
||||
这一批不是为了再多造几个小程序页面，而是要把这类能力的边界收住，明确：
|
||||
|
||||
- 哪些只能作为顾客体验背后的运营输入
|
||||
- 哪些只允许抽取少量结果给顾客看
|
||||
- 哪些可以留作未来扩展，但现在不能强行前置
|
||||
|
||||
如果这一批不收口，后面很容易继续出现两个问题：
|
||||
|
||||
1. 把后台运营视角直接搬到 C 端
|
||||
2. 误以为后台每个菜单都应该有一个对应的小程序页面
|
||||
|
||||
---
|
||||
|
||||
## 2. 证据源
|
||||
|
||||
### 后台真实来源
|
||||
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/customer/index.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/customer/list`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/customer/analysis`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/overview.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/transaction.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/invoice.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/settlement.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/report.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/cost.ts`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/overview`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/transaction`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/invoice`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/settlement`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/report`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/cost`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/dashboard/workspace/index.vue`
|
||||
- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/dashboard/analytics/index.vue`
|
||||
|
||||
### 已完成批次依赖
|
||||
|
||||
- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md`
|
||||
- `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md`
|
||||
|
||||
### 旧版小程序参考
|
||||
|
||||
- `docs/09-租户后台与C端功能映射总表.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 后台真实功能清单
|
||||
|
||||
| 后台能力 | 真实内容 | 对顾客是否直接可感知 | 小程序承接方式 | 结论 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 客户列表 | 客户标签、下单次数、注册周期、活跃/流失/高价值筛选、客单价、复购率、最近下单 | 否 | 推荐、分层、运营策略输入 | 间接支撑 |
|
||||
| 客户画像 / 客户详情 | 偏好品类、偏好配送方式、偏好支付方式、常购商品、订单趋势、会员摘要 | 否 | 个性化推荐、权益提示、复购推荐输入 | 间接支撑 |
|
||||
| 客户分析 | 新老客构成、客单价分布、RFM 分层、Top 客户、增长趋势、分群明细 | 否 | 活动定向、推荐排序、会员运营输入 | 间接支撑 |
|
||||
| 财务概览 | 今日营收、净收入、退款金额、可提现余额、收入构成、成本构成、利润趋势、Top 商品 | 否 | 仅后台经营驾驶舱 | 不前置 |
|
||||
| 交易流水 | 收入、退款、储值充值、积分抵扣、支付方式、到账金额、备注、交易详情 | 只有极少数字段可感知 | 订单金额说明、充值记录、退款记录、积分变动说明 | 间接支撑 |
|
||||
| 发票管理 | 发票设置、申请、开票、作废、记录详情、自动开票阈值 | 部分可感知 | 未来可从订单详情延伸出发票申请 | 未来扩展 |
|
||||
| 到账查询 | 到账统计、到账日期、渠道、商户号掩码、结算周期、到账明细 | 否 | 无前台页 | 不前置 |
|
||||
| 经营报表 | 营收、成本、利润率、退款率、日报周报月报、PDF/Excel/ZIP 导出 | 否 | 无前台页 | 不前置 |
|
||||
| 成本管理 | 成本录入、成本分类、成本率、趋势、月度明细 | 否 | 无前台页 | 不前置 |
|
||||
| 工作台 / 分析页 | 通用导航、示例项目、访问量、下载量、来源图表等 | 否，且业务证据弱 | 不应作为小程序设计依据 | 不前置 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 后台能力到 C 端的映射结论
|
||||
|
||||
## 4.1 不是后台每个菜单都需要一个顾客页面
|
||||
|
||||
这是本批最重要的冻结结论。
|
||||
|
||||
前面几批已经把顾客主链路基本收齐了：
|
||||
|
||||
- 店铺前置
|
||||
- 菜单浏览与加购
|
||||
- 结算与支付
|
||||
- 履约与售后
|
||||
- 我的与资产
|
||||
- 活动导购与增长
|
||||
|
||||
这一批看到的 `customer / finance / dashboard`，大多数都属于：
|
||||
|
||||
- 运营分析层
|
||||
- 财务结算层
|
||||
- 后台驾驶舱层
|
||||
|
||||
它们当然重要，但重要不等于应该前置成顾客页面。
|
||||
|
||||
正确做法是：
|
||||
|
||||
- 先确认它到底是顾客任务，还是商家任务
|
||||
- 如果只是运营和经营支撑，就留在后台
|
||||
- 只有当顾客真的需要发起动作、查看结果、完成闭环时，才考虑前台承接
|
||||
|
||||
## 4.2 客户列表、画像、分析是商家 CRM 语言，不是顾客任务语言
|
||||
|
||||
`customer` 域里已经能确认很多能力：
|
||||
|
||||
- 客户标签
|
||||
- 活跃 / 沉睡 / 流失 / 高价值分层
|
||||
- 客单价与复购率
|
||||
- 偏好品类
|
||||
- 偏好配送方式
|
||||
- 偏好支付方式
|
||||
- 常购商品
|
||||
- RFM 分层
|
||||
- Top 客户
|
||||
|
||||
这些能力对小程序当然有价值，但价值主要体现在幕后：
|
||||
|
||||
- 首页推荐排序
|
||||
- 点餐页推荐商品
|
||||
- 券和活动的定向投放
|
||||
- 会员运营策略
|
||||
|
||||
不合理的做法是把这些后台概念直接翻译成顾客可见页面，比如：
|
||||
|
||||
- “我的客户画像”
|
||||
- “我的 RFM 分层”
|
||||
- “高价值顾客标签展示”
|
||||
|
||||
这类表达对顾客没有自然任务价值，反而会把后台运营语言泄露到前台。
|
||||
|
||||
## 4.3 RFM、Top 客户、客群明细不应直接成为前台可见概念
|
||||
|
||||
后台客户分析里已经出现：
|
||||
|
||||
- 新老客构成
|
||||
- 客单价分布
|
||||
- RFM 矩阵
|
||||
- Top 客户排行
|
||||
- 各种分群明细
|
||||
|
||||
这说明系统已经具备精细化运营输入源，但它支持的是：
|
||||
|
||||
- 谁该看到什么活动
|
||||
- 谁更适合被推荐什么商品
|
||||
- 谁应该收到什么权益提醒
|
||||
|
||||
而不是让顾客自己看一页分析报表。
|
||||
|
||||
因此这一批需要明确：
|
||||
|
||||
- 客群标签不做前台字段
|
||||
- RFM 不做顾客可见解释
|
||||
- Top 客户不做排行榜页面
|
||||
- 客户分析只作为个性化和自动运营的支撑层
|
||||
|
||||
## 4.4 财务概览、到账、成本、报表是典型后台经营面板，不应顾客化
|
||||
|
||||
`finance/overview`、`settlement`、`cost`、`report` 已经很清楚地表明：
|
||||
|
||||
- 财务概览看的是营收、净收入、退款金额、可提现余额、利润趋势
|
||||
- 到账查询看的是到账渠道、到账日期、商户账户、结算周期
|
||||
- 成本管理看的是食材、人工、包装、固定成本及成本率
|
||||
- 经营报表看的是利润率、退款率、日报周报月报及导出
|
||||
|
||||
这些能力对应的是：
|
||||
|
||||
- 商家算账
|
||||
- 商家对账
|
||||
- 商家经营分析
|
||||
|
||||
不是顾客任务。
|
||||
|
||||
所以小程序里不应该出现：
|
||||
|
||||
- 顾客版财务驾驶舱
|
||||
- 顾客版到账中心
|
||||
- 顾客版经营报表
|
||||
- 顾客版成本分析
|
||||
|
||||
这类设计会把商家视角和顾客视角完全混淆。
|
||||
|
||||
## 4.5 交易流水只允许抽取“顾客真实会关心的那一小部分”
|
||||
|
||||
`finance/transaction` 是这一批里最容易被误用的一块。
|
||||
|
||||
因为它确实包含了顾客能感知到的一些东西：
|
||||
|
||||
- 退款
|
||||
- 储值充值
|
||||
- 积分抵扣
|
||||
- 支付方式
|
||||
- 订单号
|
||||
- 金额变化
|
||||
|
||||
但它本质上仍然是后台财务流水。
|
||||
|
||||
因此更合理的做法不是做一页“顾客交易流水中心”，而是把少量必要结果拆回原来的链路里：
|
||||
|
||||
- 订单金额、支付方式、退款信息，回到订单详情
|
||||
- 储值充值记录，回到储值页
|
||||
- 积分变动说明，回到积分相关页
|
||||
|
||||
也就是说：
|
||||
|
||||
- 可以借它做解释
|
||||
- 不能把整张后台流水表原样前置
|
||||
|
||||
## 4.6 发票管理是少数可以保留前台扩展入口的财务能力
|
||||
|
||||
`finance/invoice` 和其他财务模块不一样。
|
||||
|
||||
这里已经能确认：
|
||||
|
||||
- 发票申请
|
||||
- 发票记录
|
||||
- 发票详情
|
||||
- 发票开具
|
||||
- 发票作废
|
||||
- 发票设置
|
||||
- 自动开票阈值
|
||||
|
||||
这说明系统里确实存在一条“顾客申请发票”的业务事实，而不只是后台内部表格。
|
||||
|
||||
但当前仍然不能直接把后台发票管理页搬成顾客财务中心，原因是：
|
||||
|
||||
- 后台页面包含发票设置、开票、作废等商家动作
|
||||
- 这些动作不是顾客主链路
|
||||
- 目前主文档也还没有完整冻结前台发票交互
|
||||
|
||||
因此更合理的结论是：
|
||||
|
||||
- 电子发票入口可以作为未来扩展保留
|
||||
- 最自然的入口位置是订单详情页
|
||||
- 当前不单独拉出一套正式前台发票中心
|
||||
|
||||
## 4.7 `dashboard` 当前不能作为小程序页面设计的事实源
|
||||
|
||||
`dashboard/workspace` 和 `dashboard/analytics` 当前看到的内容更接近：
|
||||
|
||||
- 脚手架示例数据
|
||||
- 通用工作台
|
||||
- 通用访问量图表
|
||||
|
||||
而不是外卖业务里的稳定事实模型。
|
||||
|
||||
这意味着：
|
||||
|
||||
- 它可以作为后台壳层参考
|
||||
- 不能反推 C 端页面设计
|
||||
- 不能拿“访问量、下载量、来源图表”去推导小程序顾客页结构
|
||||
|
||||
这一点需要明确写住，避免后续继续把示例页当业务源。
|
||||
|
||||
---
|
||||
|
||||
## 5. 小程序页面与能力重映射
|
||||
|
||||
## 5.1 `T01 首页` 与 `T02 点餐页`
|
||||
|
||||
这两页可以继续被 `customer` 域间接增强，但增强方式只能是：
|
||||
|
||||
- 更合理的推荐排序
|
||||
- 更贴近用户偏好的商品分组
|
||||
- 更合适的活动曝光
|
||||
- 更贴近会员状态的权益提示
|
||||
|
||||
不能新增成：
|
||||
|
||||
- 客户画像页入口
|
||||
- 顾客标签展示区
|
||||
- 客群等级说明区
|
||||
|
||||
## 5.2 `T04 我的页`、资产页、订单详情页
|
||||
|
||||
这几页可以继续从 `finance/transaction` 抽取顾客可理解的结果，但要坚持“结果页”思路：
|
||||
|
||||
- 我的页只做摘要入口，不做财务总账
|
||||
- 储值页看充值计划、余额和充值记录，不看后台流水维度
|
||||
- 积分页看积分来源和使用结果，不看财务记账视角
|
||||
- 订单详情页看支付结果、退款结果、可能的发票入口
|
||||
|
||||
不能演变成：
|
||||
|
||||
- 顾客交易流水驾驶舱
|
||||
- 顾客财务对账中心
|
||||
|
||||
## 5.3 `P05 订单详情页` 的未来扩展位
|
||||
|
||||
如果后续要承接 `finance/invoice`，最合理的是在订单详情页里增加：
|
||||
|
||||
- 申请发票入口
|
||||
- 发票申请结果
|
||||
- 发票状态查看
|
||||
|
||||
但当前不先冻结：
|
||||
|
||||
- 完整发票中心首页
|
||||
- 发票设置页
|
||||
- 开票 / 作废等商家动作页
|
||||
|
||||
## 5.4 当前明确不新增的正式前台页面
|
||||
|
||||
这一批明确不建议新增以下顾客页：
|
||||
|
||||
- 客户列表页
|
||||
- 客户画像页
|
||||
- 客户分析页
|
||||
- 财务概览页
|
||||
- 交易流水总账页
|
||||
- 到账查询页
|
||||
- 经营报表页
|
||||
- 成本分析页
|
||||
- 顾客版仪表盘页
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前发现的不合理设计点
|
||||
|
||||
### 6.1 把后台功能表机械地一一映射成前台页面，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台回答的是“商家怎么管”
|
||||
- 前台回答的是“顾客怎么用”
|
||||
|
||||
调整：
|
||||
|
||||
- 以后不再按后台菜单数量推导前台页面数量
|
||||
|
||||
### 6.2 把 CRM 标签、RFM 分层、Top 客户直接前置给顾客，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 这属于后台分析语言，不是顾客任务语言
|
||||
|
||||
调整：
|
||||
|
||||
- 只把它们转译成推荐、权益、活动曝光，不直接展示原始概念
|
||||
|
||||
### 6.3 把财务驾驶舱、到账、报表、成本直接做成顾客可见页，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 这些页面服务的是商家经营和财务核对
|
||||
|
||||
调整：
|
||||
|
||||
- 只保留顾客真实会发起或会关心的结果查看能力
|
||||
|
||||
### 6.4 把交易流水误当成顾客可用的完整资产中心，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 后台流水是记账视角，不是顾客任务视角
|
||||
|
||||
调整：
|
||||
|
||||
- 只抽取订单、充值、退款、积分这类与顾客行为直接对应的结果
|
||||
|
||||
### 6.5 把 `dashboard` 示例页当成业务事实源，不合理
|
||||
|
||||
原因：
|
||||
|
||||
- 当前内容明显包含示例项目、通用访问图表和脚手架数据
|
||||
|
||||
调整：
|
||||
|
||||
- 后续做小程序梳理时，不再把 `dashboard` 当成强事实源使用
|
||||
|
||||
### 6.6 发票能力如果直接照搬后台，会把商家动作误塞给顾客
|
||||
|
||||
原因：
|
||||
|
||||
- 后台发票页同时包含设置、开票、作废等管理动作
|
||||
|
||||
调整：
|
||||
|
||||
- 只保留未来可落在订单详情里的申请与结果查看方向
|
||||
|
||||
---
|
||||
|
||||
## 7. 本批次冻结后的映射结论
|
||||
|
||||
## 7.1 本批不新增正式前台页面
|
||||
|
||||
和前六批不同，这一批的主要结论不是“新增承接页”，而是明确：
|
||||
|
||||
- 当前主链路已经足够
|
||||
- `customer / finance / dashboard` 主要作为后台支撑层存在
|
||||
|
||||
## 7.2 间接支撑
|
||||
|
||||
- 客户列表、客户画像、客户分析
|
||||
- 交易流水中的退款、充值、积分、支付方式等事实子集
|
||||
- 营销和推荐排序所需的客群分层能力
|
||||
|
||||
## 7.3 未来扩展
|
||||
|
||||
- 订单详情页中的电子发票申请入口
|
||||
- 发票申请状态与结果查看
|
||||
- 基于客户分析的更精细推荐与专属活动排序
|
||||
|
||||
## 7.4 明确不前置
|
||||
|
||||
- 客户管理后台概念页
|
||||
- 财务概览驾驶舱
|
||||
- 到账查询与结算账户页
|
||||
- 成本录入与成本分析页
|
||||
- 经营报表导出页
|
||||
- 顾客版 Dashboard
|
||||
|
||||
## 7.5 本批次新增约束
|
||||
|
||||
- 后台运营分析能力默认先归入“间接支撑”，不要先做顾客页
|
||||
- 后台财务结算能力默认先归入“不前置”，不要用报表思维设计顾客端
|
||||
- 只有顾客真的会发起的动作，才允许从后台能力中抽取前台入口
|
||||
- `dashboard` 当前不作为小程序设计事实源
|
||||
- 发票能力保留扩展位，但不进入当前主链路冻结范围
|
||||
|
||||
---
|
||||
|
||||
## 8. 本轮梳理收口
|
||||
|
||||
到这里，`docs/12-租户管理员功能重构梳理/` 这一轮按顾客链路拆批次的重构梳理已经完成。
|
||||
|
||||
这一轮最终收口后的原则是：
|
||||
|
||||
- 顾客页只承接顾客任务
|
||||
- 后台页只作为事实源，不天然等于前台页
|
||||
- 规则、分析、结算、报表优先放在后台支撑层
|
||||
- 未来扩展只保留有明确顾客动作闭环的能力
|
||||
|
||||
如果后面继续往下做，下一阶段就不应该再回到“大而泛的页面猜想”，而应该进入：
|
||||
|
||||
- 单页规格回写
|
||||
- 字段级状态收敛
|
||||
- 接口契约补齐
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 271 KiB |
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user