本白皮书从看店通视角描述「小程序商城从 0 到 1 再规模化」的建设方法，适用于品牌自营、连锁门店、社区团购与知识付费等场景。全文强调里程碑、风险与验收标准，而非空泛概念。
方法说明（请先读）
- 数据来源：看店通小程序商城交付项目的立项文档、实施排期与上线复盘，以及微信开放平台与微信支付的公开规则文档。本文不引用第三方咨询机构的市场数据，也不是任何机构认证的白皮书。
- 样本范围：以品牌自营商城、连锁门店会员商城、社区团购与知识付费四类项目为归纳对象，单项目团队规模多在 3 至 20 人之间，不覆盖跨境、超大型平台型电商。
- 统计周期：方法归纳自 2026 年及之前的交付经验，平台规则部分以 2026 年 9 月可查到的官方文档为基准。
- 局限性：文中的阶段划分与周期是典型值而非保证值，实际工期受资质审批、内容准备与内部决策速度影响较大；所有实施细节以合同与交付文档约定为准。
第一章：立项与目标对齐
立项应回答：主卖什么、在哪卖、钱从哪来、成功指标是什么。避免「先做小程序再说」导致范围失控。建议书面确认 MVP 范围：例如「微信单店 + 微信支付 + 基础会员 + 企微客服入口」，二期再加分销、多门店或抖音同步。
- 利益相关方：业务 owner、IT、财务、法务、门店代表（如适用）。
- 约束：预算、上线日期、是否必须私有化、是否已有 ERP。
- 风险：类目资质、支付进件周期、内容供应能力。
第二章：选型 SaaS 还是定制
SaaS 上线快、标准功能成熟，但深度定制与数据迁移可能受限。定制灵活、可贴合 ERP，但周期与维护成本更高。评估维度：SKU 复杂度、促销规则、积分体系、开放 API、SLA、退出与数据导出能力。可参考SaaS 与定制对比辅助决策。
实操上建议把选型问题写成可回答的清单，让候选方逐条书面回复，避免只听演示：会员与订单数据能否全量导出、导出格式是什么；促销规则是否支持你现有的叠加逻辑（例如会员折扣与券能否同用）；多门店场景下库存真相源在哪一端；接口是否有版本与兼容策略；故障响应时限与赔付条款；合同终止后数据保留与交付方式。这几项谈不清，后期更换系统的成本往往高于当初省下的开发费。
第三章：实施阶段划分
| 阶段 | 交付物 | 验收要点 |
|---|---|---|
| 需求与设计 | 原型、接口清单、测试用例 | 核心路径覆盖、异常流程定义 |
| 开发与联调 | 体验版、支付沙箱、ERP 联调 | 订单闭环、退款、库存扣减 |
| 合规与提审 | 协议、资质、隐私指引 | 对照审核清单 |
| 试运营 | 小流量真实订单 | 客服、物流、对账跑通 |
| 规模化 | 监控、扩容、运营 SOP | 指标达标与复盘机制 |
第四章：商品与运营准备
技术就绪但商品图粗糙、详情违规，仍会审核失败或转化极差。应并行准备：主图规范、详情模板、运费模板、售后政策、客服话术。连锁需统一价格体系与门店库存策略。内容团队与商城团队共用发布日历，避免直播卖的款未上架。
第五章：数据与集成架构
典型集成包括：ERP/WMS 库存、OMS 订单、CRM/SCRM 会员、BI 报表。建议事件驱动：Webhook 推送订单状态，定时任务做对账补偿。鉴权遵循API 鉴权规范，密钥分环境管理。
第六章：上线后迭代
上线不是终点。前 90 天关注稳定性与 NPS，而非盲目加功能。每两周评审需求 backlog：优先修复阻塞交易的 bug，再考虑营销玩法。定期做合规与性能体检。
第七章：常见失败模式
- 把小程序当静态宣传册，无交易闭环。
- 分销规则触碰合规红线，导致封号。
- 库存不同步，超卖引发大规模客诉。
- 忽视数据归属，换系统时无法迁移历史会员。
- 把「上线日期」当唯一目标，砍掉测试与试运营，结果用真实客户当测试用例。
- 只买系统不配人，商城上线后无人负责内容、客服与活动，三个月后数据回落。
第八章：最小可行范围参考
多数项目失控都始于一期范围太大。下面是我们常用的一期与二期划分，供对照裁剪：一期只做交易闭环与基础会员——商品与规格、购物车与下单、微信支付、运费与地址、订单与退款、基础会员等级与积分、优惠券、企微客服入口、基础数据报表。二期再叠加经营玩法——分销与推广员、多门店与库存分仓、储值、拼团与秒杀、直播挂链、ERP 与 WMS 对接、自定义报表。
判断某个功能该放一期还是二期，用一个标准：没有它，用户能不能完成一次完整购买并得到正常售后？不能，就是一期；能，就放二期。按这个标准，分销、储值、拼团几乎都可以后置，而地址与运费模板、退款流程不能后置。一期范围越小，试运营阶段越能把真实问题暴露出来，二期的排期也越可信。
