按产品逐一拼凑而成的系统
一个互联的餐厅平台
重点考验系统间的衔接，而非单看功能清单。
分开组装的技术组合，仍可能是合适的选择。真正的运营问题在于：当一笔订单跨越不同产品边界时，访问权限、记录、路由与支持服务将如何运作。
各自独立的管理
使用多个产品，可能意味着彼此独立的访问权限、设置与支持关系。
对账节点
检查订单、支付、收据与报表记录，在哪些环节需要相互核对或导出。
顾客数据范围
确认某个营销工作流程可使用哪些经同意的订单相关情境信息，以及适用于哪些角色与条款。
厨房路由
核实每个下单渠道，如何将订单送达正确的厨房工作站，并将状态回传给员工。
共享运营层，依需求设置。
共享菜单基础
已设置的菜单数据，可服务于 POS、扫码点餐与 Storefront 渠道。
互联的订单工作流程
支持范围内的桌台、柜台、线上与外送订单，可进入 Cibus 的厨房流程。
关联的支付记录
支持范围内的现金、银行卡、分单、小费、代金券与收据记录，与相关订单保持关联。
获授权的顾客情境
获授权的订单、收据与同意情境信息，可支持已设置的顾客工作流程。
经营者工作台
已设置的运营管理、支付、报表、员工与洞察功能，可通过 Cibus 产品取用。
各项功能问题，逐一对照。
此为类别层面的评估框架，并非声称每个独立产品的表现完全一致。请依据贵餐厅自身的工作流程，核实入围服务商与建议中的 Cibus 范围。
| 功能 | 产品各自独立时 | Cibus 的做法 |
|---|---|---|
| POS | 检查菜单、员工、支付与报表的设置，是否在不同系统中重复存在。 | Cibus POS 使用已设置的菜单、订单、支付、员工与报表情境信息。 |
| 扫码点餐 | 检查扫码订单，如何与桌台、厨房及支付工作流程衔接。 | Cibus 的扫码订单，可使用已设置的菜单、订单、厨房与支付工作流程。 |
| 厨房显示 | 检查哪些下单渠道，可将出单分派至各厨房工作站。 | Cibus KDS 可从已设置的 Cibus 渠道，接收支持范围内的订单。 |
| 支付 | 检查收款记录、订单与日终审核，彼此如何连接。 | 支持范围内的 Cibus 支付记录，会与相关的一笔或多笔订单产生关联。 |
| 收据 | 检查电子收据与热感收据，是否使用最终的订单与支付记录。 | Cibus 可根据已记录的订单与支付情境信息，开立已设置的电子收据与热感收据。 |
| 员工手机应用 | 检查哪些楼面工作流程，需要固定终端或另行更新。 | Cibus Staff 支持按角色范围划分的桌台、进行中订单、班次与支付工作流程。 |
| 报表 | 检查在进行运营审核之前，哪些数据须先导出或合并。 | Cibus 报表功能，会在已设置的范围内，使用现有的订单与支付记录。 |
| 顾客营销 | 检查受众数据、渠道同意记录与营销活动记录，如何相互衔接。 | Reach 可针对已设置的营销活动，使用获授权的订单情境信息，以及已记录的渠道同意状态。 |
| 社交内容 | 检查菜单与品牌情境信息，如何进入内容审核流程。 | Stories 会根据已设置的菜单与品牌情境信息，准备可编辑的草稿，供店主或经理审核。 |
| 线上点餐 | 检查品牌化点餐渠道，如何与菜单、厨房及结账流程连接。 | Storefront 可连接已设置的 Cibus 菜单、结账与厨房工作流程。 |
| 配送运营 | 检查派单、配送状态与确认记录，在何处管理。 | Rider 会将已设置的配送任务与状态记录，连接至 Cibus 的订单工作流程。 |
| AI 洞察功能 | 检查分析所使用的数据来源情境信息，以及由谁负责审核相关建议。 | AI 洞察功能会根据获许可的餐厅情境信息，准备简报与建议，供经营者审核。 |
| 多门店管理 | 检查门店范围、角色、设置与报表，是分开管理还是整合处理。 | Cibus 支持集团层级的可视性，并搭配餐厅范围的设置与访问权限管控。 |
选择前应先厘清的问题。
什么是 Cibus？
Cibus 是一套面向企业（B2B）的餐厅操作系统。它将已设置的产品——涵盖服务、厨房运营、支付、员工、报表、直接点餐、顾客增长与配送——整合于同一个平台之中。
此比较是否针对特定的 POS 或软件服务商？
不是。本页比较的是 Cibus，与「分别组装独立餐厅工具」这一运营模式，并非针对每一家服务商的效能评比：个别产品可能提供整合功能或更广泛的能力，因此采购方应直接向每个入围系统核实相关信息。
Cibus 能否取代餐厅目前使用的所有工具？
不会自动如此。答案取决于所选择的 Cibus 模块、餐厅工作流程、市场、支付设置、硬件与所需的整合项目。需求了解阶段，会梳理出哪些系统可由 Cibus 取代、哪些应保持连接，以及哪些应维持原状。
餐厅能否分阶段导入 Cibus？
可以。餐厅可先确定所需的产品与门店范围，再规划后续新增的模块。产品之间的依赖关系、数据迁移、硬件、培训与推行责任，会在提案中一并确认。
Storefront、Reach、Stories 与 Rider，是否为已实现的 Cibus 产品？
是的。Storefront、Reach、Stories 与 Rider，均为已实现的 Cibus 产品。具体的渠道、服务商、市场与部署可用性，会在需求了解阶段确认。
选择单一平台，是否保证能降低成本或提升效能？
不会。商业与运营方面的结果，取决于该餐厅本身、现有合约、产品范围、支付设置、硬件、人力配置与推行方式。请以书面提案与实际运营契合度为比较依据，而非预先假设会产生节省成本或效能提升的结果。