社区团购小程序开工前,先发一张营业执照远远不够。
前台看起来只是选商品、下单、到社区自提,后台却同时连着商品库存、截单时间、团长佣金、分拣配送、退款和对账。任何一处口径含糊,开发时都会变成反复改页面、改字段、改订单状态。红数科技接这类需求时,通常先确认经营关系,再收资料。顺序反过来,很容易收了一大堆文件,真正做方案时还是缺关键答案。

先确认是哪一种社区团购
社区团购不是单一模式。项目方自己采购、定价、收款和售后,通常按自营业务梳理;如果小程序允许多个供应商或商家入驻,各自管理商品,交易后还要分别结算,方案就更接近平台型业务。还有一些项目,供应商只供货,消费者仍然向项目方购买,这和“商家直接入驻经营”也不是一回事。
这几种模式的首页可以做得很像,所需类目、支付安排、合同关系和后台权限却不一样。立项时至少要把下面几件事定下来:
- 商品由谁采购,销售方在订单和票据上是谁;
- 消费者的钱进入哪个主体的商户号,退款由谁发起;
- 团长是推广、代收货、核销,还是还承担配送和售后;
- 供应商只供货,还是能够登录后台自行上架、改价和接单;
- 商品送到中心仓、团长自提点,还是直接送到消费者地址。
暂时定不下来的地方不要用“后面再说”带过。可以把备选方案都保留,但要明确首期按哪套流程开发,否则同一个“团购下单”会拆出完全不同的订单、库存和结算逻辑。
主体资料不只是一张营业执照
确定经营模式后,再整理主体资料会快很多。常见的基础材料包括营业执照彩色扫描件或清晰照片、法定代表人身份证件、企业对公账户信息、实际办公或经营地址、常用邮箱和能够接听审核电话的手机号码。需要他人担任小程序管理员、备案负责人或支付经办人时,还要提前准备其身份信息,并确认是否需要授权书。
这里最容易出问题的不是“少传一张图片”,而是不同环节用了不同主体,却没人能说明它们之间的关系。小程序主体、备案主办单位、微信支付商户、商品销售方和开票主体是否一致;不一致时,授权、合作或委托关系用什么材料证明,都应该在方案阶段核一遍。
微信现行的小程序备案指引列出的准备项包括主办单位证件、主体负责人证件、小程序负责人证件、可能涉及的前置审批或专项审批材料,以及属地通信管理部门要求的补充材料。负责人和法定代表人不是同一人时,各地要求可能不同。平台初审通过后,相关负责人还要留意工信部短信,并按通知时限完成核验。证件临近到期、照片边角不全、号码无人接听,都会让原本很简单的环节停下来。

小程序账号、认证、备案和支付要一起看
已经注册过小程序的项目,需要提供小程序名称、APPID、当前管理员和成员权限情况,并确认账号归属。尚未注册的,则要先确定用哪个主体注册、由谁长期保管管理员权限。服务商可以协助配置,但主体账号、邮箱、管理员和商户平台的核心权限不宜长期放在个人员工或外部人员手里。
涉及在线付款时,通常还要准备微信支付申请所需的营业执照、法定代表人身份证件和结算银行账户等资料。具体提交项会随主体类型、经营类目和商户平台页面变化。方案阶段还应补齐几项业务信息:商户简称显示什么、客服电话由谁接、退款账户怎样安排、是否需要发票、财务按订单还是按结算周期对账。
如果项目要给供应商、门店或团长分账,不能只在需求表里写一句“支持分账”。先把收款主体、分配对象、计算基数、结算周期、退款后的扣回方式和异常款处理写成几笔能够算清的示例,再判断采用哪种支付和结算能力。没有这组例子,开发完成后最容易出现的不是按钮不能点,而是财务对不上账。
商品资料要整理到可售规格,不能停在品名
社区团购的商品变动快,商品表如果只有“苹果、鸡蛋、大米”,后台几乎没法直接导入。至少要整理到每个可售规格,也就是实际库存和价格对应的那一项。一个能用于初始化的商品表,通常会包含:
- 商品分类、商品名称、规格名称、单位和包装数量;
- 商品主图、详情图、产地、品牌或供应商;
- 成本价、销售价、划线价是否展示,以及团购价的适用时间;
- 商品编码、条码、库存、限购数量、起售数量;
- 净含量、保质期、储存条件、发货或自提说明;
- 缺货时允许换货、部分退款,还是整单退款;
- 食品标签、检验检疫或供应商随货材料中,业务实际需要留存的部分。
食品类目要单独核资质。微信开放文档目前对“商家自营—食品饮料”列出的材料包括食品经营许可证、食品生产许可证、仅销售预包装食品时的备案凭证等可选项;“生鲜/初级食用农产品”则要求企业营业执照经营范围包含相应内容。酒类、保健食品、母婴食品等还有各自类目和材料要求。实际经营品类和证照范围对不上,页面做完也可能无法按计划提交审核。
商品图片也应在此时确定责任人。供应商图能不能使用,主图比例是否统一,生鲜商品按份、按盒还是按称重后的实际数量销售,这些不是美工拿到图片后才处理的小事,会直接影响规格、价格、库存和售后规则。

