此山茶场 · 商家端 V1

先定边界,再开始做后台

商家端 V1 建议做成茶场自用的轻量运营后台,服务扫码点单、出餐、商品维护、茶礼处理、基础配置和异常处理;它不是完整 ERP,也不做人工点单或收银台。

文档状态已确认通过
关键决策7 项
确认后进入S2 基础配置

最重要的一句话

V1 先保证能营业、少出错、好上手,不把后台做重。

第一开发模块

建议先做基础配置,因为用户端首页、我的页、营业时间、电话、导航都依赖它。

资金相关底线

支付、退款、余额、好友卡流水必须先写技术文档,再开发真实资金能力。

已确认的 7 个关键决策

这 7 条已完成 PM 确认,后续 PRD、原型和开发都按这些边界推进。

待确认
S1-C01

商家端 V1 是否定位为轻量运营后台?

建议结论:是。V1 不做完整 ERP,先服务真实营业动作。
  • 它负责订单处理、制作看板、茶礼处理、商品维护、基础配置和异常处理。
  • 店长能看到今日待办,现场员工能快速处理已支付订单。
  • 后续可以扩展权限、数据统计和更复杂经营能力。
确认后范围更清楚,S2/S3/S4 可以按模块推进。
如果不确认后台容易膨胀成 ERP,拖慢上线。
原文:第 3、4、11 章
S1-C02

是否不做商家端人工点单 / 收银台?

建议结论:是。用户扫码,自助下单并完成支付,商家端只处理已支付订单。
  • 不做员工替用户点单,不做前台收银。
  • 不做报手机号扣会员余额。
  • 不做好友卡截图或口头核销。
确认后订单和资金链路更简单,更适合 MVP。
如果不确认会引入收银、权限、对账、误扣等复杂问题。
原文:第 4.2、7.1、7.5 章
S1-C03

是否采用“角色权限 + 工作模式”?

已确认方向:是。后台角色不能写死,V1 支持角色配置和页面级功能权限;暂不做数据权限和按钮级权限。
  • 角色里可以勾选功能权限,第一版先做到页面级别。
  • 暂不做数据权限,例如“只能看自己订单”或“只能看某门店数据”。
  • 暂不做按钮级权限,例如某个页面里的“退款”“删除”“导出”按钮是否可操作。
  • 工作模式用于组织页面体验,不替代角色权限。
确认后后台有权限底座,又不会被复杂权限拖慢第一版。
如果做得更深数据权限、按钮级权限和审批流会显著增加设计和开发量。
原文:第 4.1、5 章;后续需单独权限 PRD 细化
S1-C04

P0 是否包含 6 个必做模块?

建议结论:是。基础配置、商品、点单订单、制作看板、茶礼订单、商家端首页进入 P0。
  • 基础配置避免用户端写死茶场信息。
  • 商品、点单订单、制作看板决定能否现场营业。
  • 茶礼订单和商家端首页支撑茶礼闭环与日常管理。
确认后V1 主干完整,能覆盖点单和茶礼。
如果不确认后续排期会反复摇摆,容易漏主链路。
原文:第 6.1 章
S1-C05

P1 是否包含会员、好友卡、经营数据?

已确认:是。它们属于 V1 范围内,但开发顺序放在后面;经营数据优先级建议放在会员 / 好友卡之后,先做基础看板,不做复杂 BI。
  • 会员与充值管理用于查询、充值记录、消费记录、退款流水。
  • 好友卡管理用于列表、详情、流水、关联订单和异常查询。
  • 经营数据先做基础看板,不做复杂 BI。
确认后不会遗漏会员好友卡,但不抢 P0 资源。
如果不确认可能过早做复杂会员系统,影响上线节奏。
原文:第 6.2、7.5 章
S1-C06

第一开发模块是否为基础配置?

建议结论:是。先做基础配置,再做商品和订单。
  • 茶场名称、地址、电话、营业时间、停止接单、首页轮播图都应从后台配置。
  • 这能避免用户端页面写死信息。
  • 也为订阅消息、物流 API 等后续配置留入口。
确认后可以直接进入 S2-T001 基础配置 PRD。
如果不确认用户端和后台会反复临时写死信息。
原文:第 7.4、8 章
S1-C07

资金相关模块是否坚持先技术文档后开发?

建议结论:必须坚持。支付、退款、余额、好友卡流水不能直接边想边写代码。
  • 真实支付和退款涉及密钥、回调、对账和资金安全。
  • 好友卡和会员余额都需要流水可追溯。
  • staging 默认 mock 支付,prod 才进入真实支付链路。
确认后资金安全底线清楚,后续开发更稳。
如果不确认容易产生资金错账、退款漏洞和不可追溯问题。
原文:第 8、10 章;S0 技术决策

模块范围:哪些现在做,哪些后置,哪些不要做

