自建配送平台还是外包运力：系统侧对照清单

自建配送平台还是外包运力，系统侧先对照主账、权限、规则与回写。买系统与买运力是两笔采购。

图注｜系统侧先对照

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

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

自建强调自用系统与自管运力；外包强调第三方履约服务。

主账在谁那里；规则谁说了算；异常以哪边单据为准；费用能否回写；权限能否按组织隔离。

图注｜主账归属

更宜自建：连锁自配、区域品牌、多级分润。更宜外包：短期覆盖、运力空洞。组合：专配托底+外包溢出，须写分流。

图注｜回写规则

外包单进不进自用任务池；完成后费用是否回写；门店看到的状态是否同源。

云虎配送宝站在系统侧，支撑自建闭环与可配置规则；外包运力按项目确认，不作覆盖承诺。

八、外包扩大时的风险信号

信号一：自有主账变空账。信号二：异常只能在对方后台查。信号三：门店与调度状态长期不一致。出现信号，先修回写与分流，再谈继续加外包量。

九、自建扩大时的风险信号

信号一：规则空站增多。信号二：改派靠群。信号三：对账回不到原单。这是系统治理问题，不是再外包就能自动修好。

十、决策会上的一页纸

左栏自建条件，右栏外包条件，底栏组合规则与不在范围。一页纸能减少会后各说各话。

结论：自建还是外包，先对照系统侧四件事。对照清楚再组合，比口号二选一更可落地。

十一、财务视角的选择

自建更利于活动规则与分润自治；外包更利于短期成本柔性。财务要问的是：费用能否回原单、活动能否进费用结构、退款如何回退。自建配送平台还是外包运力，财务口径先统一，再谈组织偏好。

十二、法务视角的选择

外包合同看履约责任与数据；系统合同看交付范围与授权。两份合同不要共用一个「平台合作」标题糊弄过去。

十三、运营视角的组合操盘

早午晚不同策略：午高峰专配+溢出，夜间可提高众包比例。策略写在规则，不写在群公告。系统侧先对照，操盘才有把手。

十四、落地补充

自建配送平台还是外包运力的决策，建议设置复盘点：上线30天看空账率与状态不一致率。指标变差就回调组合比例，而不是情绪化全切某一边。

十五、场景化验收怎么写才不空

把验收写成「场景 → 动作 → 可见结果」。例如：门店发一单，调度可见待派，骑手完成后后台与商家进度同号，财务能按单号找回费用分项。任何一步靠截图或口头补状态，都算未通过。写清场景化验收，比写「功能齐全」更能挡住范围漂移。

十六、培训与制度最小包

系统上线当天，至少准备三份一页纸：门店怎么发单与看进度，调度怎么改派与关异常，财务怎么抽检回原单。一页纸不够文学，但够用。没有最小包，再好的同城配送能力也会退回微信群。

十七、数据与演示隔离

后台演示数据、测试骑手、测试门店要与正式经营数据隔离，避免把演示商户写成客户案例，也避免测试单污染对账。权限上运维账号与业务账号分开，关键操作可审计。

十八、扩量前的冻结检查

试点通过后设短冻结：只观察异常结构与对账断链率，不天天改核心规则。冻结期能看出系统是否真的在跑，还是现场仍靠熟人。冻结通过再复制站点模板、再开渠道、再谈编制。云虎配送宝提供可配置的订单、调度、运力、商家与结算能力；是否冻结、何时扩量，由客户项目管理决定。买系统解决单与账，买运力解决人与车，两件事始终分列。

十九、表述与合同对齐

对外材料删除日单量保证、覆盖保证、终生免费升级、合规包过等绝对化句子。对内合同与验收用例使用同一套边界语言。对齐之后，售后争议会明显下降。郑州云虎软件是软件与技术支持方，不自营、不运营同城配送运力平台，也不代替客户招聘骑手或承诺单量。

二十、收尾前再核三问

三问是：主账是否同源，改派是否留痕，流水是否回原单。三问都通，才谈扩店扩渠道扩编制。任一不通，先修系统与制度。把三问贴在调度台与项目群置顶，比再开一次动员会有用。云虎配送宝用于配置订单、调度、运力、商家与结算等业务链路；运力组织与经营结果仍由客户自行确定。