Channel Manager 恢复之后，酒店还要核对什么？

系统重新连上了，你却还不能马上把那几张临时记录收起来。中断期间，同事接下的订单、收过的款项、已经安排的房间，都需要与后台重新对上。

当时先把客人安顿好，是管理者与团队一起补位的结果。恢复之后，也需要一个清楚的做法，保留大家已经做过的事，让下一班不用从头追问。

客人已经接待好了，记录也值得被好好接住。

先分清已确认的事件与自己的酒店情况

Preno 在11月6日公告中转述合作方 SU／STAAH 安全事件及服务恢复，并称 Preno 客户资料未在该事件中受损。 [1]

这不支持把所有 Channel Manager 中断都称为攻击，或把所有使用者都列为资料受损者。ITOCHU 8月的另一份研究讨论酒店人员遭钓鱼、账号接管的路径，并非同一事件。 [2]

以下是 MythAsia 为酒店整理的一般运营核对框架，不是上述厂商的专用操作指南。是否可以重新接入、恢复自动任务或改变同步设置，应按酒店获确认的安排及供应商／负责技术人员的指引处理。

明确目前哪一段不能使用：Channel Manager 同步、PMS、付款、房卡，或其中的接口。一个平台显示在线，并不能单独证明其他环节也已经正常。

按酒店获批准的应急流程接待；记录临时处理的订单参考、处理时间、已确认状态、经办人和待处理事项。只保留完成核对所需的资料，使用获准的保存位置和访问权限。不要把账号密码、API key 或完整付款卡资料写进交班表。

如果无法可靠确认预订、款项或房态，交由获授权人员决定下一步。不要为了清空队列擅自绕过必要的身份、收款或房间状态核实，也不要凭空假设自助机能够离线接替外部系统。

指定核对负责人，与供应商明确可核实的受影响时段和已经恢复的服务。以原有预订参考及获准记录逐项对照；下面四项由酒店结合自己的系统确定证据与负责人。

对照渠道确认、PMS 和临时记录。人工建立过的订单，重新出现时先查是否同一笔，再决定是否需要处理。改期、取消和待确认事项分别标记，不把重新同步等同于一笔新订单。

按酒店授权，通过获准的交易记录核对房费、押金、退款及处理时间。界面缺少资料不等于没有付款；核实前不要仅凭空白状态再次扣款或要求重付。状态不明的交易交给获授权负责人及相应供应商处理。

对照实际入住、退房和清洁状态，确认 PMS 房态是否一致。按酒店流程核实房卡有效情况；不要为了让记录看起来整齐而随意改房、重复制卡或重置仍在使用的房间。

把已确认与待核实分开。每项未完成事项写明下一步、接手人、下次检查时间及升级渠道，不只留一句“系统问题”。住客仍在等的事项按酒店现行优先级与授权处理。

下面这组字段可复制到酒店获准使用的交班记录。它不是客人证件、密码或卡资料的收集表。收集范围、访问权限及保留期限仍按酒店政策处理。

一项事项确认解决后，由指定人员记下依据和完成时间。未解决的记录保留清楚状态；不要为了交班完成而把未知改成已完成。

让负责人员明确确认适用的订单、款项与现场状态已核对；不能确认的项目仍有负责人及下一步。按批准的范围验证恢复后的实际流程，必要时先测试，再恢复相应自动任务。技术服务恢复的确认来自负责方，运营核对完成的确认来自酒店，两者不能互相代替。

回看中断期间临时改变过的通知、付款安排、网站入口或操作方式，确认哪些应保留、撤回或由供应商处理。不要把别家酒店的恢复步骤直接套进自己的配置。

最后和同事复盘：哪个记录最难找，哪项责任不清，哪一段可以事前准备。复盘是把补位经验留下，不是事后找一个人承担所有问题。

评估酒店自助入住或 hotel automation 时，我们从酒店的预订、PMS、付款、房卡与人工接手流程出发，梳理依赖关系、例外责任和需要验证的范围。实际对接、支持、培训及恢复配合须逐店确认。

这篇文章不代表 MythAsia 已验证可在所有 Channel Manager 中断时持续运行，也不提供防攻击、零中断、自动补回全部资料或避免损失的保证。安全事件的技术调查与处置，交由相关供应商和酒店授权的专业人员处理。

先看管理者运营指南，再对照实际产品流程与案例。带来一段中断后最容易漏接的流程，我们从具体问题开始评估，不必先整理一整份采购清单。

不能仅凭能够登录作判断。先确认具体服务恢复范围，按酒店批准的验证和核对结果，再由获授权负责人决定相关操作。

不一定。应通过获准的交易依据核实，区分已收、未收和状态未知，避免在未知时重复收款。

不能直接这样假设。自助终端同样可能依赖PMS、网络、付款和房卡接口，必须核实该酒店配置及相应人工接手路径。

带来现有PMS、Channel Manager 与房卡配置，以及一段最容易漏接的流程。先把依赖与责任讲清楚，再判断需要改变什么。