适合谁
- 顾客或会员主要通过微信完成商品浏览、下单、预约或课程学习的企业
- 需要轻量化线上服务入口，希望控制首期开发成本、暂不开发独立 App 的团队
- 已有门店、课程或商品，希望通过小程序整合交易、会员及日常业务流程的企业
常见场景
- 商城交易：商品浏览、购物车、订单提交、微信支付及订单管理
- 到店服务：服务预约、订单核销、到店提醒及预约记录
- 会员与课程：会员资料、积分管理、课程展示及在线学习
- 业务系统对接：根据项目需求，对接现有库存、订单或客户管理系统
立项时要避免
- 混淆微信公众号、微信小程序、微信支付和企业微信的功能及权限，导致开发或上线阶段出现配置问题
- 商城仅实现商品展示，缺少订单状态、退款处理、发货管理等必要功能，无法满足日常运营需求
- 未提前确认小程序服务类目、微信支付商户配置及订阅消息使用条件，导致审核受阻或功能返工
功能与交付范围
预约与核销
支持服务项目展示、预约时间选择、预约人数管理、预约记录及到店核销。涉及员工排班、服务时长、预约限制等规则时，需在开发前明确业务逻辑和处理方式。
会员管理
支持微信用户登录、会员资料及按项目需求配置的会员等级或积分功能。积分获取、扣减、过期及人工调整规则需提前明确，确保会员记录清晰可查。
微信支付
根据项目需求接入微信支付，使用客户自有的微信支付商户号。支付结果、退款流程及交易记录以微信支付接口和商户平台能力为基础，一方盟不代持客户交易资金。
微信生态对接
根据项目范围接入小程序分享、客服及订阅消息等能力，并支持公众号菜单跳转小程序等场景。相关功能需满足微信平台规则及权限要求，公众号内容管理不默认包含在小程序开发范围内。
审核与发布
协助准备小程序服务类目、隐私保护说明、测试配置及发布所需材料，并配合处理审核反馈。审核结果和周期以微信平台实际审核为准，涉及客户主体资质或经营许可的材料由客户提供。
技术方案
- 小程序端使用微信原生，或在需要多端复用时评估 Taro、uni-app
- 管理后台为网页，供店员或运营处理商品、订单和会员
- 服务端按项目选择，优先对接客户已经在用的系统
可能的第三方
- 微信支付
- 微信登录
- 订阅消息
- 物流查询
- 客户现有订单或会员接口
开发过程
- 01确认场景先决定首期是商城、预约、会员，还是其中的组合。
- 02核对资质确认小程序主体、类目和微信支付商户是否已经具备。
- 03画主流程下单、预约或学习的主路径先确认，再扩展次要页面。
- 04联调支付用客户商户号完成支付和退款测试。
- 05提审发布按微信要求提交审核，并记录被拒原因。
- 06交给运营交付后台账号和日常操作需要会的几件事。
交付物
- 可运行的程序和对应源代码
- 部署说明、环境依赖和第三方账号清单
- 管理员账号、角色说明和基础操作说明
- 与合同一致的验收清单，以及已知问题列表
验收
- 验收环境与合同约定一致，不在未说明的设备或账号上临时扩大范围
- 每条功能能按清单演示通过，缺陷按严重程度记录并约定修复时间
- 客户方拥有源代码和自己名下的开发者、商户、服务器账号
维护
- 约定期内修复已交付功能的缺陷
- 系统版本、微信基础库或证书到期导致的调整，按维护约定处理
- 新功能、新端口和新的第三方平台不自动包含在维护里
费用和周期受什么影响
这里不提供固定价目。下面每一项都会改变报价和工期，书面清单确认后才是正式范围。
- 只有展示，还是包含交易、预约或会员账务
- 是否自带管理后台，以及后台要给几种角色使用
- 微信支付、退款、物流和订阅消息是否在首期
- 要不要对接已有 ERP、表格或会员系统
- 审核材料是否齐全，主体和类目是否已经确定
常见问题
小程序和 App 怎么选？+
用户主要在微信内完成、首期希望尽快上线时，优先小程序。需要应用商店分发、较强的系统能力或复杂离线能力时，再评估 App。两者可以先后做，不需要第一天同时开工。
没有微信支付商户号能开始吗？+
界面和大部分功能可以先做。支付、退款和正式提审依赖主体、类目和商户号，这些不齐时，不能把上线日期写成确定承诺。
模板改logo算定制吗？+
不算。一方盟的小程序按约定功能开发。若客户明确要求在已有模板上改，合同会写明模板限制和不能改动的部分。
上线后改一个按钮也要重新审核吗？+
涉及小程序代码的发布通常需要再提审。只在后台修改商品、文案或订单，一般不用发版。具体以微信当时的规则为准。
