项目速览
- 行业：区域零售（企业采购 + 个人消费）
- 交付内容：小程序商城、会员与积分、优惠券与拼团、订单与售后、运营后台
- 周期：12 周；团队 6 人
- 技术栈：uni-app、PHP + MySQL、Redis、微信支付、OSS 与 CDN（自有）
背景
客户有两百多家企业客户和一批个人消费者，原来用一款 SaaS 商城：活动做不了、会员规则改不了、数据拿不出来。每年「双 11」想做个企业采购专场，只能手工改价、手工核对。
方案要点
① 一套后端，多端同源
商品、价格、库存、订单、会员规则全部在服务端，前端只做展示与交互。好处是：不会出现「小程序里能用、App 里不能」的规则分裂，运营也只在一个后台维护。
② 会员与价格
两类价格体系：企业客户走「协议价 + 授信额度」，个人走「零售价 + 优惠券 + 积分」。同一商品对不同客户展示不同价格，权限在服务端判定，不靠前端隐藏。
③ 订单状态机与售后
订单状态严格按状态机流转，非法流转在服务端拒绝。售后按「仅退款 / 退货退款 / 换货」三类走不同流程，换货支持「先寄回后发出」与「上门换」两种。
最容易出错的四处
- 支付一致性：微信支付回调可能重复、可能延迟。所有回调按订单号做幂等，且必须回查支付平台状态，不信任回调内容本身。
- 库存扣减：下单锁库、支付扣减、超时释放三段式，超卖靠「库存行加锁 + 失败重试」兜底，而不是靠前端校验。
- 优惠叠加：券、积分、会员折扣、活动价的叠加顺序必须写死并可在后台查看，否则客服无法解释「为什么少减了 5 块」。
- 退款与对账：退款单与账单每日对账，差异单独立池；对账不平的记录不允许直接关闭，必须人工确认原因。
活动支撑
「企业采购专场」这类活动由运营在后台配置：选品、专属价、可见范围（指定客户标签）、起止时间。不需要开发介入，也不需要临时改代码——这是客户换掉旧 SaaS 的核心原因之一。
结果
营销活动从「一周排期」变成「当天配置」；企业客户的协议价与授信在系统内可控；订单与退款对账每天自动跑，财务不再手工核。具体 GMV 数据由客户掌握。
复盘
如果重做，我们会把「优惠叠加说明」做成订单详情里的可展开条目，客服可以用它直接向客户解释。这类「可解释性」功能投入很小，但能显著降低客服压力。
发表回复