复盘 | 从V0.1到V1.2，记一次无人售卖机对接的经历

文章从版本迭代的实操层面出发，对无人售卖机对接的项目进行了复盘总结并分享了相关经验。

背景

小汪所在公司里有一台无人售卖机，是公司买回来的，放在茶水间内部使用的，由公司内另一团队在购买的时候做了个简单的程序，将无人售卖机的支付系统对接到了公司的支付中台上。

Image by Crystal Chen from Pixabay

就是上图这种随处可见的售卖机，用户选商品后扫码付款。

就在一个平静的早上，小汪突然接到通知，公司买了数十台同样的售卖机回来，打算放在整栋大楼各个楼层里，用来推广社区电商APP。

调研

这是小汪公司买的售卖机，由于品牌原因就不放实图了，分为售卖机、云控系统两部分。

于是小汪就开始找到原来负责对接的团队（简称团队B），了解这台售卖机的对接流程：

1. 用户在售卖机上选择商品后，售卖机侧告诉我方包括商品名称、价格、设备号等订单信息；
2. 我方创建一个支付订单，并生成一条支付链接，然后返回给售卖机；
3. 售卖机在那个小小屏幕上展示出二维码，让用户扫码支付；
4. 我方系统发现订单被支付后，向售卖机侧发送开闸指令。

其实研究，就是支付和开闸而已。但是原来开发的团队告诉小汪：

• 售卖机系统从向我方请求下单，到掉落截止时间，一共就60秒！我方要创建订单、返回链接、售卖机生成二维码并展示、用户扫码支付、我方通知售卖机开闸……
• 更坑的是，我方如果把握不好这60s，超时发给售卖机，售卖机依然会返回成功，但却不掉落商品！
• 售卖机没有提供其他任何接口

于是小汪简单想了一下方案后，赶紧纠集商务与项目的同事与售卖机的供应商电话沟通，结果总结一个词：

要钱！

方案 V0.1

跟领导商议之后，小汪纠集了团队B与自己的团队，大家头脑风暴一轮后，定义了第一版本方案。

版本：V0.1

目的：宣传推广自家APP

需求：一开始想在售卖机边上贴上我们平台的广告，用户扫码下载APP注册成新用户后，再通过APP扫码购买可获得新人价（1分购），如果直接扫码下单则不享受优惠。

将方案与领导汇报后，期间方向变为，推广商城的微信小程序版本，要求用户必须注册登录才能完成支付，注册登录后可以享受持续的折扣优惠。

原因如下：

（1）下载APP扫码享受新人优惠

但是由于售卖机在写字楼内，用户体量有限，拉新效果差，而且用户可能用了一次就把APP删了，后期转化率低；

（2）下载APP扫码享受持续优惠

可以增加APP的持续活跃度，但门槛依然有点高

（3）使用微信直接扫码进入小程序

门槛低且目前小程序活跃度比APP高，是个不错的选择

（4）领导要求用户必须注册登录后才能购买

不能只是访问了小程序就能享受优惠，必须实现拉新作用。可以利用微信联登、微信小程序授权手机号登录，优化用户登录体验。

（5）后天就要上线

会后小汪赶紧调整好方案同步给技术大大们，但是当晚上技术团队传来消息，由于不同项目组使用的域名不一样，需要售卖机那边换一下来我方下单的域名。于是小汪连夜连线售卖机的商务，这个终于不用加钱了，但是要排期实现，而且对小汪晚上打扰他十分不满！并郑重表示他们不是全时提供售后的！

也就是说，2天内把域名换了是不现实的了。

方案 V1.0

第二天一大早，小汪再次召集了自己的团队和团队B，大家商讨如何处理，技术大大们讨论后说，对方不换域名这个没什么，我们自己内部做一下转发吧，至少能挺一段时间。

然后边与技术团队讨论，小汪一边确认了方案V 1.0

版本：V1.0

目的：用户拉新、活跃

需求：用户通过支付宝、微信扫码后，跳到商城对应的H5、微信小程序页面，登录完进行支付，支付成功后导流到对应版本的商城中。我们设定一个固定的优惠比例，对售卖机传过来的价格打折。

