旅宿取消、退款与未通知而未入住的处理｜付款、房量与记录步骤

受理住宿预订取消后，处理不会在删除预订时就结束。客房房量、付款、退款、住客联系与会计记录也必须一致。

未通知而未入住时，不能只因住客没来，就未经确认直接向信用卡收款。应确认预订时提示的取消政策、住客同意、付款服务条件，再由人批准收款。

本文说明的是小型旅宿防止漏处理的实务步骤，不是个别法律判断。对规约或收款合法性有疑问时，请向付款公司、预订服务或专业人士确认。

不删除预订，而是改变「状态」

原则上，不从管理画面完全删除已取消预订。应区分以下状态并保留历史。

状态	意义	主要后续处理
住客原因取消	住客提出取消请求	判断取消费、退款、释出房量
旅宿原因取消	设施无法提供住宿	全额退款、替代说明、停止销售房量
日期变更	改到其他日期	确保新日期、价差、释出旧房量
未通知而未入住	未联系也未抵达	确认联系、政策、判断收款
付款失败	付款未完成	保留或取消预订、说明重新付款
退款处理中	已操作退款，等待完成	日后确认付款画面与明细
退款完成	已确认退款结果	结束记录

删除后，就无法追踪谁在何时做了什么判断，以及为何退款。

固定处理顺序

收到取消联系后，依下列顺序处理。

找出预订
确认本人与请求内容
确认预订当时适用的政策
计算取消费与退款金额
由责任人批准金额
变更预订状态
确认客房房量如何恢复
对原付款交易退款
告知住客内容与反映所需时间参考
日后核对付款结果与操作记录

依预订管道，可能需要从OTA管理画面操作，也可能从旅宿预订系统操作。在告知住客「请从OTA办理」之前，先确认哪一方才是正式受理管道。

防止重复预订的房量操作，请参阅电话、OTA与自家预订的房量管理步骤。

步骤1：确认预订与本人

用电话或电子邮件受理取消时，至少核对下列项目。

预订编号
住客姓名
抵达日期与晚数
预订管道
已登记的电话号码或电子邮件地址
对象客房与人数

不要只凭发件人名称判断，要确认与预订记录的联系方式一致。不得询问完整卡号或安全码来验证本人。

步骤2：查看预订当时的政策

确认的不是目前网站上刊登的规约，而是受理该笔预订时向住客提示的条件。

免费取消期限
期限后的取消费率
当天取消与未通知而未入住的条件
灾害、交通停驶、传染病等例外
退款方式与时间
OTA独有条件
住客同意的记录

若是否可退款依房价方案而异，也要记录方案名称。保存画面、确认电子邮件、规约版本等日后能说明的资料，但不要过度复制个人信息。

步骤3：由两人确认退款金额

退款金额依下列方式整理。

预计退款金额＝已收金额 − 适用取消费 − 规约允许扣除的费用

税、点数、优惠券、OTA手续费、付款手续费的处理，依合同与会计方式而异。不要推测，请向预订服务与会计负责人确认。

计算表范例

项目	金额与内容
预订总额
已收金额
免费期限
取消受理日期与时间
适用条件
取消费
预计退款金额
计算者
批准者

避免让退款负责人独自完成计算、批准、执行、核对。小型家族经营即使难以安排两人确认，也要保存计算画面，隔天由另一人核对。

步骤4：更新预订与客房房量

退款前，先确定预订状态与房量处理方式。

全部取消：恢复全部住宿日期的房量
部分取消：只变更对象客房与人数
缩短晚数：只恢复不再需要日期的房量
日期变更：先确保新日期，再恢复旧日期
旅宿原因：另外判断是否可重新销售
未通知而未入住：确认隔天以后的连住晚数如何处理

通过空房日历确认预订状态变更是否已反映到OTA或自家网站。不要只退款却持续封锁房量。

步骤5：退回原付款交易

原则上，应在付款管理画面开启原交易，对该交易执行退款。

Stripe官方退款文件说明，可对已成功的付款全额或部分退款，退款只能退回原付款方式。Stripe余额不足时，信用卡退款可能处于待处理状态。

Square官方退款说明说明支持全额、部分与按商品退款，信用卡付款退款期限为原交易日起1年内。QR码付款期限依服务商而异。

退款时的记录项目

原预订编号
原付款ID与交易编号
退款金额
全额或部分退款
退款原因
操作日期与时间
操作者与批准者
付款画面状态
通知住客的日期与时间

不要将卡号转抄到记录。付款ID也不要贴到公开页面或共用聊天中。

