商家发单系统：门店下单到履约分步对照

商家发单系统要管的是门店从下单到履约可见、账可回原单，而不是另起一套账本。先跑通一单三端同口径，再扩门店与渠道。

图注｜发单与主账同源

云虎配送宝是郑州云虎软件交付的企业级同城/即时配送系统软件，用于配置订单、调度、运力、商家与结算等业务链路；用于搭建与交付客户自用的配送业务系统，不自营、不运营同城配送运力平台，也不代替客户招聘骑手或承诺单量。选型先分清「买系统」与「买运力」：系统管单与账，运力由客户自建或对接第三方。

建议按对象验收：门店认证与资料审核状态；自发单的物品、取送地址、预约时间、费用确认；第三方来源订单进入后的发单或履约协同；账户充值、明细与配送进度查看。

少做的是把商家端做成脱离后台的独立财务王国。

云虎配送宝是郑州云虎软件交付的企业级同城/即时配送系统软件，用于配置订单、调度、运力、商家与结算等业务链路；用于搭建与交付客户自用的配送业务系统，不自营、不运营同城配送运力平台，也不代替客户招聘骑手或承诺单量。选型先分清「买系统」与「买运力」：系统管单与账，运力由客户自建或对接第三方。

第一步门店就绪：入驻审核通过，业务配置与后台一致。第二步发一单：选物品类型、选地址与时间、确认费用并发单。第三步看履约：待接、在途、完成或异常可在商家侧查看，且后台同单号。第四步对一笔账：扣款或余额变动能回到该订单费用分项。

图注｜费用分项可回查

商家端负责发单与进度感知；后台负责规则、调度、权限、对账与异常总控；骑手端负责接单履约与完成凭证。三端分工清晰，才不会出现门店说已送达、调度说未派出。

图注｜渠道单与自发单同口径

若门店同时接线上渠道订单，系统价值是多来源进入同一主账后再履约。渠道对接资料可写如麦芽田、青云等可对接范围；勿写成全平台零人工。

适用：连锁或单店自配、需要门店自助发单与监控的团队。不适用期望：软件方替门店运营、替门店保证出餐与打包质量、替门店承诺配送时效结果。

云虎配送宝商家发单端与管理后台商家、订单、调度模块配合，形成门店发单到运力履约的闭环；财务流水支撑门店侧查询。

结论：商家发单系统要管的是门店从下单到履约可见、账可回原单。先跑通一单三端同口径，再扩门店与渠道，比先发一堆未对齐的单更接近可运营。

八、门店培训用同一套状态词

商家发单系统上线后，门店最容易自创状态词：说「走了」可能指骑手已接、也可能指已出餐。建议对内规定与系统状态对齐的口语映射，减少客服翻译成本。系统状态仍以后台为准，门店端只做感知，不另建账本。

九、连锁多店时的发单权限

未审核门店不能发单；已停用门店应离开可发池；连锁账号若能看他店资金，属于权限事故而非功能亮点。商家发单系统与加盟分站、权限管理是同一条链上的不同节，需要一起抽检。

十、商家端常见误用与纠正

误用一：把门店账号借给多人，导致操作无法追责。纠正是一人一号或按岗位授权。误用二：发单后只看聊天群，不看商家端进度。纠正是规定进度以系统为准。误用三：渠道单在店内小票处理，不进系统。纠正是能进主账的单必须进主账。商家发单系统要发挥作用，依赖门店习惯与系统能力一起改，而不是只上线一个APP。

十一、发单费用确认页的验收意义

费用确认页不只是展示数字，它是商家与平台规则对齐的瞬间。若确认页金额与后台订单分项不一致，后续对账几乎必吵。验收时固定抽检：确认页合计、订单费用分项、商家流水变动三者一致。

预约单、加价、优惠同时存在时更要抽检。商家发单系统在这里暴露的是规则是否进主账，而不是界面好不好看。把这一页验稳，门店信任会明显高于「先发了再说」。

十二、商家端与营销活动的边界

优惠券、活动价可以提升下单意愿，但必须进入订单费用结构，商家确认页与后台分项一致。否则活动越成功，对账越痛苦。商家发单系统若与营销模块联动，验收重点仍是主账，而不是活动海报。

十三、连锁督导怎么用商家数据

督导不应只看门店自评，而应能按权限查看本区发单量、取消率、异常单。但督导账号若能改他店资金，则越权。商家发单系统之上，是权限与组织树；二者要一起设计。

十二、商家发单与客服工单的边界

商家发单系统解决发单与进度可见；客服工单解决投诉解释与政策沟通。若客服直接在群里改承诺时效，却不回系统，商家端显示会与真实履约冲突。

建议规定：涉及改派、取消、费用调整，必须落系统动作后再回复门店。商家端看到的状态才可信。系统能力要配上这条纪律，发单APP才不会变成「仅供参考」。

连锁培训可以把「先查单号再开口」写成门店与客服共同习惯。一笔单一个号，比十句安抚更接近可运营。