微信点餐的需求和技术演变

微信点餐的需求和技术演变

背景

先解释下什么是Hack版本,什么是Saas版本?

Hack版本就是指使用侵入的手段破解点菜机的各种信息,使得点菜机看起来就像是我们自己的一样。

Saas版本就是指做我们自己的点菜机,还要做成服务的

为什么要做Saas版本的微信点餐?

因为目前的hack版本面向未来开发导致现实问题很多,多到让微信点餐产品看不到未来,商户静悄悄的越来越少

微信点餐的业务需求

11个核心功能

  1. 微信线上点单
  2. 微信线上支付
  3. 点菜机线下点单(退菜)
  4. 点菜机线下支付
  5. 点菜机关台
  6. 支持优惠
  7. 支持库存
  8. 支持做法
  9. 支持转台
  10. 支持套餐
  11. 支持快餐
  12. 支持优惠券,储值,积分

1-6是一期内容,神通交接前已完成。7-10是二期内容,属于后续功能扩充。11是待完成功能,12是附加的会员管理方面的功能。

Hack版本

当初为什么立项,现在已不可考。但是微信点餐产品做出来终归是为了占据点餐市场,并且作为会员服务其中的一项增值服务。

Hack版本的问题

目前hack版本的微信点餐到底存在哪些问题?

常见问题

  1. 各种环境问题(软件没配置对,被杀毒软件杀了,点菜宝异常)等等导致的数据上传错误,缺失
  2. 打印机不出票
  3. CRM不能操作菜单
  4. 小程序下单超时、点菜宝链路异常等各种点餐失败原因
  5. 商家点菜机落后最新版本100多个版本
  6. 关台不正常,导致小程序看到没关的单
  7. 购物车没有清空,在不同清空下到底要不要清
  8. 该打折的没有打折,不该打折的打折了,重复打折
  9. 不支持带价格的做法,导致价格各种不对
  10. 小程序点的多规格的菜在点菜机上价格会被改掉为最小价格
  11. …(还有一百万个)

总之,消费者使用体验很差,就像我们去吃饭用小程序点餐一样,会喷人家做的怎么这么烂。商家使用体验很差,只要出一点问题,消费者就喊商家解决,商家有不明白,然后就上报,报多了就默默地撕掉了点餐码。运营人员和技术人员接到问题之后被商家一顿喷,还得老老实实的给排查解决问题,但是对于那种数据源头不属于自己的系统的奇怪性的概率问题,查起来真的很难受。不管对于消费者还是商户还是运营人员还是开发人员来说,完全没有用户体验。So:去你妈的微信点餐,真难用

主要问题

hack版本微信点餐凉凉的主要原因:

  1. 点菜机源头的任何结构改动都会导致整体不可用:例如美食专家的字段改动,导致读不到任何数据
  2. hack的方式使得整个win端的配置太过于复杂,导致没有CS或者技术参与,出了问题商家根本不知道怎么办
  3. hack的方式使得各种点菜机出了问题也都是找我们,而不是找点菜机厂商
  4. 各种不同版本的点菜机对于具体的菜不一定有唯一键,导致对于临时调价这种场景无法匹配到菜,结果老师出现各种价格不对的问题

基于事实基于约定面向未知

口号:我们不生产点菜机,我们只是点菜机的搬运工

那么之前是如何搬运的呢?此处有两个主要步骤:

  1. 打通点菜机:破解点菜机的数据库密码,了解点菜机的数据库结构,并且adapt到我们自己的数据格式
  2. 打通点菜协议:解密博立协议,通过点菜宝和串口/网口将点菜信息写入到点菜机

很容易看到,基于事实基于约定面向未知的产品设计本身就不是一个稳定的产品,只能当成一个实验室产品使用,但是最后却错误的上线到了生产。

目前的现状

  • 已打通83款点菜机(hack点菜机密码、菜品图片、菜品增删改查、做法等等信息)
  • 支持博立协议的所有点菜机点餐

因为面向未知,不确定因素导致维护成本很高。为了快速上线,新需求带来的新代码都嵌入到了老代码中,导致高耦合度,每一块看上去很恶心的代码都能看到和点餐相关的逻辑,所以后续就有拆分visit和stage的过程。

hack的方法

手持点菜宝通讯过程:

  1. 通讯过程

    • 点菜宝和基站通讯是通过无线特定赫兹(433MHZ);
    • 基站和收银机计算机通讯可以通过串口或者网口方式;
  2. 通讯测试

    • 硬测试:点菜宝和基站通讯上需要通过将基站拨码处于调试状态测试,通信是单向的,基站发送,点菜宝接收;

    • 软测试:软测试是指将通信基站连接计算机,用“无线点菜机管理”软件对通信基站与点菜机进行测试,此时的测试是双向的,即正常使用模式。

  3. 通讯协议

    • 点菜宝,基站,收银机计算机数据交换采用的协议通常叫:博立协议,但是博立协议非行业标准协议,会存在不同厂商根据自身情况对协议进行私有定制开发;

    • 协议有三个指令:登陆,开台,点菜;点菜宝在使用前需要先在收银机计算机“无线点菜机管理””模块中勾选点菜宝编号进行诸如“菜品”,“桌台”等基础数据同步到点菜宝内;然后“登陆”,“开台”,“点菜”流程;

除了hack点菜宝的通讯过程,还需要hack点菜机本身数据库的链接方式以及用户名和密码。

基站设备图:

Saas版本

点菜机初始版本只支持在线点餐,不支持离线点餐,网络不好的就不上。也就是说就是为了微信点餐服务的。

系统结构

参见mindnode

待确认问题

兼容性问题

因为模式太多,需要考虑兼容性问题

  1. win端起新的后台管理项目
  2. 后端新项目不支持老版本老模式,如果还有老用户就慢慢过渡到新版本
  3. 不再有堂食菜品库,都是自定义菜单,在win端管理后台管理
  4. B端的菜单设计功能逐渐废弃

优惠和菜品的关系

目前是否参与优惠取决于菜品是否有参与优惠的字段discountable,即是否参与优惠是菜品的一个属性。具体的优惠折扣应该是所有参与优惠的菜的总价的打折,这个是商家临时决定的。

折扣值具体在哪边设置需要确认下

做法和菜品的关系

目前做法是在菜品里面加一个字段,显示这个菜有多少种做法。对于每一个菜都需要设置做法信息。

改为Saas之后,做法需要单独维护一个做法表,做法分类和菜品做关联(需要确认是和菜品关联还是和sku关联),避免各种重复录入

做法分类表和做法表的设计:

做法分类:做法分类Code + 做法分类name,例如 0100 + 甜度

做法:做法code + 做法name + 做法分类code,例如 AAAA + 七分甜 + 0100

其他平台

屏芯:使用ActiveMQ推送。同样会产生因为推送超时导致的重复下单,不知道有什么巧妙的办法可以解决重复下单的问题。但是也说明推送的方式是可行的

Flowsnow wechat
欢迎您扫一扫上面的微信公众号,订阅我的博客!
捐赠:喜欢就请我喝一杯