区分「已操作退款」与「退款完成」

旅宿按下按钮后，不一定立即反映到住客明细。退款请求会经过发卡公司等机构处理。

因此将状态分为两个阶段。

退款处理中：已在付款服务执行退款
退款完成：已在付款画面确认成功，并完成必要核对

Stripe说明，退款偶尔可能失败，会通知失败事件。Square也说明，反映到明细所需的时间依发卡公司而异。

对住客不只说「已退款」，也要告知金额、退款去向，以及发卡公司可能需要时间才反映。不要保证具体反映日期，也要提供确认窗口。

日期变更不要混同取消与新预订

日期变更时，同时整理下列项目。

新日期的房量
新旧房价的差额
新取消条件
追加收款或部分退款
OTA、预订系统、付款的显示

若先取消旧预订，新日期可能在此期间售出。先确保新日期，确认变更内容后再恢复旧房量。

旅宿原因取消

因设备故障、灾害、营业因素等无法提供住宿时，不要自动套用与住客原因相同的取消费。

记录无法提供住宿的原因
迅速联系住客
确认已收金额的退款
通过OTA预订时，确认指定步骤与联系窗口
考虑能否提供替代旅宿说明
将对象客房停止销售

补偿与额外费用的处理依情况、合同而异，不要自行判断后承诺，必要时向专业人士咨询。

未通知而未入住，先确认再收款

超过预计入住时间仍未抵达时，依下列顺序处理。

确认预订记录与预计抵达时间
确认电子邮件、电话、OTA消息
考量安全，尝试联系住客
确认交通障碍与灾害信息
记录联系时间与方式
在规定时间，由责任人判定未通知而未入住
确认预订时的政策与同意记录
依付款服务与OTA步骤判断收款
决定隔天以后连住房量如何处理

Square面向住宿设施的说明指出，消费者也可对未入住与取消费提出异议，可能因发卡公司判断而发生拒付。预订时明确提示政策、取得同意记录很重要。

不要认为「已存储卡片信息就能收款」，应先确认该付款方式是否支持未入住收款，以及能否确认住客同意。

预授权与实际扣款是不同处理

暂时保留信用卡可用额度的预授权，与实际完成扣款不是同一件事。

Stripe官方文件说明，支持的付款方式可分开进行授权与实际扣款，但授权有有效期限，若未在期限前实际扣款，资金会解除保留。日本以JPY计价的适用卡片也有最长30天的说明，但卡片种类与条件不同。

不能只靠一般短期预授权，持续保证几个月后的住宿预订。应使用预订系统与付款公司正式提供的住宿用途方式。

为拒付准备的记录

即使已收取消费或未入住费，住客也可能向发卡公司提出异议。应保存以下必要且充分的信息。

预订日期时间与管道
住宿方案与房价
提示过的取消政策
住客同意记录
确认电子邮件与重要联系历史
取消受理日期与时间
预计抵达时间与尝试联系的记录
收款金额的计算依据
退款与收款的操作记录

决定保存期限与访问权限，妥善删除不再需要的信息。不得将卡号或安全码作为证据保存。

区分员工权限

作业	接待负责人	责任人	核对负责人
受理取消请求	○	○
计算取消费	○	○	确认
批准金额		○
执行退款	限制	○
确定未通知而未入住		○
隔天核对入账			○

Stripe、Square与预订系统的管理画面应设置2步验证，迅速停用离职者账号。登录保护也可参阅WordPress的BASIC验证与2步验证。

每天的未完成清单

营业结束前，确认下列项目是否为0件。

已受理取消、尚未变更预订
已取消预订、尚未释出房量
已批准退款、尚未执行
退款处理中、尚未确认结果
已变更日期、尚未处理差额
未入住候选、责任人尚未确认
尚未发送住客通知

件数不是0时，记录负责人与下次确认时间。

请AI制作确认表的提示词

请为小型旅宿制作取消、退款与未通知而未入住的确认表。
预订管道为［OTA名称、电话、自家网站］，付款为［服务名称］。

请将下列情况分成不同步骤。
- 住客原因的全部取消
- 晚数与人数的部分变更
- 日期变更
- 旅宿原因取消
- 未通知而未入住
- 付款失败

每个步骤须包含本人确认、适用规约、计算、批准、预订状态、房量、付款、通知、隔天核对。
服务专用条件只使用官方资料，不明时请标示「需确认」。
不要处理真实预订信息、卡片信息或API密钥。
不要制作让AI独自执行收款或退款的步骤。