技术要点：当用户需要用支付宝购买时，通过微信提供的 “扫普通链接二维码打开小程序” 功能，用户用支付宝扫描时，进入H5版本商城，用微信扫描时，进入微信小程序对应页面，这样就只需要一个二维码即可解决不同工具扫描的问题。

小汪火急火燎的把方案汇报给领导，没问题了立即跟技术同步投入开发，最后在deadline过后次日凌晨完成了对接。

方案 V1.1

系统上线后第一天，大家都很积极，由于饮品打折后确认划算，而且操作轻松，当天购买的人络绎不绝。次日，公司运营打呼不好！由于我们相对来说太便宜了，居然被一些用户几十瓶几十瓶的买，售卖机都快被掏空了！

加之售卖机那个坑爹的60s限制，头一天有些用户的饮料没掉落，开始跑来要退款了，于是小汪就开始着手V1.1 版本，同时让运营与领导协商重新定折扣比例。

版本：V1.1

目的：限制用户高频购买、增加退款功能

需求：用户一天享受一定次数的优惠，超过后就只能原价购买。如果用户完成支付后，我方系统从支付宝/微信获得的支付时间发现已经距离接收到售卖机的订单超过58秒时，不再向售卖机发放开闸指令，而是自动退款。

关于饮料没掉落用户跑来要退款的问题，在咨询售卖机供应商后，供应商表示可以加钱给我们查询掉落状态的接口……

小汪与运营沟通后，指定了一套退款流程：

1. 如果用户反馈没掉饮料，我们就先让用户出示订单支付成功的凭证，然后查询我方系统是否存在该订单；
2. 如果存在，再查询售卖机云控系统，云控系统要是显示没掉落商品，则退款；
3. 如果显示已掉落，用户坚持的话，则联系物业查看楼栋监控。

新版本两天就开发测试好了，系统上线后，退款率下降了些，同时刷单现象也明显减少，但是依然有的用户就不断买直到触发限购。

方案 V1.2

机器开始正常运作了，每天能为平台带来不少的订单，更重要的是小程序和H5商城的访问量，此时小汪就开始思考如果让这些买饮料的人更好的导流到商城。同时运营也提出，现在这套系统没有后台，每天要向技术要前一天的订单报表，再跟售卖机云控系统中的订单进行人手比对，体验非常糟糕。

于是就有了V1.2版本。

版本：V1.2

目的：更好的向商城导流、帮助运营改善核对订单的压力

需求：

1. 将售卖机支付成功后跳转的页面变为在商城后台广告管理中可以配置，这样用户支付成功后不再是固定进入商城首页，而是可以跳到最新的活动页、专题页，更吸引用户的注意。
2. 引入新用户优惠，如果用户是新注册的，享受新用户折扣。
3. 在商城后台增加订单查看功能，同时支持选择日期后上传售卖机云控系统导出的订单列表，进行自动对账，如果系统发现我方传了开闸指令，但是售卖机云控系统显示并未掉落商品的，则系统自动发起退款。

又过了几天，售卖机的运营终于稳定了下来，至此，无人售卖机的对接暂告一段落。

总结

在这次与无人售卖机对接的过程中，小汪总结了一些经验：

• 硬件要与业务场景相辅相成的，如果有机会能参与到采购流程中，必须先于供应商约定对接、售后等事宜，为未来业务拓展打好基础。
• 在做用户补贴时，一定要提前做好用户白名单、黑名单、限购、预警策略，还可以对接一些第三方的风控平台，如网易易盾、腾讯云天御等产品，对用户手机号、设备、IP进行风险预测，最大的避免黑产风险。
• 面对突发需求时，应多想想该需求未来的发展方向、可能存在的问题，同时尽可能复用已有的功能。这次对接中，登录、订单、支付等功能都是使用社区商城已有功能，减少了重复“造轮子”的时间。
• 新设计的功能，在规划的未来场景中，应该具备复用的可能性，这样一旦遇到需求变更，或者需求终止，就可以更加的从容。

 

本文由 @iCheer 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议