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信任与治理
每个人只看得到其角色和所属门店允许的内容，各机构的数据在数据库层面就已隔离。敏感操作有记录，事后不可修改。AI 保持关闭，除非机构自行开启。试点结果只有测量之后才会展示，也不宣称获得任何第三方认证。
09在组合中
空间
Guestenza 把“空间”轨道延伸到酒店餐饮：在这里，一栋建筑变成了客人每晚亲身体验的服务。它紧贴同一套方法：从客人的真实问题出发，摆证据而不是猜测，补救一律由第二人批准。