B2C商城小程序方案前期需要准备哪些资料？

方案沟通刚开始时，一份营业执照、一个 Logo，再加一句“参考某某商城”，是很常见的资料组合。拿它做几张页面效果图没问题；真要把下单、收款、发货和售后跑起来，信息还差得远。

红数科技在方案前期会先确认一件看起来很基础、实际上决定整个项目走向的事：这是谁的商城，卖什么，钱收进谁的账户，货从哪里发，出了售后由谁处理。只要这几句话里还有模糊的地方，功能清单就不可能真正定下来。

资料整理到什么程度才算够？运营说的每一条规则，产品能据此画出流程，开发知道数据怎样处理，测试也能判断结果对不对。到这个程度，报价、工期和验收范围才有可靠依据。文件多不代表准备充分，互相矛盾的十张表还不如一张已经确认过的商品表。

先把商城的经营边界写清楚

B2C 商城通常是企业直接面向消费者销售商品或服务。这里最先要确认的不是首页有几个专区，而是经营主体和交易关系。如果只是企业自营，商品、收款、发货、开票和售后一般都由同一主体承担；如果还允许其他商家入驻、独立结算或自行履约，项目就已经不只是普通自营 B2C 商城，后台权限、结算、合同和合规要求都会明显变化。

先用一页纸把这些问题写明白：

• 商城是品牌自营、经销商零售，还是带有多商户入驻；
• 面向个人消费者，还是同时服务企业采购；
• 销售实物商品、虚拟商品、到店服务，还是几种业务并存；
• 价格是否全国统一，有没有会员价、区域价、阶梯价或员工价；
• 从一个仓库发货，还是按区域、门店或供应商拆单；
• 是否需要发票，开票主体是谁，申请和交付方式是什么；
• 售前、发货、退款、退货、换货分别由哪个岗位处理。

这张业务说明不用写成厚厚的需求文档，关键是不能互相矛盾。比如运营希望同一订单可以跨仓发货，财务却只接受一次开票；会员规则说积分可以抵现，结算规则又没有说明退款时积分怎么退。这样的冲突，越早发现越省事。

资质、账号和负责人资料

这一组资料直接影响小程序注册、备案、服务类目、支付接入和最终发布，应当先核实有效期与主体名称，不要等到提审前再补。

截至 2026 年 7 月，微信开放文档列出的小程序备案材料包括主办单位证件、主体负责人证件、小程序负责人证件，以及按业务需要提交的前置审批或补充材料；负责人还要在平台操作过程中完成核验。新闻、出版、药品和医疗器械等业务可能涉及前置审批，普通商品零售也应按照实际经营内容选择服务类目，不能为了先上线随意选择。

工业和信息化部关于 APP 备案的通知明确，境内提供互联网信息服务的 APP 主办者应履行备案手续；微信的小程序备案指引已经把具体材料和办理入口落到了平台流程里。备案不是开发公司的内部登记，资料最终要由真实经营主体确认。[^3]

微信支付也要单独看待。小程序账号开通了，不等于已经具备收款能力。应当尽早确认商户号是否存在、结算账户是否正常、超级管理员能否配合验证，以及小程序 AppID 与商户号如何关联。微信支付官方接入指引将“小程序”列为独立接入场景，实际申请资料和审核结果以申请页面当时显示的要求为准。

商品资料要达到可以导入的程度

“我们有几百款商品，开发好以后再录”听起来很合理，实际很容易把问题拖到最后。开发阶段至少要拿到一批具有代表性的真实商品，覆盖单规格、多规格、不同运费、缺货、预售、促销和售后限制等情况。否则测试时用的都是同一种演示商品，真实数据一导入，规格、价格和库存问题才会一起冒出来。

商品表建议一行对应一个可独立管理库存和价格的 SKU，至少包含：

• 商品名称、商品分类、品牌和内部商品编码；
• 规格维度与规格值，例如颜色、尺码、容量；
• 销售价、划线价、成本价是否需要进入后台，以及含税口径；
• 可售库存、预警库存、库存单位和扣减时点；
• 重量、体积、运费模板、发货仓和配送限制；
• 主图、详情图、视频、卖点、参数、包装清单和售后说明；
• 上下架状态、开售时间、限购数量和适用活动；
• 条码、ERP 编码或其他需要与现有系统对应的唯一标识。

这里有个很实用的判断：同一款商品如果出现两个编码，团队能不能立刻说明哪个是商城编码、哪个是仓库编码，以及二者怎样对应？说不清，后面的库存同步、发货回传和退款入库都会受影响。

图片也不能只发压缩过的聊天截图。主图比例、详情页宽度、白底图要求、视频封面和版权来源应当一起确认。商品参数不要全塞进详情长图，尺码、材质、保质期等会影响筛选、搜索或售后的信息，最好保留为结构化字段。

把一笔订单从头走到尾

商城方案是否完整，拿一笔订单走一遍最容易看出来。从用户把商品加入购物车开始，依次确认优惠计算、地址校验、运费、支付、库存扣减、拆单、发货、收货、开票、评价和售后。每一步都要有明确规则，不需要的功能也要明确排除。

优惠尤其容易产生分歧。满减、优惠券、会员折扣、积分抵现、赠品和包邮是否可以叠加，按什么顺序计算，退款时优惠如何分摊，都应当写出例子。只给一句“支持优惠券”，开发只能做出最基础的版本，和运营真正想用的玩法往往不是一回事。

售后资料至少要说明：未发货能否直接取消；已发货如何申请退款或退货；是否允许部分商品、部分数量退款；运费由谁承担；赠品是否需要退回；超时如何处理；退款原路退回还是允许其他方式。对于不适用无理由退货、定制或临期商品，还要由企业根据真实经营情况和现行规则准备清楚、可展示的说明，不能让系统默认替企业作决定。

