夜里一点二十，2208 的客人打电话下来，说隔壁在打牌，椅子拖了一晚上。
前台小姑娘处理得很快：查了空房，给了 1812，刷了张新房卡，送上去，说了句不好意思。全程不到五分钟。
第二天中午结账，两件事冒出来。
第一件，1812 期间那两瓶矿泉水和一个洗衣袋，挂在 1812 的房号上，结账时没人看见——因为客人是来结 2208 的单。
第二件，渠道后台显示 2208 还在住。客人退房之后，这间房在平台上是「已入住未退」，房态和渠道对不上，超售预警平白响了一次。
这两件事都不是前台的错。换房看起来是换一张卡，实际上是把这笔订单从一间房搬到另一间房，而系统里跟房号绑着的东西不止一张卡。
房号不是房间的名字
先说一个容易忽略的前提：房号不只是一串数字，它是这笔订单此刻的位置。
所以凡是跟着位置走的事实，都得跟着动——房态、保洁任务、门锁授权、渠道单、账单归集、夜审统计。反过来说，凡是跟着客人走的（早餐份数、会员等级、停车权），就不该因为换了房号重新计算。
这条分界线画清楚了，七处该动的地方就清楚了。
| 哪一处 | 换房时要动什么 | 漏了会怎样 |
|---|---|---|
| 房态 | 原房转脏房，新房从净房转在住 | 原房停在「净房」，第二天被再卖一次 |
| 订单 | 订单上的房号字段 | 房态说 1812，订单说 2208，两套事实 |
| 账单 | 两个房号期间的消费归到同一单 | 结账时两笔账各说各话 |
| 门锁授权 | 旧卡失效，新卡下发 | 旧卡还开得了 2208 的门 |
| 渠道单 | 直连订单的房号回写 | 平台与实际房号不一致，对账对不上 |
| 权益 | 早餐份数、车位按订单走，不重算 | 被当成新入住，早餐份数翻倍或清零 |
| 夜审 | 同一夜多次换房只计一个间夜 | 出租率虚高，RevPAR 被摊薄 |
下面挑四处最容易出事的展开说。
第一处：原房为什么必须是「脏房」
随手点成净房
「反正客人走了，房间是干净的」。结果这间房立刻回到可售池，当晚被卖出去，保洁没接到任务。
点成脏房或待查房
房间退出可售，保洁任务自动生成，查完再放回净房。多一步，但不会卖错。
房态的三种常驻状态，差别不在颜色，在它是否参与可售：
- 净房：可以卖，会出现在可售池里；
- 脏房：不能卖，同时触发一条保洁任务；
- 维修房：不能卖，并且不进保洁队列，要工程处理完才放回来。
换房之后原房该走哪条，取决于客人住了多久：住了一晚以上、动过床和卫生间，就是脏房；只是进去放了个行李，可以走待查、由客房确认后再放净房。
选住的房态屏把状态压在色块上，一眼就能看出哪间能卖。正因为看得清、点得快，才更容易点错——所以这里的规则不是「小心一点」，而是让脏房自己带任务：点成脏房，任务跟着来；点成净房，就什么都不会发生。
第二处：房号只能有一个主
换房时最常见的中间态是这样的：房态屏上已经把 1812 拖成在住，订单里还写着 2208。
这个窗口通常只有几十秒，但它危险的地方不是「数据难看」，而是有人会在这个窗口里把 2208 当成退房处理，或者把 1812 当成空净房卖掉。
所以顺序是固定的：先改订单，房态跟着订单走。订单是这笔生意的事实，房态是订单在屏上的投影。反过来先动房态，就是在改投影、不改事实。
判断一家门店有没有把这件事做对，看一个细节就够了：换房之后，房态屏上的新房是不是自己亮起来的。如果需要人工再去点一次新房的状态，说明订单和房态之间是两套记录，早晚会对不上。
第三处：旧卡还开得了门，这是安全口子
门锁授权是按房号下发到锁上的。换房的时候，新卡下发这一步谁都不会忘——客人要进门，忘了当场就炸。
忘的通常是另一半：旧卡失效。
客人搬走了，旧卡还在他手里。这张卡如果还能开 2208，等于留了一把能开别人房间的钥匙。真正出问题不在当天，在这张卡被转手、被捡到、被记住的那天。
蓝牙门锁的好处是授权可以即时改，不用等人到门口写卡。但「可以即时改」和「真的改了」是两件事：
新卡下发
新房号、有效期从当下算起，别沿用原订单的入住时间——凌晨换房时，原卡的有效期可能当天中午就到期。
旧卡作废
作废要按卡作废，不是按房号作废。同一间房可能存在多张卡（家人各一张），一张都不能留。
临时密码一并处理
如果之前给客人发过临时开门密码，换房后这条密码要重绑到新房号，或者直接失效。密码是挂房号的，房号变了它不会自己跟过去。
第三项是最容易漏的。临时密码是为了让客人不用下楼拿卡，很省事——也正因为省事，它在下发之后基本没人再回头看。
第四处：直连订单的房号，只能一边是主
渠道订单的房号，改法有两条路：
1. 在渠道后台改，由直连把新房间同步回 PMS； 2. 在 PMS 改，由直连回写给渠道。
两条都对，但不能同时用。两边都改，最后一定有一边覆盖另一边，而且覆盖的时间点没人记得。
实操上更稳的是第二条：前台只在 PMS 里操作，渠道侧交给系统。理由很朴素——前台在忙的时候不会去开三个平台后台，一旦需要开，就一定有人忘。
至于渠道侧没同步的情况，不用靠人盯：每日一次房态对齐检查，把「渠道在住数」和「PMS 在住数」比一遍，差出来的那几间逐个查。这比让前台记「换房要记得改携程」靠谱得多。
剩下三处，一句话各说一遍
账单要分两段。房价不同的换房（升级、降级、换到更大房型）不是「一笔调价」，是两段不同价格的间夜。合成一笔，渠道对账时拆不开，佣金也算不平。
权益按订单走。早餐份数、停车位、会员权益挂在订单的住客数上，不挂在房号上，换房不该重算。但要注意另一种换房——原住客走、新住客住进来，那是「换人」，实名登记和权益都要重来一遍。
夜审只认一个间夜。同一夜换三次房，出租率还是加一，不是加三。这条平时不出事，一旦有人手工补录，就会冒出一间不存在的房。
现场用的五步清单
一、先看新房能不能给
净房、今日无预订、不在维修状态。这一步在房态屏上完成，别先去翻订单。
二、改订单房号
只改这一处，房态、保洁、统计跟着走。改完回房态屏确认新房已经亮成在住。
三、把消费搬过来
新房间已经产生的消费（迷你吧、洗衣、送餐）要归到同一张单上，结账时才不会漏。
四、处理卡和密码
新卡下发、旧卡全部作废、临时密码重绑或失效。三件事一起做，别分两次。
五、通知两边
客房去清原房，渠道侧确认房号已回写。这一步不是礼貌，是闭环。
五步里，第一、二步是系统能带着人走的，第四、五步最依赖人。
为什么拿换房当样本
换房是门店里最小的一次「跨模块作业」：一次改住，牵动房态、订单、账单、门锁、渠道、权益、统计。
如果一套系统只是几个各自能打开的页面，这七件事就得靠前台背口诀——忙起来必然漏，漏了必然第二天才发现。
如果它是一套数据模型，改一处，其余的跟着对：改订单，房态跟着变；房态变，保洁任务跟着来；房号变，门锁授权跟着换。前台那五分钟，才真的只是五分钟。
我们做选住云管家时把房态、订单、账单、门锁放在同一套权限体系下，图的就是这个——不是功能多一个，是让「改一次」这个动作，只改一次。