01问题所在
酒店餐饮业并不缺系统，缺的是一个统一的运营事实来源。预订系统、收银系统、外卖应用、厨房显示屏、库存表和点评网站，各自只掌握一个片段。当一位宾客的夜晚出了问题，原因往往在别处：某个工位出餐慢了、缺了一样食材，或者某个时段预订过满。反馈在客人离席之后才到达，而能否补救，取决于碰巧是谁注意到了。
02系统
酒店业宾客体验与运营智能。
Guestenza 是一个横跨宾客、团队、运营、财务和智能的统一运营层，建立在同一个数据模型、同一个访问模型和同一条审计链之上。它由一系列互联产品组成：Passport 负责宾客记忆，Command 提供跨品牌、跨门店的视图，Kitchen 管理工位与库存就绪状态，Recovery 处理投诉案例，Channel 覆盖预订、堂食、自取和外送，Twin 用于决策建模。
03为何重要
每一个宾客时刻都与背后的实时运营相连，让管理者看清原因、及时行动并衡量结果。
服务对象
- 多品牌餐饮集团
- 酒店和度假村餐饮部门
- 美食广场与共享场地
- 医院、大学和工作场所的机构餐饮
04核心功能
- 01
Passport：经同意的宾客记忆
偏好、过敏信息、特殊场合和到访记录，在宾客同意的前提下保存，并提供给为其服务的团队。
- 02
Kitchen：工位与库存就绪
工位负荷、备餐时间、现有库存、损耗和差异，汇集为厨房与供应就绪状态的统一视图。
- 03
Recovery：闭环投诉处理
每一条投诉都成为有专人负责的案例，附有拟议措施、第二人的批准和记录在案的结果。
- 04
Command：品牌与门店
跨品牌、跨门店的统一视图：哪些需要关注，哪些发生了变化，哪家门店正在偏离计划。
05产品实景
截图均为 Guestenza 公开网站的原样截取，未经编辑。凡该项目将示例标注为示意或合成内容之处，均保留原有标注。
06运作方式
- 01
宾客信号
在宾客同意的前提下，记录一项偏好、一次等候、一条投诉或一次回访。
- 02
运营原因
将该信号与当时正在发生的情况并列对照：厨房负荷、库存、人手和渠道。
- 03
行动
合适的管理者会收到相关背景和明确的下一步，且不超出其权限和审批额度。
- 04
结果
结果被记录下来，让补救、服务和成本可以得到衡量，而不是凭推测。
07独特之处
Guestenza 把宾客、运营和决策放在同一份记录中，并可作为叠加层、混合方案或完整系统，与现有系统并行运作。对于自己不知道的事，它十分严谨：实测为零、数据缺失、服务提供方不可用和访问被拒，都会显示为不同的答案。
08信任与治理
每个人只能看到其角色和所属门店允许的内容，每个机构的数据在数据库层面即相互隔离。敏感操作会被记录，事后无法修改。除非机构主动开启，人工智能始终处于关闭状态。试点结果只有在实际测量后才会呈现，也不声称获得任何第三方认证。
09在组合中的定位
空间
Guestenza 把“空间”轨道带入酒店餐饮业：在这里，一栋建筑成为宾客每晚都在体验的服务。它严格遵循共同的方法：从宾客的真实问题出发，呈现证据而非猜测，补救措施须经第二人批准，并从一开始就支持英语和阿拉伯语。
同一轨道上的其他项目