邻家便利是一家在上海拥有 48 家门店的社区连锁便利店，主打「下班路上顺手买」的即时零售。过去三年，周边大型超市与即时配送平台持续分流，门店客流下滑。管理层希望借微信小程序把到店顾客沉淀为线上会员，做线上下单、门店自提与周边三公里即时配送。
他们最初的方案是直接用某第三方 SaaS 模板，但试用一周就放弃了：模板无法对接门店现有收银库存系统，店员每天要在两个后台之间手动对账，反而增加了工作量。
我们为客户搭建了一套「一主三端」的小程序体系：用户端小程序负责浏览、下单与会员；门店端小程序让店员接单、核销与更新库存；运营后台让总部管理商品、价格、优惠券与门店；同时与门店现有收银系统做了实时库存同步，避免超卖。
我们没有先画界面，而是先跟着店员跑了三天门店。
早高峰鲜食、下午茶饮品、晚间日用，三个时段的客群与商品完全不同，首页需要按时段动态排序。
用户选店 → 浏览 → 加购 → 选择自提或配送 → 微信支付，全程不超过五次点击。
订单推送到门店小程序，店员接单后拣货，自提用户扫码核销，配送订单呼叫第三方骑手。
下单后自动发放满减券，7 天未回购自动推送「你的常买商品有货了」。
库存同步是整个项目最难的部分：我们对接了门店原有 POS 的实时库存接口，线上线下扣减同一笔库存，避免出现「用户下单但店里已经卖光」的尴尬。针对鲜食短保商品，系统在每天 19:00 后自动对当日便当、饭团打七折，帮门店减少损耗。
自提核销使用门店端扫码枪 + 小程序双模式，高峰期店员不需要逐笔查订单号，扫用户手机上的取货码即可完成。
连锁项目最难的从来不是写代码，而是让一线店员真的用起来。
我们没有 48 家门店一起上线，而是选了三家客流结构不同的门店做两周灰度：写字楼店、社区店、交通枢纽店分别暴露了不同问题。写字楼店早高峰订单集中，门店端需要按时间窗聚合拣货；社区店老年人占比高，下单流程必须能由店员代客完成；交通枢纽店配送距离波动大，需要更灵活的骑手调度。这些问题在灰度期全部被消化，全量上线时几乎没有返工。
我们为每家门店制作了一页纸的「店员操作卡」：接单、拣货、核销、异常处理四步图解，贴在收银台旁边。同时录制了三分钟短视频，店长可以在早会播放。上线第一个月，我们驻场支持了一周，现场帮店员解决每一个手忙脚乱的瞬间。
上线后，运营后台第一次按门店维度看到数据：哪家店线上占比最高、哪类商品被反复加购、哪个时段订单最密集。总部据此调整了配送范围与鲜食补货节奏，而不再凭经验拍脑袋。
我们还协助客户设计了一套「首单立减 + 七日复购券」的冷启动机制：用户线上下单后，门店店员会在递货时口头邀请加入企业微信社群，把一次交易变成长期关系。三个月后回看，社群贡献的复购订单占到了线上总量的近三成——这部分顾客以前完全属于即时配送平台，如今终于回到了品牌自己手里。
小程序上线三个月，邻家便利重新掌握了自己的顾客
我们最担心的是「门店不愿意用」——便利店店员每天已经忙到飞起。泰格团队做了一件让我们意外的事：他们不是先做用户端，而是先把门店端小程序做到店员愿意用。上线后第一个月，没有一家门店抱怨对账麻烦。三个月后，我们第一次能说清楚：到底是哪个小区的用户、在几点、买了什么。这种数据以前是想都不敢想的。
连锁小程序的胜负手，从来不在用户界面有多好看，而在一线门店愿不愿意用、用了以后能不能真的省时间。我们把门店端和店员培训放在与用户端同等重要的位置，正是因为——没有店员愿意接单的小程序，再好看也是零单。
半年后，邻家便利把小程序复制到了苏州的十家新店，开业首周线上订单即占门店总量四成。这套可复制的「用户端—门店端—运营后台」体系，已经成为我们服务连锁零售客户的标准底座。
这套从门店出发的方法论，后来也被用于餐饮、药店等不同连锁业态，核心始终不变：先让一线用得顺，再谈用户体验，这也是我们对每一个连锁客户的承诺：先接地气，再谈规模，这是我们做线下项目时始终坚持的顺序。
为线下连锁品牌打通线上线下