老客户陈总上个月约我吃饭，说他前年找外地团队做的小程序开发，生鲜商城投了七万多，现在日活不到三十人，问我能不能救。看完系统我说代码还有救，但真正的问题不在代码。征得他同意，把这个项目当作反面教材复盘出来。
立项时的定位就偏了
陈总做水果批发，看了同行搞社区团购眼热，也想做个商城让居民下单。复盘时我们算了一笔账：他的批发利润率不到十个点，零售配送一单的履约成本三块多，一天三十单的量，卖得越多亏得越稳。这个模式对个人创业者成立，对他这种有批发主业的老板，零售只是锦上添花，不值得all in。立项时要是先算履约账，这七万里有一半不用花。做小程序开发之前先算履约成本，这个教训值七万，写出来希望别人少交。
两套价格体系互相打架
商城上线后，老客户发现小程序里的零售价比找他批发的价高出一截，感觉被当成了冤大头；批发的老客户又嫌小程序下单麻烦，还是发微信订货。一个系统想同时服务两类客户，价格体系没分开，结果两边都不满意。这是B端生意转零售最典型的坑：你的零售体系要么独立运营，要么先别做，硬捏在一起，老客没留住，新客也没起量。
上线后没人管，系统就成了空城
- 没有指定专人负责上架、回复和售后，商品图用了两年前的旧图
- 没做过一次活动推送，用户下载理由消失后就再没打开过
- 配送时效不稳定，投诉没人处理，差评在本地群里传开
工具本身没有获客能力，它只是把你已有的运营动作线上化。运营动作为零，系统数据自然为零，这两件事从来没有例外。所以小程序开发交付那天，运营的分工就该定下来，谁管上架、谁管回复、谁管售后，落实到人名。
我们给的三条整改意见
商城降级成给批发老客户的自助下单工具，砍掉零售模块，价格体系跟批发对齐；指定他店里一名文员每周花两小时维护商品和处理订单；加一个批量订货和常用清单功能，让老客户下单从发微信变成点小程序，省的是他自己的接单时间。系统回到它该待的位置上，事情就顺了。改完一个多月，周订单稳定在两百单以上，都是原来发微信那批人。这个项目没救活零售，但把工具用在了对的场景。要是你也琢磨过上线商城，先把履约成本和运营人手这两个问题想清楚，想不透的，找比格网络聊聊业务再决定，别急着掏钱。
