Cibuscibus.
运作方式

从下单到班次复核,同属一个运营层。

跟随一笔 Cibus 订单,从桌台扫码、服务员收银系统(POS)或 Storefront(线上点餐商店)开始,经过厨房备餐、支付、收据、报表,直到顾客再互动的完整流程。

事件流 · 实时
示意
  1. QR
    扫码点餐与支付
    T12 · 4 位客人
    开台中
  2. POS
    POS
    服务员 SM · 6 项
    已送出
  3. KDS
    厨房显示系统(KDS)
    烧烤站 · 冷盘站
    烹制中
  4. PAY
    支付
    2 张银行卡 · 分单
    已授权
  5. REC
    收据
    电子 · 已关联订单
    已开立
  6. RCH
    Reach
    待审核
    已起草
  7. INS
    AI 洞察功能
    今晚简报
    已更新
一笔订单 · 七个功能模块 · 一份记录
1个运营层

点餐、厨房、支付、员工与增长业务,同属一个平台。

1个事件流

支持范围内的订单操作,会汇入互联的运营事件。

1个菜单数据源

互联渠道使用已设置的菜单与价格记录。

1份顾客档案

支持范围内的到访、订单与同意情境信息,可与顾客档案建立关联。

痛点

拼凑系统让餐厅付出的代价

拼凑系统
POS、线上点餐、顾客互动与配送工具,可能各自持有独立的菜单、订单与顾客记录。
人工交接
由于系统之间无法互通,员工需要在不同工具间重复输入信息。
报表对不上
不同工具可能采用不同的定义与截止时间,导致团队需要自行核对该班次的数据。
顾客信息中断
来自扫码点餐、外卖市场平台、电话与现场到访的顾客,在团队眼中都呈现不同的样貌。
旧方式对比 Cibus

从四个供应商,到一个运营层

拼凑系统
  • POS、扫码点餐、厨房显示系统(KDS)、支付、营销与配送,分别来自不同供应商
  • 员工需要在不同工具间重复输入数据
  • 收据与订单分散在不同系统中
  • 顾客后续跟进与实际订单脱节
使用 Cibus
  • 一个运营层,承载支持范围内的订单,从下单到班次复核全程贯通
  • 支持范围内的事件,连接已设置的 POS、KDS、支付、Storefront、Reach(顾客营销工具)、Rider(外送调度工具)与 AI 洞察功能工作流程
  • 收据、退款与小费,与订单明细项目相关联
  • 支持范围内的顾客与同意情境信息,可供 Reach 工作流程使用
完整流程

从扫码到洞察,会发生什么

  1. 01进单
    订单可通过扫码点餐、POS、Storefront 或员工手机应用进入系统
    互联的点餐功能模块,使用已设置的菜单与加料选项记录。
  2. 02建单
    互联的点餐功能模块,共用同一套订单与计算规则
    价格、税费与折扣规则,会通过已设置的工作流程进行验证,从而降低各渠道之间的差异。
  3. 03分流
    厨房出单按工作站分流
    各工作站的优先顺序、特殊要求与备餐计时。
  4. 04支付
    支付方式涵盖银行卡、终端、电子钱包、现金、代金券或分单
    直接与订单明细项目相关联。
  5. 05收据
    系统自动开立电子与纸本收据
    订单与支付记录,支持收据、退款与日终对账等工作流程。
  6. 06互动
    顾客情境信息,支持 Reach、Stories(社交内容工具)与 AI 洞察功能相关工作流程
    访问权限与同意范围规定依然适用;相关建议与草稿仍须经营者审核后方可使用。
  7. 07配送
    配送订单会分派至 Rider
    实时追踪与送达证明,会回传至相应订单。
  8. 08报表
    店主可查看销售活动、班次状态与相关建议
    互联记录,为已设置的各门店与班次,提供一致的起点。
系统底层

底层如何互联

菜单与加料选项
一套菜单驱动 POS、扫码点餐、Storefront 与报表,并可依门店进行个别调整。
订单记录
互联的订单记录,由参与该工作流程的相关功能模块更新。
厨房分流
出单按工作站分流,并附带优先顺序、备餐计时与传菜统筹视图。
支付与收据
银行卡、终端、电子钱包、现金、代金券与分单——与订单相关联。
顾客档案
支持范围内的订单历史、同意记录与偏好设置,可为 Reach 与 AI 洞察功能提供参考依据。
事件流
支持范围内的运营事件,为报表与已设置的活动记录,提供共享的状态信息。
班次示例

一笔订单,从头到尾

  1. 19:42
    顾客在桌台扫描 QR 菜单
    与服务员手上 POS 显示的,是同一份实时菜单。
  2. 19:48
    服务员通过员工手机应用加入配酒推荐
    互联的 QR 视图,会同步收到更新后的订单状态。
  3. 20:05
    厨房出单分流至烧烤站与冷盘站
    传菜统筹可查看完整出单,各工作站则只看到自己的工作项目。
  4. 21:15
    账单通过 Stripe Terminal,分单至两张银行卡
    支付分摊金额仍与订单保持关联;支持范围内的退款工作流程,会保留相应的支付与订单情境信息。
  5. 21:22
    电子收据根据支付记录开立
    在适用的情况下,另行记录的营销偏好设置,可支持后续的 Reach 工作流程。
  6. 次日
    AI 洞察功能简报提出一个菜单相关问题
    店主会查看相应的支持记录,并自行判断是否需要采取行动。
一个运营层

不是四个供应商拼凑而成,而是贯穿整个班次的一个运营层。

支持范围内的从扫码到洞察分析的各项事件,连接已设置的菜单、订单、支付与顾客情境工作流程,减少人工对账的工作量。

常见问题

Cibus 实际如何运作

所有功能模块是否共用同一份菜单?

已设置的 POS、扫码点餐、Storefront 与报表工作流程,使用互联的菜单记录。餐厅、渠道与门店之间的差异,取决于已核准的设置方式。

走一遍实时的 Cibus 订单流程。

See how Cibus connects service, kitchen operations, payments, reporting, customer engagement and delivery into one restaurant operating system.