多品牌连锁餐饮点餐与结算平台

项目背景

客户是一家面向连锁餐饮的软件企业，业务同时服务单门店商户、连锁品牌与多品牌平台运营方三类对象，组织层级从平台、品牌、子品牌、区域一直到门店，还存在同一门店内经营多个品牌的复合店形态。堂食点餐、收银、后厨制作、出餐送餐、门店管理、供应链采购与多方结算在同一条链路上环环相扣：顾客扫码点餐经 POS 推送 KDS，KDS 出餐后通知 WST 服务员终端送餐，再回写服务与账务数据。层级深、端多、正餐与快餐模式分叉、结算主体不止两方，使口径确认本身成了项目的第一道难题。

客户当时的状态

委托进入时没有一份能对齐的功能清单：各端要做什么、谁负责、做到什么算清楚，多数停留在口头与零散文档里。同一功能在门店、区域、品牌三级看到的数据范围不同；正餐与快餐的订单状态流转不同；自采与集采的付款对象与触发时机也不同。若直接开工，开发会把这些分歧固化成返工。

我们的做法与取舍

第一个取舍是先固化口径再谈开发。我们按角色视角逐条梳理功能诉求并区分优先级，把系统收敛为七个使用端：统一管理后台、POS 收银、KDS 后厨、WST 服务员终端、供应商门户，以及顾客与员工两个小程序端。取舍点在于不再增加端的数量——现场作业、总部管理与外部协同各自归位，避免同一个动作在多处重复实现。

第二个取舍是先画通正向链路，再补逆向。点餐、制作、出餐、送餐这条主线先按正餐与快餐分别定义状态流转：正餐走点单、就餐到结账，快餐走点单、制作到取餐。退菜、退货、退款、挂账逾期、盘点差异这些反向流程，在首轮功能完整性检查中被识别为断点，我们在开发前补齐其设计并逐项标注缺失环节，而不是留到联调阶段才暴露。

第三个取舍是用可交互原型承担评审，而不是用文档作承诺。七套前端原型分别承载顾客端、门店后台、POS、KDS、WST、供应商门户与员工端，让客户在逐端点击中确认界面与流程口径。原型由本地模拟数据驱动，不含生产服务与真实支付通道，这一前提在评审材料里写在最前面。

方案如何承载多品牌经营

组织与权限按层级与复合店结构设计，统一管理后台按角色输出差异化菜单与数据范围，POS 与 KDS 需支持多品牌切换场景。食安侧把出品质检嵌入主链路：制作完成进入待质检队列，合格放行方可送餐，多次不合格触发异常上报与整改任务；食材侧按供应商录入、核验、审核、生成溯源码，消费端的发布状态由品牌控制。结算侧区分门店付供应商的自采、品牌付供应商的集采，以及集采下品牌向门店做的内部清算，三类关系的资金流向与触发时机（货到付款、账期到期、供应商开票）分别定义，并覆盖采购退货的逆向结算。门店侧的排班建议由历史数据与客流预测生成，规则可配置、发布前需审批；另设数字运营官角色承担收银辅导、数据解读培训与问题整改跟进。

原型阶段的架构边界

公开架构归纳为五层：使用入口承载七个端；业务服务承载点餐闭环、门店运营、供应链与结算；平台能力提供分层权限、多品牌与复合店切换、报表与消息提醒；外部渠道是支付与分账、短信推送、对象存储、物流查询与银行接口等第三方依赖，需客户侧先行提供资质、凭证与协议；数据底座支撑跨品牌、跨门店的汇总与追溯。本阶段只有入口层是可交互前端，业务与数据由本地模拟数据呈现，服务端实现与第三方通道未在本阶段核验，网络拓扑、服务器配置与账号凭证一律不公开。

本稿公开的范围与后续

本稿公开的是业务方案设计与多端可交互原型验证这一段的范围与做法：功能优先级梳理、系统划分、正向与逆向链路的业务分析，以及承载评审的前端原型。合同与排期文件中的后续开发、联调、测试与验收安排属于计划目标，未作为已完成的事实引用；实际建设范围、上线时间与业务效果，以双方正式文件与实施结果为准。