O2O多门店小程序方案前期需要准备哪些资料？

多门店项目最容易出现的误会，是把“门店列表”当成多门店方案。页面上能找店、能导航，只说明门店展示做出来了；一旦再加到店自提、预约、配送、门店库存、会员余额或跨店售后，总部和门店之间原本没有说清的关系就会一起冒出来。

红数科技在方案前期更关心一笔真实订单能不能讲完整：顾客进入小程序后怎样选店，看到哪套商品和价格，库存从哪里来，订单由谁确认，缺货时谁处理，退款退到哪里，财务最后怎样核对。这笔订单能从选店一直讲到售后，门店资料才算落到了真正的业务上。

先确认门店是同一套生意，还是各自经营

“直营网点、加盟店都有”还不足以确定系统怎么做。前期需要逐类说明门店与总部的关系。

直营网点通常由总部统一经营，但商品、库存和履约可能落在各门店。加盟店使用同一品牌，不代表总部可以替门店收款、开票或处理全部售后。联营店、经销网点、服务站也可能只共享品牌入口，交易主体仍然不同。表面上都是门店，后台权限、支付路径和责任边界差别很大。

先准备一页业务关系说明，写清这些问题：

• 哪些门店是直营、加盟、联营或仅作展示的服务网点；
• 顾客实际向总部还是门店购买，页面需要显示哪个经营主体；
• 商品、服务、价格、库存、优惠和营业状态分别由谁维护；
• 门店能否拒单、改价、退款、停用商品或调整可预约时间；
• 收款、结算、开票、售后和投诉分别由谁承担；
• 会员、积分、储值、优惠券能否跨店使用，成本由谁承担。

这一步会直接影响账号、支付、订单和会员设计。若各门店是独立经营主体，项目可能需要进一步核对平台型交易、商户进件或分账能力，不能按普通单商户小程序先做完再补。

建一份能直接导入系统的门店台账

门店资料不宜散在地图收藏、群聊定位和营业执照照片里。建议先用表格建立统一门店台账，每家店一行，并设置不会随门店改名而变化的门店编码。

选择三到五家差异明显的门店做样本更有效：一家正常营业店、一家有独立价格的加盟店、一家仅预约服务的门店，再加一家即将开业或暂停营业的门店。样本能覆盖这些差异，字段和后台状态才不容易漏。

主体、账号、备案和类目资料要按实际功能准备

账号资料至少要明确小程序主体、管理员、项目成员、AppID、现有认证与备案状态；如果还要关联公众号、企业微信、开放平台或已有商户号，也要画清账号归属。管理员应由企业能够长期管理的人担任，避免上线后关键账号仍由临时员工或外部个人控制。

单位主体办理小程序备案时，通常需要主办单位证件、主体负责人和小程序负责人的身份与联系方式、实际通讯地址、小程序服务内容等资料；涉及新闻、出版、药品和医疗器械、网约车等服务时，还可能需要前置审批文件。小程序已经注册，不等于备案和具体业务许可自然完成。

服务类目要根据小程序真正提供的服务选择，不能只看企业营业执照上写了什么。餐饮点单、教育培训、医疗服务、酒类销售、出版物交易等功能，所需材料并不相同。微信开放文档也明确提示，服务类目及材料会随政策、法规和平台要求变化，应以实际提交时后台要求为准。

因此，资料夹里除了总部证照，还要放入与门店和业务对应的许可证、品牌或商标授权、门店经营授权、证件有效期记录。证照名称、主体名称、门店地址和实际功能对不上时，应先确认解决方式，而不是等提审退回后再找材料。

商品和服务资料要先确定“总店模板”和“门店差异”

多门店最常见的数据问题，不是少几个商品字段，而是没有确定同一件商品在不同门店之间是什么关系。

如果总部维护标准商品库，门店通常只维护是否在售、门店价和门店库存；如果门店可以自建商品，就需要额外确认商品审核、分类统一、图片版权和搜索归类。服务预约也是一样：总部可以统一定义服务项目，但服务时长、可约员工、可约时间和价格可能由门店分别维护。

前期应提供一批真实商品或服务样本，至少覆盖：

• 总部统一价格、门店独立价格和临时促销价；
• 单规格、多规格、加料或可选服务项；
• 全门店在售、部分门店在售和门店临时停售；
• 实时库存、每日限量、无需库存和到店后确认；
• 仅自提、可配送、需预约或到店核销；
• 退款条件、过期处理、使用门店和不可用时段。

商品名称、编码、规格、图片、详情、价格、库存单位、适用门店和履约方式最好放在结构化表格中。把价格表做成图片、把可用门店写进详情长图，短期看省事，后面门店变动、搜索筛选和批量更新都会变得很难。

订单规则要覆盖选店、履约和异常处理

