写在前面
此系统的背景如下:为某餐厅开发用于接收创建订单、简单运营的系统,此前餐厅的收银端、CRM、ERP 均使用外购系统,需要全部更换为自研系统,由于各系统到期时间、研发上线时间不一致,所以各系统既需要可以独立运营,又需要未来可以互相调用。
由于餐厅所属集团旗下有几种不同业态,门店距离很近,即用户重合的概率比较高,因此 CRM 系统同时记录了不同业态的会员,但是又需要各系统可以自行进行一些精细化运营,所以在此系统中也包含了一部分会员运营的内容。
商家属于同时接受线上预约和直接线下消费的模式,线上有小程序进行预约选座。
这里只列出骨干,因为很多都是业内常见的操作,由于和 ERP、CRM、收银端的独立,也比较简单,就不赘述了。
零、布局和订单
最基础的功能之一,展示当前座位图,包括就座信息、即将到来的预订信息,当前各状态订单的列表等。 首页布局图此布局图是配置中商家自己绘制的,鉴于商家会在特殊节日如情人节更改大厅布局,所以提供了修改布局的功能,后面会讲到。
左侧是当前订单的基础信息,左滑可以修改订单的状态,如从已入座修改为已完成,或发送提醒短信等。
首页布局图 – 预订视图 – 左滑动作
一、创建订单
创建订单提供了保存草稿的功能,鉴于实际使用的前台小姐姐可能会在创建订单时被打断去引领入座,所以提供了保存草稿的功能,但同时由于不太可能出现保存多个草稿的场景,因此只提供了保存一份草稿、在创建订单时提示是否要继续的功能,类似闲鱼。
新建
草稿
同时很多客户会选择打电话预订,因此在接听蓝牙电话时,也提供了直接预订的功能。
来电 – 直接添加
二、订单详情
布局 - 订单 - 更改状态以上为订单详情,订单信息在此可以修改。
三、数据分析
由于餐厅此前没有做数据分析和精细化运营,所以此处只提供了最基础的一些预订数据分析。
当日概况
当日概况 – 状态 & 折线
四、餐厅基础设置
由于餐厅有不同的市别、在不同的市别又有不同的座位区开放,为了可以准确的控制线上预约的可选座位,在餐厅配置时把市别、座位分区拆分开,这样在配置座位时可以控制在什么时段开放哪些分区的座位。
餐厅设置
在这里讲一下线上如何判断有多少座位可用的逻辑。
在所选的时间 +- 轮次时间均未被锁定即此时间此座位可用,轮次时间为后台配置,以 2 小时为例,选择 12:00,那么如果 10:00 - 14:00 该座位都处于非锁定状态,则此座位在 12:00 可用;因此,当选中了 12:00 的预约座位时,这个座位在 10:00 - 14:00 都是被占用状态,分配在此时段将产生冲突;当创建直接进店订单时,从入座时间开始之后 + 轮次时间,此座位也是被占用的,直到手动更改状态。
【轮次】这个字段是参考竞品了解到的,当时我并不懂有什么意义,只是默认两小时时,前台当用户就餐时会以两小时为标准判断顾客用餐进度,我觉得这个没什么意义,因为就算超过两小时也不可能赶走顾客。后来做线上订座时发现,这其实可以当作一个基础参考值,当某座位有人就座以后,应当认为这个座位从入座起,两小时内不可用;如果有人订了 15:00 的某座位,那么这个座位在线上来讲,15:00 -17:00 应该是不可用的。实际到店后如果产生时间座位冲突,就由服务员线下调解,但是两小时的轮次应该是一个基础值,当然这个时间可以由营业人员结合实际运营情况来调整。
另外,由于选座并不是预订时必填的字段,因此虽然小程序提交了预订单,但是并不知道要锁定哪几张座位,或者说精确计算到底占用了几张座位,鉴于商家是不拼座的模式,因此使用以下策略:
当客户在小程序提交订单且没有选择座位时,需要系统通过人数为该订单分配虚拟占座,向上取系统内与订单人数最接近的桌位类型来计算(如果有 3 个人,系统内有 2 人桌,4 人桌,6 人桌,那么虚拟分配一个 4 人桌,如果有 7 个人,虚拟分配 6 人桌和 2 人桌),同时,当某时间虚拟桌位 + 实际占座大于等于了餐厅桌位以后,小程序可用桌位即为 0,不可继续选择此时段;但是只要当实际占座 < 餐厅桌位时,线下仍可继续创建订单,即店内仍有空座时,服务员可以选择优先安排线下就餐的订单,其可能产生的矛盾由服务员来调解。
五、布局绘制
由于餐厅可能会为一些特别的节日,如情人节,更改餐厅布局,为了线上选座的功能,提供了绘制餐厅布局的功能,提供一些基本固定的元素给商家,由商家来自行绘制。
鉴于特殊布局仅为固定日期,因此提供了上线时间字段,非此时间段均会应用绘制的默认布局类别。
餐厅设置 – 座位排列 - 布局列表
餐厅设置 – 座位排列 – 新建特殊画布
餐厅设置 – 座位排列 - 新建特殊画布 – 拖进画布
如图所示,在绘制布局时,即可选择分区、桌位可接待人数等字段。这样配合基础设置中的分区开放时段的设置,就可以控制选座时在某时段开放某分区了。这个布局图同样提供给收银端使用。
六、食客
这里对门店的顾客做一些基础的管理和记录,暂时没有精细的分析,由于该系统尚未接入收银端的数据,也不会在此系统对顾客和消费数据进行分析。
由于商家不希望对普通营业员泄露全部食客名录,因此增加了验证功能。
新建食客 - 已有客户.png 食客搜索 – 校验指纹.png 食客详情 – 订单记录.png
由于到店用餐食客都可以被认为是餐厅会员,但是作为 CRM 会员一定要经过后续主动注册才可以登记录入系统,因此这里的食客信息与全业态的 CRM 数据会有所出入,采取了一些特殊的存储和同步策略,不赘述。
七、短信模版
商家需要在顾客预约成功、提醒顾客就餐时间等时机发送短信给顾客,因此提供了短信模版的功能。模版分为几个固定的类别,每个类别下可以创建多个模版,并应用其中一个。商家可以修改发送的短信内容。这里为商家提供了增加类别的功能,为今后可能有的精细化运营做准备,届时可以选择某些用户群体,或者创建一些节日营销短信等进行发送。
餐厅设置 – 短信模版
由于餐厅需要在短信中输入顾客姓名、就餐时间等信息,为方便餐厅员工使用,采用了将这些固定字段标签化、点击插入内容的方法。
短信模版在应用后,仍需运营商来审核,因此系统也需要反馈给餐厅员工短信是否审核通过。
餐厅设置 – 短信模版 – 模版列表.png
八、配合使用的订座小程序
小程序提供了简单的预订、订单查询、修改、取消和注册系统 CRM 会员的功能,这里展示预订和选座的界面。
分组内选座 区域概览
由于座位很多,一次性展示所有座位很难,所以选择先展示分区,点开分区再查看分区内座位并选座。
分组内选座
九、总结
由于和 CRM、ERP、收银端是独立的系统,所以这个系统承载了比较简单的功能,但是做一些细节的时候还是思考和学到了一些东西,不论是业务或产品,记录一下。
网友评论