写在前面
此系统的背景如下：为某餐厅开发用于接收创建订单、简单运营的系统，此前餐厅的收银端、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，不可继续选择此时段；但是只要当实际占座 < 餐厅桌位时，线下仍可继续创建订单，即店内仍有空座时，服务员可以选择优先安排线下就餐的订单，其可能产生的矛盾由服务员来调解。
五、布局绘制
由于餐厅可能会为一些特别的节日，如情人节，更改餐厅布局，为了线上选座的功能，提供了绘制餐厅布局的功能，提供一些基本固定的元素给商家，由商家来自行绘制。
鉴于特殊布局仅为固定日期，因此提供了上线时间字段，非此时间段均会应用绘制的默认布局类别。
如图所示，在绘制布局时，即可选择分区、桌位可接待人数等字段。这样配合基础设置中的分区开放时段的设置，就可以控制选座时在某时段开放某分区了。这个布局图同样提供给收银端使用。
六、食客
这里对门店的顾客做一些基础的管理和记录，暂时没有精细的分析，由于该系统尚未接入收银端的数据，也不会在此系统对顾客和消费数据进行分析。
由于商家不希望对普通营业员泄露全部食客名录，因此增加了验证功能。
由于到店用餐食客都可以被认为是餐厅会员，但是作为 CRM 会员一定要经过后续主动注册才可以登记录入系统，因此这里的食客信息与全业态的 CRM 数据会有所出入，采取了一些特殊的存储和同步策略，不赘述。
七、短信模版
商家需要在顾客预约成功、提醒顾客就餐时间等时机发送短信给顾客，因此提供了短信模版的功能。模版分为几个固定的类别，每个类别下可以创建多个模版，并应用其中一个。商家可以修改发送的短信内容。这里为商家提供了增加类别的功能，为今后可能有的精细化运营做准备，届时可以选择某些用户群体，或者创建一些节日营销短信等进行发送。
由于餐厅需要在短信中输入顾客姓名、就餐时间等信息，为方便餐厅员工使用，采用了将这些固定字段标签化、点击插入内容的方法。
短信模版在应用后，仍需运营商来审核，因此系统也需要反馈给餐厅员工短信是否审核通过。
八、配合使用的订座小程序
小程序提供了简单的预订、订单查询、修改、取消和注册系统 CRM 会员的功能，这里展示预订和选座的界面。
由于座位很多，一次性展示所有座位很难，所以选择先展示分区，点开分区再查看分区内座位并选座。
九、总结
由于和 CRM、ERP、收银端是独立的系统，所以这个系统承载了比较简单的功能，但是做一些细节的时候还是思考和学到了一些东西，不论是业务或产品，记录一下。