多门店小程序要先决定选店发生在什么时候。顾客可以先选店再看商品，也可以先看商品，再由系统根据地址、库存或服务能力推荐门店。这两个路径会影响首页、购物车、库存校验和订单归属。

前期资料不能只写“支持自提、配送、预约”。每一种履约方式都要说明正常流程和例外情况：

• 到店自提以哪家门店的库存为准，提货码由谁核销，能否改店；
• 同城配送由门店、总部仓、第三方运力还是顾客自选方式履约；
• 预约按门店、服务项目、员工还是房间排期，迟到和爽约怎样处理；
• 门店缺货、超时未接单、临时闭店、部分商品取消时由谁联系顾客；
• 跨店购物是否允许，一次支付后是否拆成多张门店订单；
• 售后能否跨店办理，原下单门店关闭后由谁接手。

最好准备几组订单样例，让运营、门店、财务和开发一起走一遍。正常下单只是其中一组，改门店、部分缺货、使用总部券、门店退款、已核销后申诉也应该有人给出处理口径。

支付、会员和优惠资料要算到账

需要在线收款时，应准备商户号归属、超级管理员、结算账户、支付场景和现有商户配置，并确认小程序主体与商户号的关系。微信支付的小程序下单接口只解决支付发起这一步，门店款项怎样归集、怎样结算以及退款和对账如何落地，仍要根据真实经营关系设计。

财务至少要确认：款项进入总部还是门店账户，支付手续费由谁承担，退款从哪里退，发票由谁开，门店业绩按下单、支付、核销还是售后完成计算。若有加盟店结算，还要准备一笔带优惠和退款的算例，明确商品款、配送费、平台补贴、门店优惠与退款各自怎么分摊。

会员资料也不能只写“积分、等级、优惠券、储值”。要先说明会员归总部还是门店，注册时用什么作为唯一身份，历史会员如何迁移，余额和积分由谁承担，跨店消费怎样记账。已有 CRM、收银或储值系统时，需要提供字段说明、脱敏样本、接口文档和测试条件。余额类资产迁移还应安排迁移前后核对，不能只看导入条数。

后台权限、接口和数据来源要落实到人

总部运营、区域负责人、店长、店员、客服和财务看到的内容不同，能做的动作也不同。前期可以用一张权限表确认谁能查看、修改、审核、导出和退款，尤其要单独核对手机号、地址、订单导出、价格修改、会员资产和财务数据。

若项目需要连接 POS、ERP、WMS、CRM、预约、配送、电子发票或数据分析系统，资料不能只写系统名称。还要准备接口文档、版本、部署方式、测试账号、测试环境、调用限制和对接负责人。更关键的是确定每项数据的准数在哪里：门店营业状态由谁维护，价格冲突听哪套系统，库存多久同步一次，订单和退款由谁回传。

接口暂时拿不到，可以列为待验证项；在没有完成接口验证前，不应把“实时库存”“自动同步”写成已经确定的交付范围。

隐私、协议和素材授权要跟着实际页面走

多门店小程序经常使用定位、收货地址、手机号、预约联系人、发票信息和订单记录。前期需要做一张个人信息清单，逐项写明在哪个页面收集、为什么需要、是否可以不提供、保存多久、哪些岗位能看、是否提供给配送或其他第三方，以及用户如何撤回授权或申请删除。

微信开放文档要求，开发者处理用户个人信息时补充用户隐私保护指引，提审版本还会核对实际调用的隐私相关接口和指引内容。不能先套一份通用隐私模板，再让功能去迁就模板。

同时准备用户协议、会员规则、优惠券规则、预约或配送说明、退款售后规则、发票说明，以及图片、字体、视频、商标和门店照片的使用依据。哪些内容由总部统一发布，哪些允许门店自行上传，也要写进审核与下架规则。

开工前，把资料整理成七个可确认的文件包

资料不必在第一次沟通时全部做成最终稿，但影响主体、交易和数据结构的内容不能一直留空。可以按下面的顺序整理：

01_业务关系与项目范围
02_主体账号备案与行业资质
03_门店台账与门店素材
04_商品服务价格与库存规则
05_订单履约支付与会员规则
06_角色权限接口与迁移资料
07_隐私协议测试与验收用例

方案和报价前，至少应给到业务关系、代表性门店台账、核心商品或服务样本、履约方式、收款结算口径和现有系统清单。进入视觉与开发前，再补齐正式素材、完整数据、异常规则、接口条件、隐私协议和验收用例。

开工前，选一家直营店、一家加盟店、两个有门店差异的商品，再安排一笔带优惠的订单。从顾客选店开始，走到门店接单、核销、部分退款和财务对账。每一步都能说出用哪份资料、由谁处理、以什么结果为准，这套多门店小程序方案才具备开工条件。

参考资料

以下公开资料核验于 2026 年 7 月 24 日。平台类目、申请材料、审核流程和接口能力可能调整，实际项目应以申请或接入时的官方页面为准。