团长和自提点资料,要能支持真实履约
团长资料通常包括姓名、手机号、所属区域、服务社区、自提点名称和地址、营业或提货时间、定位信息、结算账户,以及必要的协议和身份核验材料。收集到什么程度,应当以实际业务和合规需要为限,不要因为后台能加字段就把个人信息全收一遍。
自提点还要说明容量和接货条件。冷藏冷冻商品能不能存、司机几点能送到、团长如何确认收货、消费者凭什么核销、过时未取怎么处理,这些信息最终都会落在系统状态和操作权限上。一个团长同时管理多个点,或者一个自提点由多人轮班,也要提前告诉开发方,不能默认“一人一点”。
佣金资料最好直接给计算例子。按商品金额还是实付金额计算,运费和优惠券是否计入,退款后佣金怎么冲回,按周还是按月结算,最低结算金额是多少。税务、发票和与团长的法律关系,应由项目方结合所在地要求让财税和法律人员确认,小程序只负责按确定后的规则记录和计算。
截单、分拣、配送和核销要用一笔订单走一遍
一张配送范围图和一句“次日达”,还不足以设计履约。项目方需要提供可配送区域、仓库或供应商发货点、社区线路、截单时间、预计到货时段、最低成团或起送条件,以及节假日怎么调整。
可以拿一笔真实商品做推演:消费者今晚下单,系统什么时候锁库存;次日谁按社区汇总采购量;仓库如何打印分拣单;少货时谁在后台改数量;司机送到自提点后由谁确认;消费者取货是输码、扫码还是团长代核销;有一个商品坏了,是退单品还是整单。走完这一遍,订单状态、通知节点和后台权限基本就清楚了。
如果首期同时做自提和送货上门,还要分别给出运费、配送范围、联系人信息和异常处理,不能共用一句模糊规则。定位、收货地址、手机号等信息只在相应场景需要时收集,页面上的用户隐私保护指引也要与实际调用的接口和用途一致。

售后、客服和结算规则要写到能执行
社区团购常见的售后并不复杂,但对时效很敏感。生鲜破损、少件、错发、未及时取货、团长误核销,各自需要什么凭证,由谁审核,退款退到哪里,多长时间内可以申请,都要有清楚的口径。暂时没有专职客服,也要确定由哪个岗位接收消息,避免小程序里留了售后入口却无人处理。
财务侧至少要看四组数:消费者实付和退款、商品销售与成本、供应商应结款、团长应得佣金。优惠券、平台补贴、团长佣金和退款分别记到哪里,先用表格算通,再做后台报表。报表页面再漂亮,也替代不了一笔订单从支付到结算的数字关系。
品牌和页面资料,等业务口径稳定后再集中整理
页面资料包括品牌名称、Logo、标准色、首页栏目、轮播图、公告、客服电话、服务说明、商品详情模板,以及用户协议、隐私政策、配送规则和售后规则。没有成熟视觉资料时,可以先提供希望靠近的风格和明确不接受的风格,不必临时找一堆彼此不一致的参考图。
首页先放什么,应该看实际经营重点。高频生鲜、限时团购、社区自提点切换和订单入口,往往比大段品牌介绍更早影响下单。页面文案也要与真实能力一致。尚未覆盖的配送范围、不能保证的到货时间、没有依据的品质承诺,不应为了页面好看先写上去。
用户信息部分建议单独列一张表:收集哪项信息、在哪个页面收集、用来做什么、是否必须、会交给哪类服务方、保留多久、用户如何更正或删除。微信要求涉及处理个人信息的小程序填写用户隐私保护指引,提审版本的接口调用情况与指引内容不一致时,可能需要先更新后再提交。
现有系统和历史数据,越早说越省事
已经在用进销存、ERP、仓库系统、电子面单、打印机或供应商订货系统的项目,要提供系统名称、数据样表、可用接口文档和对接联系人。不要只说“需要同步库存”,还要说明哪个系统是最终库存、多久同步一次、网络中断时以哪边为准、取消订单后库存怎样回补。
历史商品、会员、团长和订单需要迁移时,先导出一小份脱敏样表。开发方看过真实字段后,才能判断哪些可以直接导入,哪些需要清洗,哪些因为缺少唯一编号只能重新匹配。正式数据不要通过普通聊天工具四处转发,测试阶段也不需要拿完整身份证号、银行卡号或真实用户地址来跑流程。
最后准备一份能验收的项目底稿
资料整理到这里,项目方还需要确定需求确认人、日常对接人、财务和仓储参与人,以及谁有权确认上线。功能清单最好区分首期必做、可以后补和明确不做,避免每次讨论都把新想法当成原需求。
验收不要只看页面是否与设计稿一致。用几组完整场景检查更有效:正常下单并核销、截单前取消、缺货后部分退款、优惠券订单退款、团长佣金冲回、供应商对账、库存不足和重复核销。每个场景写清输入、应出现的状态和最终金额,开发方与项目方看到的是同一个结果。

真正可以直接交给开发公司的资料,归拢起来大致是这些:主体与负责人证件、小程序和商户平台账号、经营类目资质、商品与供应商表、团长和自提点表、配送范围与截单规则、佣金和结算示例、售后口径、品牌页面素材、用户信息清单、现有系统接口及历史数据样表,再加一份有负责人和优先级的功能清单。
不要求第一天就把所有图片和表格做到最终版,但经营关系、收款关系和履约责任不能留空。它们一旦确定,原型、后台、数据表和测试用例都会顺下来;这三件事没有定,后面每一轮“再改一下”都会改到系统底层。
微信平台的备案、类目和隐私要求会随政策及平台规则调整,实际提交时应以后台当日提示为准。可直接核对小程序备案操作指引、小程序开放的服务类目、用户隐私保护指引填写说明和小程序微信支付接入指引。