物流部分要提供发货地址、退货地址、合作快递、运费模板、配送范围、偏远地区规则、包邮门槛，以及是否需要电子面单和物流轨迹。多仓、多门店或供应商代发还要补充分仓优先级、缺货处理和一单多包裹的展示方式。

页面资料不只是 Logo 和参考链接

视觉设计需要品牌资料，也需要真实内容。建议整理 Logo 源文件、标准色、辅助色、字体使用要求、品牌图片、商品拍摄规范和已有宣传物料。若企业没有完整 VI，可以明确希望保留的品牌特征和不能使用的表现方式，不必临时拼一套看起来很全、实际没人遵守的规范。

首页要展示什么，最好先由运营给出业务优先级。新品、爆款、活动、内容种草、分类入口、会员权益，不可能同时占据最显眼的位置。参考小程序可以帮助说明偏好，但需要指出具体参考哪一处，是导航方式、商品卡片、配色，还是结算路径。只说“照这个做”，既容易涉及不必要的模仿，也无法解释它是否适合自己的商品数量和运营方式。

同时准备这些前台文字：品牌简介、客服工作时间、发货时效、退换货说明、发票说明、会员规则、积分规则、优惠券规则、用户协议和隐私政策。按钮名称、空页面提示、审核失败原因这类短文字，后期看似可以边做边补，实际上直接影响用户能否顺利操作。

现有系统、数据和接口不能只报一个名称

如果商城需要连接 ERP、WMS、OMS、CRM、财务、电子发票、客服或物流系统，应当准备接口文档、测试环境、测试账号、字段说明、调用限制和现有技术负责人的对接方式。仅仅告诉开发“我们用某某 ERP”还不够，同一套软件的版本、已购模块、部署方式和开放接口权限都可能不同。

旧商城要迁移数据时，先确定迁移范围。商品、会员、积分、优惠券、历史订单和售后记录的处理难度完全不同。还要明确哪些数据允许迁移、旧编码怎样对应、重复会员如何合并、历史订单是否只读，以及切换当天怎样避免两个系统同时改库存。

没有现成接口文档也不是不能做，但方案里应当把“等待第三方确认”的部分单列出来。未经验证就把双向库存同步、自动开票或会员权益打通写成确定功能，后面的工期和费用很难稳定。

隐私与合规资料要跟着功能一起定

小程序收集手机号、收货地址、定位、相册内容或其他个人信息，都应当对应一个真实、必要的功能。不能先把能调用的权限都接上，再用一份通用隐私政策兜底。

前期需要列清楚：收集什么信息、在哪个页面收集、为什么需要、保存多久、由谁使用、是否提供给第三方，以及用户怎样查询、更正、删除或撤回授权。接入地图、客服、统计、推送等第三方服务时，还要核对它们实际处理的数据。微信开放文档已经提供用户隐私保护指引的填写说明；《个人信息保护法》对处理目的、方式、范围和个人权利也有明确要求。

交易规则同样要能在前台找到。经营者信息、商品信息、价格和费用、交付方式、售后条件、客服渠道不能只存在于运营人员的口头说明里。涉及食品、化妆品、出版物、医疗器械等具体类目时，应让企业法务或对应业务负责人根据实际商品复核资质与展示内容，开发方不能用一份通用模板代替经营判断。

开工前还要确定验收依据

需求已经说清，不代表项目边界自然就清楚。正式开发前应确认页面原型、功能清单、角色权限、数据字段、接口范围、兼容范围和验收方式。企业内部最好指定一位能协调运营、财务、仓库和管理层的项目负责人，零散意见由这位负责人汇总确认，避免同一个页面收到几套互相冲突的修改意见。

验收资料不必复杂，但要能回答几个问题：用什么账号和数据测试；哪些流程必须完整走通；什么情况算严重问题；上线前谁确认商品、价格、库存、协议和支付；上线后由谁维护商品与处理订单。报表也要明确字段口径，例如“销售额”究竟按已支付、已发货还是已完成订单统计，退款发生后如何回冲。

如果希望资料一次交得更清楚，可以按下面的目录整理：

01_主体资质与授权
02_小程序和支付账号
03_业务说明与功能范围
04_商品SKU与媒体素材
05_价格库存与促销规则
06_订单物流与售后规则
07_品牌视觉与页面文案
08_现有系统与接口文档
09_协议隐私与合规材料
10_测试数据与验收人员

资料没有全部准备齐，也可以先做需求梳理和原型，但要把缺项、负责人和最晚确认时间写进项目记录。经营主体、收款路径、商品规格、价格库存、订单状态、售后规则和外部接口，不能带着模糊答案进入开发。这几项一变，动的通常不只是页面文字，数据库、后台和用户流程都可能跟着改。

资料交完以后，团队应当能直接回答三个问题：商城具体怎么卖，系统具体怎么跑，出现例外时谁按什么规则处理。答不上来的地方，就是开工前还没有解决的需求。

[1]: 微信开放文档：小程序备案操作指引，核验日期：2026 年 7 月 23 日。 [2]: 微信开放文档：小程序开放的服务类目，核验日期：2026 年 7 月 23 日。 [3]: 工业和信息化部：关于开展移动互联网应用程序备案工作的通知，工信部信管〔2023〕105 号。 [4]: 微信支付商户平台：微信支付接入指引，核验日期：2026 年 7 月 23 日。 [5]: 微信开放文档：用户隐私保护指引填写说明，核验日期：2026 年 7 月 23 日。 [6]: 中国人大网：中华人民共和国个人信息保护法。