9.1 KiB
9.1 KiB
全周期版本规划与范围分层
- 文档版本：
V1.0 - 适用项目：
TakeoutSaaS小程序 C 端 - 文档目标：基于现有租户后台能力与 C 端页面规格，定义小程序从原型期到成熟期的完整版本路径
1. 文档目的
本文件不再只回答“一期先做什么”，而是回答以下 3 个问题：
- 小程序 C 端全周期应该按什么节奏推进
- 每个版本解决什么用户问题、承接什么后台能力
- 哪些能力属于当前页内实现，哪些能力属于未来扩展
本文件与 docs/05-页面清单总表.md、docs/09-租户后台与C端功能映射总表.md、docs/10-全周期研发实施顺序与交付清单.md 配合使用。
2. 全周期总览
| 阶段 | 版本建议 | 阶段定位 | 核心目标 | 对应价值 |
|---|---|---|---|---|
| G0 | 原型规划期 | 文档与原型收口 | 把页面、路由、组件、流程、业务规则定清楚 | 降低后续返工 |
| G1 | V1.0 核心交易版 |
先跑通交易主闭环 | 顾客能完成选店、点餐、结算、支付、查订单 | 建立基础下单能力 |
| G2 | V1.1 履约服务版 |
补全场景与售后 | 顾客能退款、评价、自提、堂食扫码点餐 | 提升服务完整度 |
| G3 | V2.0 会员资产版 |
建立复购资产池 | 顾客能使用会员、优惠券、积分、储值、次卡 | 提升留存与复购 |
| G4 | V2.1 营销增长版 |
做活动承接与增长 | 顾客能参与新客礼、满减、秒杀、限时折扣等活动 | 提升转化与拉新 |
| G5 | V3.0 精细运营版 |
进入精细化经营 | 做消息触达、个性化推荐、服务中心、深度数据联动 | 提升 LTV 与运营效率 |
3. 各阶段详细范围
3.1 G0 原型规划期
阶段目标
- 完成 C 端页面地图、交互流、页面规格、业务规则与组件清单
- 对齐租户后台已有能力与 C 端承接关系
- 为后续 UI 设计、开发实现、接口对接提供统一母文档
当前应交付内容
docs/01-文档导航与实施顺序.mddocs/02-信息架构与路由.mddocs/03-全局业务规则.mddocs/04-核心用户流程.mddocs/05-页面清单总表.mddocs/06-通用组件清单.mddocs/07-页面规格/docs/08-10规划类文档
阶段完成标准
- 产品、设计、开发对页面范围与先后顺序没有歧义
- 每个页面都有明确入口、出口和状态要求
- 页面与后台能力关系可追溯
3.2 G1 V1.0 核心交易版
阶段定位
先做“顾客下单主闭环”，目标不是一次做全，而是先把最核心的交易能力跑通。
目标用户问题
- 顾客能否快速找到门店并进入正确点餐场景
- 顾客能否快速选品、加购、结算、支付
- 顾客付款后能否看到自己的订单和状态
版本范围
核心页面
T01 首页T02 点餐页T03 订单页T04 我的页（基础版）C01 商品详情抽屉C02 购物车抽屉P03 结算确认页P04 支付成功页P05 订单详情页P18 堂食扫码确认页
必要支撑页
P01 门店选择页（轻量版）P02 地址管理页（基础版）
核心能力
- 门店选择与场景切换
- 商品分类浏览与商品详情选择
- 规格、加料、数量联动
- 购物车与金额汇总
- 结算页金额明细展示
- 微信支付占位与支付成功回流
- 订单列表、订单详情、基础状态表达
本阶段不追求
- 完整会员资产闭环
- 全部营销会场与复杂优惠组合
- 售后评价全部细节
- 精细化消息与推荐系统
成功标准
- 顾客可以从首页进入交易链路并形成订单
- 外卖、自提、堂食 3 种场景至少完成基础差异表达
- 下单后可在订单页和订单详情页找到订单
3.3 G2 V1.1 履约服务版
阶段定位
在 V1.0 基础上，把履约透明度与售后能力补齐，让小程序具备完整服务体验。
版本范围
P06 退款申请页P07 退款详情页P08 评价页- 回补
T03 订单页 - 回补
P05 订单详情页
核心能力
- 待支付继续支付 / 取消订单
- 订单履约时间轴
- 外卖配送、自提取餐码、堂食桌号展示
- 退款申请、退款状态查询
- 订单评价、匿名评价、晒图评价
- 再来一单入口
成功标准
- 顾客知道订单当前走到哪一步
- 顾客能看见退款入口、处理进度和结果
- 已完成订单能评价，评价后能回流到订单或复购场景
3.4 G3 V2.0 会员资产版
阶段定位
从“做完订单”升级到“让顾客愿意回来”，建立用户资产和长期关系。
版本范围
T04 我的页（完整版）P09 领券中心页P12 会员中心页P13 积分商城页P14 储值充值页P15 次卡页
核心能力
- 展示会员等级、成长值、权益、会员日信息
- 展示并领取优惠券
- 展示积分余额、积分获取与兑换能力
- 展示储值方案、充值记录、余额支付入口
- 展示次卡购买、核销、剩余次数
- 让资产在结算页有实际承接入口
成功标准
- “我的”页不再只是资料页，而是复购与留存中心
- 顾客能理解自己拥有哪些资产、如何使用这些资产
- 会员资产与结算页面存在清晰闭环
3.5 G4 V2.1 营销增长版
阶段定位
从“顾客可复购”升级到“商家可持续做增长”，让后台营销能力在前台有承接页和转化路径。
版本范围
P10 秒杀活动页P11 限时折扣活动页- 回补首页活动区与点餐页活动承接
- 回补领券中心与结算优惠展示
- 接入新客有礼、满减活动、活动日历类运营能力
核心能力
- 新客礼包导流
- 满减自动命中与说明
- 秒杀会场与倒计时表达
- 限时折扣专区与商品承接
- 首页 Banner、活动宫格、专题入口
- 老客复购推荐、最近下单商品推荐
成功标准
- 商家配置的营销活动能在 C 端被顾客感知并参与
- 活动不只是“展示”，而是能引导进店、加购、结算和支付
3.6 G5 V3.0 精细运营版
阶段定位
从“有交易、有增长”升级到“有精细化经营能力”，让 C 端不仅承接交易，也承接服务和用户经营。
建议范围
P16 消息中心页P17 帮助中心页- 回补首页个性化推荐与用户画像相关模块
- 回补“我的”页服务区、消息区、客服区
- 规划未来扩展：发票、客服、投诉、电子会员码、常购清单、个性化券包
核心能力
- 订单消息、营销消息、系统通知的聚合触达
- FAQ、客服、售后帮助、自助指引
- 基于顾客历史订单和会员标签的商品推荐
- 基于活动日历与用户标签的个性化营销承接
- 为未来 CRM、财务票据、顾客洞察留前台入口
成功标准
- 小程序从“下单工具”升级为“用户经营载体”
- 顾客在 C 端能获取服务、消息、活动、资产、订单等全维度体验
4. 全周期能力分层
| 能力域 | 说明 | 主要版本 |
|---|---|---|
| 交易域 | 选店、点餐、购物车、结算、支付、订单 | V1.0 |
| 履约域 | 配送、自提、堂食、时间轴、退款、评价 | V1.1 |
| 资产域 | 会员、优惠券、积分、储值、次卡 | V2.0 |
| 增长域 | 新客礼、满减、秒杀、限时折扣、复购推荐 | V2.1 |
| 服务域 | 消息、帮助、客服、服务入口 | V3.0 |
| 经营域 | 个性化推荐、顾客标签、票据与更多增值能力 | V3.0+ |
5. 各版本之间的依赖关系
V1.0是所有后续版本的底座，没有交易闭环，后续资产和营销没有承接意义V1.1解决“下单后怎么办”，否则订单体验不完整V2.0解决“顾客为什么愿意回来”，是复购的基础V2.1解决“商家如何主动做增长”，是运营放大的关键V3.0解决“如何长期经营顾客关系”，是品牌化和精细运营的关键
6. 推荐落地原则
6.1 不要按页面数量推进，要按闭环推进
- 优先级不取决于页面多不多，而取决于是否能形成业务闭环
6.2 不要把所有后台能力一次前置到 C 端
- 后台配置能力很多，但前台承接必须按用户价值和转化优先级上线
6.3 每个版本都要有明确“上线后可验证的结果”
V1.0看下单成功率与订单可见性V1.1看退款与评价路径是否清晰V2.0看资产使用率与复购率V2.1看活动参与率与转化率V3.0看消息触达率、留存和用户活跃度
7. 与现有文档的关系
docs/02-信息架构与路由.md负责定义“页面怎么挂”docs/03-全局业务规则.md负责定义“业务怎么跑”docs/04-核心用户流程.md负责定义“顾客怎么走”docs/05-页面清单总表.md负责定义“有哪些页面”docs/08负责定义“整个项目分几期做”docs/09负责定义“后台能力如何映射到 C 端”docs/10负责定义“研发实施时先做什么、交付什么”