这一块是防止商家端变大的护栏。P0 是 V1 主链路,P1 是要预留但可以后置,P2 是本阶段明确不做。

P0 必做

  • 基础配置
  • 商品管理
  • 点单订单管理
  • 制作看板
  • 茶礼订单管理
  • 商家端首页

P1 可后置

  • 会员与充值管理
  • 好友卡管理
  • 经营数据统计,优先级建议在会员 / 好友卡之后

P2 暂不做

  • 复杂 ERP / 多门店 SaaS
  • 复杂数据权限、按钮级权限、审批流权限
  • 人工点单 / 收银台
  • 优惠券、积分、会员等级
  • 小票打印、语音播报
  • 好友卡截图 / 口头核销

角色权限 + 工作模式

角色权限解决“谁能看哪些页面”,工作模式解决“进入页面后如何高效完成现场工作”。两者一起用,不把角色写死。

角色配置

可以创建和编辑角色。店长、员工、制作人员、茶礼处理人员可以作为默认模板,不写死为唯一选择。

页面级功能权限

角色可勾选能进入哪些页面,例如订单处理台、制作看板、茶礼订单、商品管理、基础配置、会员好友卡。

V1 暂不做

暂不做数据权限、按钮级权限和复杂审批流。比如“只能看自己订单”“退款按钮是否可点”后续再细化。

商家端首页

今日概览、异常待办、退款、商品状态和快捷入口;可支持今日 / 本周 / 本月的基础切换。

现场订单模式

处理用户已支付订单:接单、制作、可取餐、确认取餐。

制作 / 茶礼模式

制作看板低干扰盯单;茶礼处理发货、物流、自提核销和异常订单。

核心业务边界

这一部分是完整方案的主体。它不是让你立刻确认每个字段,而是帮你建立全局视角:商家端 V1 到底管什么,不管什么。

点单订单

  • 支持待接单、制作中、可取餐、已完成、已取消。
  • 订单详情展示取餐号、商品、规格、金额、支付方式、下单时间。
  • 支持接单、开始制作、完成制作、确认已取餐。
  • 支持整单退款和部分退款。
  • 好友卡支付订单进入同一套订单状态流转。

点单不做

  • 不做员工手动创建普通点单订单。
  • 不做员工代客收银。
  • 不做送到座位。
  • 不做外卖配送。
  • 不做小票打印。

商品管理

  • 支持分类、商品名称、价格、图片、说明。
  • 支持上架、下架、售罄。
  • 支持规格和制作分组。
  • V1 不做真实复杂库存。
  • 茶礼商品库存可先用宽松数值或状态控制。

茶礼订单

  • 支持待发货、待提货、已发货、已完成、已取消。
  • 支持物流公司和物流单号。
  • 支持自提码核销。
  • 支持发货提醒和取消规则。
  • V1 快递统一到付,小程序只收商品金额。

基础配置

  • 茶场名称、地址、联系电话、营业时间。
  • 停止接单时间、首页轮播图、地图导航地址。
  • 是否展示电话 / 客服入口。
  • 微信订阅消息模板配置。
  • 物流 API 配置。

会员与好友卡

  • 商家端只做管理、查询、流水和异常处理。
  • 好友卡由用户端创建。
  • 接收人授权手机号后领取。
  • 接收人在自己的小程序内使用。
  • 商家端不做报手机号扣款。

首页与经营数据

  • 商家端首页是 P0:轻量概览、待办、快捷入口。
  • 首页可支持今日 / 本周 / 本月基础切换。
  • 经营数据是 P1:更完整的数据统计页。
  • 经营数据优先级建议放在会员 / 好友卡之后。
  • 第一版做基础看板,不做复杂 BI。

推荐开发顺序

这不是最终排期,但它能帮助我们先做依赖最前面的东西,减少返工。

S2 基础配置用户端首页、我的页、电话、导航、营业时间依赖它。
商品管理点单和茶礼都依赖商品、分类、上下架和售罄。
点单订单 / 制作看板核心现场链路,决定能否营业。
茶礼订单支撑发货、自提和物流闭环。
支付退款资金底座先技术文档,再开发真实资金能力。
会员余额 / 好友卡依赖支付退款、余额流水和订单闭环。
经营数据统计等订单、商品、支付数据稳定后再做。

风险与护栏

这几条是后面最容易走偏的地方。确认 S1 的目的,就是提前把护栏立起来。

风险影响控制方式
商家端范围膨胀后台越做越大,影响上线P0 / P1 / P2 明确分层
现场员工页面过重接单制作效率低商家端首页和制作看板分开
人工点单入口混入 V1资金和订单复杂度上升明确不做商家端人工点单 / 收银
好友卡被误解为前台核销产生误扣和争议好友卡只在用户端自助使用,商家端只查询和异常处理
退款规则遗漏影响资金安全支付退款模块必须先技术文档
基础配置后置用户端写死茶场信息S2 优先做基础配置