员工餐 三场景
- 预定堂食：计次或计重，可配置
- 现场就餐：计重或计次，可配置
- 盒饭预定：按份计次
- 餐盘与员工绑定有效时，跳过绑盘机
拼团报名之后，不立即支付；成团通知之后，按员工餐或客餐规则在用餐时结算
本方案基于现有智慧食堂 PC 与小程序界面重做，重点验证拼团批次、对象分流、餐盘绑定、计重/计次和通知状态是否能形成一条可落地业务闭环。
产品决策
拼团只解决“菜单提前聚合和达到供餐门槛”，结算发生在真实用餐动作上。员工餐与客餐建立独立规则和批次，不在同一条流程里靠文案区分。
客餐 固定单一路径
- 只允许小程序单独预定盒饭
- 只允许按份计次结算
- 不开放堂食、现场、计重和餐盘绑定
扣款归属待客户确认：接待部门 / 招待账户 / 个人 / 线下结算。
业务流程
管理员定期发布菜单与成团门槛
员工餐 / 客餐生成独立批次
小程序报名
截止时判断是否达到门槛
成团后通知管理员与报名人员
员工计重/计次
客餐盒饭计次
客餐盒饭计次
生成结算回执与批次进度
关键原型
可落地功能清单
| 模块 | 本期功能 | 上线门禁 |
|---|---|---|
| 拼团发布 | 对象、菜单、周期、门槛、截止时间、用餐时间、通知策略 | 发布后固化规则快照 |
| 员工餐结算 | 堂食预定、现场就餐、盒饭；计重/计次；餐盘绑定免绑盘 | 确认各场景允许的计价方式和绑定来源 |
| 客餐结算 | 小程序盒饭预定、按份计次 | 扣款归属未确认时禁止真实结算 |
| 批次看板 | 报名、成团、通知、结算四类状态独立展示 | 异常重试不得改写业务事实状态 |
| 结算接口 | 对象/场景/方式组合校验、结算回执、幂等键 | 接真实账户、设备和对账前完成接口契约评审 |
请你重点评审这 5 项
客餐最终扣到个人、部门成本中心、招待账户，还是线下结算？
员工预定堂食是否允许计重，还是只有现场就餐允许计重？
餐盘绑定复用现有系统还是新建服务？有效期和换盘规则是什么？
成团门槛按人数、总份数，还是每个菜品 SKU 分别计算？
成团通知使用企业微信、小程序订阅消息，还是两者同时发送？
原型边界：当前使用本地模拟数据，不接生产数据库、真实计费设备、真实扣款或真实消息通道。页面中的“已通知”“已结算”只代表流程演示。
验收状态
PC 构建通过移动端构建通过接口正反向校验通过12→15 人成团通过员工计重+免绑盘通过客餐盒饭计次通过未成团边界通过控制台无阻断错误