1. 电子表格可以保存预订数据，但它无法在宾客到来前捕捉到超售，发送抵达前消息，或标记未付尾款。
2. 小型酒店预订工作流包括六个阶段，在每个步骤中手动跟踪都会引入特定的失效点。
3. 大多数工作流失败并非数据录入错误，而是时机错误：正确的信息存在于某处，但未能在需要的那一刻传达给正确的人。
4. 用互联的预订软件取代电子表格能够弥补这些时间差，且无需扩大团队规模。
勉强管用的电子表格
大多数小型酒店在起步时都会使用电子表格，因为它能顺利处理早期的业务增长。你列出预订订单，标记日期，并记录来源。在出现问题之前，它一直都很有效。
问题通常从接入第二个 OTA 渠道开始。电子表格仅记录你输入的内容，但并未与 Booking.com 或 Airbnb 互联。夜间收到一个预订，你第二天早上更新了电子表格。当天晚上又收到相同日期的直接咨询，并在你打开笔记本电脑前确认了该订单。双方都不知道他们预订了同一间客房。
这种情况——原本不该发生的超售——是最明显的信号，表明预订工作流已经超出了管理工具的处理能力。但这并不是唯一的信号，其他问题会以更隐蔽的方式在宾客生命周期的六个阶段中显现出来。
阶段 1：接收预订
每个预订订单都通过以下三个渠道之一进入：OTA 平台、通过酒店网站或电话的直接预订，或者是上门散客。
手动失效点： OTA 预订以电子邮件或平台通知的形式到达。为了记录它们，必须有人阅读通知，打开电子表格，找到正确的行列并录入预订信息。这些步骤中的每一步都会引入延迟，并增加出错的几率。如果一家住宿管理着三个 OTA 渠道和一个直接预订邮箱，那么在数据进入主记录之前，需要处理来自四个独立收件箱的信息。
这种延迟非常致命，因为电子表格中的房态只有在其最后一次更新时才是准确的。两小时前到达但尚未录入的预订，在任何查看电子表格的人看来，仍然显示为可用客房。
酒店管理系统与 OTA 渠道连接后，能够直接接收预订订单并实时同步房态。当 Booking.com 确认预订时，所有已连接渠道上的该客房会同时关闭，根本不需要任何人打开电子表格。
阶段 2：确认与抵达前沟通
记录预订订单后，在宾客抵达前需要完成两件事：宾客收到包含预订详情的确认信息，以及收到包含入住办理时间和门禁指引等实用信息的抵达前消息。
手动失效点： 在手动工作流中，这两条消息都需要有人记得去发送。当预订订单通过 OTA 产生时，确认信通常发送得很可靠，因为平台会自动发送。但对于直接预订，这就完全取决于处理咨询的人员。只有在工作人员已养成刻意习惯的住宿，抵达前消息才能被稳定发出。
当抵达前消息未发送时，宾客抵达时会带着问题，需要占用住宿管理人员的时间来解答；有时还会因为入住办理时间未明确沟通而在错误的时间到达。发送消息本身并不难，问题在于无论抵达当天有多忙，是否能记得为每个渠道的每一个预订发送消息。
阶段 3：客房分配
在入住率较低时，将预订与特定客房匹配非常简单。但当有多种房型可用、涉及特殊要求，或者上一个预订订单的延迟退房与下一个预订订单的提前抵达发生重叠时，情况就会变得复杂。
手动失效点： 在电子表格工作流中，客房分配全凭视觉检查。工作人员查看哪些单元格已被占用，然后挑选一间看起来空闲的客房。这种检查的准确性完全依赖于电子表格的准确性，而这又受限于最后一次录入数据的人。如果 Booking.com 消息中备注了需要一楼客房，但未转移到电子表格中，那么在分配客房时就不会显示该要求。
超售——也就是将同一间客房分配给两个预订订单——是这种失效最严重的形式。如果房态在实时系统中进行管理，而不是在一个手动维护的表格中，这种情况是完全可以避免的。
将所有预订渠道连接到统一视图
当 Booking.com、Airbnb 和直接预订订单一经产生便录入 Smart Order 时，所有渠道上的房态会实时同步。客房分配将基于最新数据，而不是一小时前刚更新过的电子表格。
阶段 4：入住
入住是宾客和预订数据第一次需要实时匹配的环节。宾客在预订时就已设定了期望。住宿管理需要确认房型、核实付款、记录所有要求并完成钥匙交接——所有这些都需要在宾客站在前台时完成。
手动失效点： 在电子表格中，预订记录通常只有最基本的信息：姓名、日期、客房，可能还有关于来源的备注。而支付状态——是否已收取押金，尾款是否到期——往往是单独追踪的，或者直到入住那一刻才核实。如果一位三周前已支付押金的宾客抵达并期望只付尾款，若押金记录未与预订订单关联，这就会引发问题。
未从 OTA 消息转移到电子表格的特殊要求也会在入住时暴露出来。要求安排安静客房或提前入住的宾客在预订时就提出了请求，他们有理由期待这些要求能得到满足——如果发现要求没有被记录，就需要立即进行沟通来解决问题。
阶段 5：住宿期间
入住之后，预订工作流便转入在住管理阶段：处理各项请求、记录额外费用，并追踪离店日期或房型的任何变更。
手动失效点： 在手动工作流中，在住费用是最常遗漏的记录。迷你吧消费、延迟退房费、停车费——每一项都需要有人记录下来，并确保在退房前与预订订单关联。在电子表格中，这通常意味着手写便签、实体钥匙上的便利贴，或群聊中的一条消息。只有写下它的人才看得懂，后续查看预订记录的人不一定追踪得到。
延迟退房请求是最具破坏性的在住变更。两小时的延期会直接影响房务工作的排班，但在手动工作流中，那个电话或短信可能无法在清洁人员抵达打扫房间之前传达给他们。
阶段 6：退房及后续
退房意味着预订订单的结束。尾款结清，客房退回库存，如果酒店有后续跟进，还会发送一条评价请求。
手动失效点： 退房时的账单应反映住宿期间的每一项费用。在手动工作流中，未在住期间记录的费用，自然在退房时也无法收取。没有提示，没有账目，也没有系统警报。这笔成本只能自行承担，甚至没人知道它被漏掉了。
退房后的评价请求是最容易实现自动化的环节，也是最不可能手动完成的环节——它需要员工记住在每次离店后的 24 小时内发送，而且不仅仅是发给那些看起来很满意的宾客；如果没有系统支持，这种一致性几乎无法保持。
工作流互联后会发生什么改变
互联的预订工作流不需要增加人员。它只需要原班人马在一个能自动处理各个阶段过渡的系统中工作。
OTA 预订会在产生时进入系统，并关闭跨渠道的房态。确认信和抵达前消息将按计划发送。客房分配基于实时房态。在住期间的费用会附加到预订订单上。退房账单包含所有已记录的费用。次日会自动发送评价请求。
电子表格的失败并非因为使用它的人——而是因为它根本就不是为了串联工作流各个阶段而设计的。它是一个记录工具，而不是预订订单管理工具。 酒店管理系统专为小型住宿设计的酒店管理系统能自动处理各个阶段之间的衔接，而不再像电子表格那样需要人工干预来搭建桥梁。
在一个系统中运行完整的预订工作流
Smart Order 在一个数据看板中统一管理 OTA 预订订单、直接预订订单、客房分配、在住费用和退房——因此住宿管理可以利用最新数据完成每个阶段的工作，而无需在每一步操作之间更新电子表格。
常见问题
什么是酒店预订工作流？
酒店预订工作流是指从产生预订订单的那一刻起，到宾客退房并将客房退回库存之间的一系列步骤。这些阶段包括接收预订订单、确认、抵达前沟通、客房分配、入住、在住费用追踪以及退房结算。互联系统能自动处理各阶段间的交接；而手动工作流则需要工作人员手动发起每一个步骤。
为什么小型酒店在使用基于电子表格的预订订单管理时会举步维艰？
电子表格仅能记录员工输入的内容，无法自动接收 OTA 预订订单、发送沟通信息，也无法跨渠道实时同步房态。预订订单产生和人员记录之间的延迟，创造了一个同一客房可能被重复预订的时间窗口。特殊要求、在住费用和抵达前消息均依赖于人工操作，在繁忙时期很容易被遗漏。
酒店管理系统如何防止小型酒店发生超售？
连接至 OTA 渠道的酒店管理系统能直接接收预订订单，并在预订确认的一瞬间关闭所有已连接平台上的房态。预订订单产生和库存更新之间没有任何延迟——预订记录会自动显示在系统中，该客房会立即被锁定，从而避免超售。
小型酒店应该在其预订系统中跟踪哪些内容？
每条预订记录都应包括宾客姓名和联系方式、日期、房型及客房分配、来源渠道、房价及付款状态、特殊要求、在住费用以及退房结算金额。抵达前和退房后的沟通记录应当与预订订单相关联，从而为每一次宾客接触点保留完整的记录。
在什么情况下，电子表格对于酒店预订订单管理不再适用了？
当增加第二个 OTA 渠道，或者预订记录需要多人更新时，大多数住宿都会达到使用极限。前者会造成同步问题——一个渠道上的房态无法在其他渠道上体现。后者会引发版本问题——两人在不同时间更新同一个文件会产生错误，而这种错误往往只有在预订冲突爆发时才会被发现。
