自助退房听起来简单：客人点一下，系统退房，完事。
实际流程比这复杂得多。客人自助退房后，系统会给前台推一条审核消息——因为房间可能有未结消费、可能设备损坏、可能是提前退房涉及退款。前台要审核，审核通过才算真正完成。
11 月批次在这条链路上补了一个入口：自助退房审核消息里新增「查看房间账单」，去查房提交成功页与通用查房成功页也新增房间账单入口，点击进入当前审核对应房间的账单详情，返回时精确回到来源页。
之前的问题在哪
问题一：审核时看不到账
收到审核消息，只有房号和客人信息。想知道这间房有没有迷你吧消费，得另外打开房间账单页面搜房号。
问题二：查房结果和账单对不上
客房说「房间少了一瓶水」，前台查账单发现没记。两边各说各的，没有共同的界面可看。
问题三：返回时迷路
从消息跳到账单，看完返回，回到了首页而不是审核列表。要重新找那条消息。
第三个问题看起来小，但它决定了员工愿不愿意用这个入口。一次跳转要重新找路，第二次就懒得点了。
三个入口的位置
| 入口 | 使用场景 |
|---|---|
| 自助退房审核消息 | 收到推送时，直接点进去看账单，判断能否通过 |
| 去查房提交成功页 | 客房查完房提交结果后，顺手核对账单 |
| 通用查房成功页 | 常规退房查房，同样能核对 |
第三个入口是普遍性的改进。它不限于自助退房，所有查房流程都能用。
审核时该看哪四项
第一项：房费是否正确
入住房型、天数、价格。自助退房最容易出问题的是「提前退房」——房费要不要退、退多少。
第二项：房间消费
迷你吧、洗衣、租借物品。这部分最容易被漏，因为客人不会主动说。
第三项：押金与余额
押金够不够抵扣消费，多收的怎么退。自助退房时客人可能已经走了，退款要走线上。
第四项：商品订单
房间账单里的商品订单状态。这批更新同时给 APP 加了商品的反结、部分结账、冲调，就是为这类场景准备的。
第三项是最麻烦的。客人已经离店，退款只能走线上。如果押金是现金收的，退款会很麻烦——要么转账，要么让客人回来。
所以自助退房的门店，应该尽量把押金改成线上预授权。这个前提比功能本身更重要。
一个顺畅的审核流程
| 步骤 | 动作 | 判定 |
|---|---|---|
| 1 | 收到审核消息，点开 | — |
| 2 | 看房间账单 | 有无未结消费 |
| 3 | 有消费则补录或告知客人 | 能否线上补付 |
| 4 | 通过审核 | — |
| 5 | 系统自动解冻押金、发电子发票 | — |
第三步是分叉点。客人已经走了，补录消费之后怎么收钱？
一个务实的做法：小额消费（50 元以内）从押金里扣，不打扰客人；大额消费先打电话告知，征得同意再扣。未经告知直接扣款，是最容易引发投诉的做法。
对「免查房」的影响
自助退房和免查房是一对组合。很多门店为了提速，直接免查房。
免查房
客人投卡即走，体验最好。风险是消费漏收、损坏难追。
必查房
消费能收全，但要等 3–5 分钟。自助退房的意义被抵消了一半。
这批更新实际上给了一个中间方案：查房结果和账单在同一个界面，查房的同时顺手核对。
如果查房的人能当场看到账单，那查房的 3 分钟就不是「纯等待」，而是「核对」。这样查房的成本被摊薄了。
一个容易被忽略的细节
「返回时精确回到来源页」这句话，是这次更新里最不起眼但最实用的部分。
为什么这件事重要？因为前台处理审核时，往往同时开着三四个界面。如果每次看账单都要重新找回来，一天下来会浪费十几次「找回」的动作。
移动端的效率，往往就藏在这些「不用重新找」的细节里。
最后一句
自助退房的价值是把「退房」这个动作从柜台挪到客人手上。
但真正决定它能不能跑起来的，是审核这一端够不够快。客人可以自己点退房，但审核在人手上——审核慢了，客人还是要等。
这批更新补的就是这一端。