避免电话、OTA与自家预订造成重复预订｜小型旅宿房量管理步骤

小型旅宿可能在接电话时收到OTA通知，自家网站也有预订进来。即使每个管道都正常运作，只要人工输入延迟或整合停止，就可能发生重复预订。

结论很简单。

选定一本显示正确空房状况的台账；受理电话预订、变更、取消、包场的人，当场更新。

即使导入渠道管理系统，也需要这套流程。本文将它整理成不熟悉IT的旅宿主人也能与家人、员工分享的形式。

重复预订的五个原因

1. 电话预订留待稍后输入

只留下便条就回去接待客人，期间又有线上预订进来。「稍后」是最危险的时间。

2. 房量有两份权威原始记录

若把纸本台账与电脑、OTA管理画面与预订系统两者都当成正确房量，就会产生差异。

3. 整合有时间差

收到预订后，其他销售管道可能需要一段时间才关闭销售。iCal整合与API方式的同步范围、反映方式不同。

4. 变更或取消只修正一边

例如预订台账已修改日期，OTA或付款系统却仍保留旧内容。

5. 只看预订件数，不看房间

若不考量连住、房型、换房、清洁造成的暂停销售，可能只有中间某天重叠。

预订引擎、渠道管理系统、PMS的角色，整理在这篇文章。

先选定一份「权威原始记录」

权威原始记录，是所有人判断「这个画面显示空房，就可以销售」的基准。

候选包括以下任一项。

渠道管理系统的房量画面
PMS或预订管理系统的客房台账
整合OTA与自家预订的管理画面

纸本台账可作为系统停止时的临时记录或当天确认，但在线上销售期间，只以纸本作为权威原始记录很危险。

选定权威原始记录时要问的问题

能否立即录入电话预订
OTA与自家网站预订是否自动导入
连住的所有日期能否一次停止销售
能否封锁包场、休馆、维修中房间
能否从记录确认由谁变更
能否用智能手机紧急操作
如何通知故障

选定后，要将纸本台账、共用日历、各OTA画面明确标示为「确认用」或「销售管道」。

电话预订用「30秒规则」先封锁房量

受理电话预订后，在详细顾客信息之前先封锁客房房量。

确认旅宿名称、希望日期、人数、晚数
用权威原始台账确认空房
通话中录入暂订或正式预订
输入住客姓名与电话号码
输入方案、餐饮、房价、付款方式
复述内容，发送确认电子邮件或书面文件

若无法立即开启管理画面，应告知「确认空房后会回电」。不要只凭记忆或昨天打印的纸本就承诺。

放在电话旁的一张说明

开启权威原始台账的方法
新增预订按钮的位置
暂时保留期限
必填项目
故障时的记录用纸
有疑问时的联系窗口

让新人也能按同样顺序操作。

暂时保留一定要有期限

「与家人商量后回电」「团体人数未定」的预订，若无限期封房，会失去销售机会；但若不封锁房量就等待，也可能重复预订。

暂时保留应记录下列项目。

住客姓名与联系方式
对象日期与客房
暂时保留原因
回复截止日期与时间
负责人
到期后自动解除，还是由人确认

到期后改为「确定」「延长」「解除」其中一种，不要放着不管。

收到OTA预订时的确认

即使有自动整合，看到通知的人仍要确认下列项目。

预订已进入权威原始台账
从抵达日至出发前一天的房量已封锁
房型、人数、餐饮、房价正确
同一时间没有其他管道的预订
变更与取消也已反映到权威原始记录

「收到预订电子邮件」本身不能证明其他销售管道已关闭房量，要查看权威原始记录的客房日历。

自家网站预订的确认

自家网站应区分预订表单送出与预订确定。

受理预订请求：旅宿确认后才确定
即时预订：符合空房与付款条件时自动确定

若将请求受理显示成即时预订，住客会以为已确定。画面与电子邮件应明确标示「已受理」「确认中」「已确定」。

即时预订也要测试付款成功与预订确定的顺序。不要漏看付款失败却只封锁房量，或已付款却没有建立预订的状况。付款方式的选择请参阅Stripe、Square与预订系统标准付款功能比较。

变更与取消同时确认入口与权威原始记录

受理变更后，先确认是否有能保留历史的变更功能，再考虑删除旧预订重新建立。

日期变更

在权威原始记录确认新日期的空房
先确保新房量
向住客说明房价与取消条件
变更预订
确认旧日期已恢复可售
也确认OTA、电子邮件与付款的显示

取消

确认预订编号与本人信息
判断取消费
将预订改为取消状态
确认房量是否恢复可售
必要退款由人批准后执行
向住客发送完成通知

避免只删除预订却留下付款，或只退款却继续封房等单边处理。

停售也要像预订一样录入

下列情况也会占用客房房量。

维修或检查
清洁来不及完成的日期
旅宿主人的休息日
整栋包场
领队或员工使用的房间
灾害或交通障碍造成休馆

不要只用口头或便利贴传达，应在权威原始记录录入为「封房」，并留下原因与解除日期。

同步停止时的紧急步骤

发现整合故障后，要先控制新预订流入，再调查原因。

存储或打印权威原始记录的目前房量
找出受影响的OTA与自家预订
从可安全操作的销售管道开始关闭房量
电话预订按时间顺序写入紧急记录用纸
每件新增、变更、取消逐一记录
向服务商联系故障时间与症状
恢复后，按时间顺序比对权威原始记录与各销售管道
确认没有问题再恢复销售

刚恢复就批次覆盖，可能删除故障期间的新预订。请逐件核对。

紧急记录用纸的项目

受理时间	管道	预订编号	住客	住宿日期	客房	新增、变更、取消	已反映至权威原始记录	负责人

含真实住客信息的纸本应上锁；恢复后输入权威原始记录，再按保管与销毁规则处理。

每天早晚比对两次

小型旅宿也至少要在开始营业时与预订受理结束前比对。

早上确认

当天抵达、出发、连住
未付款、未确定、暂时保留
房间分配与清洁状况
夜间收到的OTA与自家预订
同步错误通知

傍晚确认

今天受理的电话预订都在权威原始记录中
变更与取消已反映到各销售管道
明天以后的暂时保留期限
付款与预订状态一致
没有漏解除停售

即使预订很少，也留下已确认「没有发生任何事情」的记录，才能区分是否漏查。

每周一次确认的数字

各管道的新预订件数
手动输入的电话预订件数
同步错误件数
从输入到房量反映的时间
已到期暂时保留件数
未处理的变更、取消件数
发现房量差异的次数

只要发现一次差异，就应重新查看哪种步骤能当场封锁房量，而非责怪负责人。

决定家人与员工的角色

作业	主要负责人	不在时	最终确认
录入电话预订	受理者	接电话的人	傍晚负责人
确认OTA通知	预订负责人	值班人员	早晚负责人
变更与取消	有权限的负责人	旅宿主人	旅宿主人
退款	旅宿主人或责任人	指定代理人	另一人核对
同步故障处理	系统负责人	服务商窗口	旅宿主人

避免「只有熟悉的人懂」的状态，至少让两人能执行电话预订、变更、取消、停止销售。

请AI制作运营步骤的提示词

为客房数［房间数］的旅宿制作防止重复预订的步骤。
预订管道为［电话、OTA名称、自家网站］。
房量的权威原始记录为［系统名称］。

请将以下内容整理成一张步骤说明，让不熟悉IT的员工也能使用。
- 通话中录入电话预订的步骤
- 暂时保留与期限管理
- 确认OTA与自家预订的反映
- 日期变更与取消
- 封房
- 同步故障时的紧急记录与停止销售
- 早晚比对

不知道系统专用操作名称时，不要推测，请保留为待确认事项。
不要使用真实顾客信息或密码作为例子。

AI制作的步骤，应由人用虚构预订从头到尾试做。