酒店的房态有两个时间维度：今天这间房能不能卖，和下个月这间房能不能卖。多数门店只管前者。
于是就出现这种场景：三楼的 8306 空调坏了，前台在当天房态上标了维修，工程部也知道。但系统里远期房态仍然是可售的，等到下个月十五号，OTA 上这张单卖出去了，客人到店，前台才发现那间房还在等配件。
选住云管家八月批次的更新在远期房态上加了置维修功能，而且维修时间可以自定义填写，远期房态的每个房间都能加。
关键在"时段"而不是"状态"
只标当天维修
系统知道今天不能卖，但不知道要修到哪天。排房逻辑照样把远期房间放出去，靠人记、靠微信提醒。
标维修时段
从哪天到哪天不可售，写进远期房态。排房时自动跳过，不需要任何人记得这件事。
时段可以自定义这一点很实用，因为维修的周期差别很大：换个灯泡两小时，等空调配件十天，整体翻新两个月。前两种用同一套逻辑处理，后者其实是"封房"。
维修房的四种来源，处理方式不同
临时故障
灯泡、花洒、门锁电池。通常当天或次日解决，标一到两天。
等配件
空调主板、电视、热水器。周期不确定，标一个保守的时段，修好提前解除。
翻新改造
刷墙、换地毯、改卫生间。按月计，属于封房，不只要在房态上标，还要同步给渠道。
长期停用
整层楼改用途、房间结构问题。建议直接从可售房数里剔除，避免拉低出租率分母。
第三种和第四种最容易出事。房间在房态上标着维修，但 OTA 后台的可售库存没同步减，平台照样卖出去，客人到店无房——这类投诉在旺季特别集中，因为旺季每一间房都在被抢。
一个必须做的动作：维修时段一旦超过三天，就要同步到各渠道的库存。系统里的房态和 OTA 上的库存是两件事，前者改完不代表后者跟着改。批量封房的操作建议放在每周固定的一天做，形成习惯。
和"超售"的关系
很多人以为维修房和超售是两回事，其实是一回事的两面。
超售的常见原因有三个：退房延迟导致房态更新滞后、脏房未及时标脏、维修房未封。前两个靠操作规范，第三个靠系统机制。
远期房态置维修解决的是第三个。它让人在发现问题的那一刻就能把影响范围画出来，而不是等到排房时才想起来。
京津冀老楼改造的现实约束
河北的存量酒店里，2010 年前后开业的那批物业正赶上第一次大修周期：管道老化、外墙渗水、电梯换件。这类维修的特点是不可预测、影响面大——今天修 5 楼卫生间，明天可能整层停水。
在这种物业里做远期排房，建议留一手：
- 维修房比例：把总房量的 3%–5% 作为"随时可能不可售"的缓冲，排房时不用满
- 同房型冗余：同一房型至少留两间可替换，不要出现"这个房型只剩一间"的情况
- 旺季前普查：每年 5 月和 9 月做两次全房普查，把要修的提前标进远期房态
| 维修类型 | 建议标记时长 | 是否同步渠道 | 解除方式 |
|---|---|---|---|
| 灯泡 / 花洒 / 电池 | 1–2 天 | 否 | 修好即解除 |
| 等配件 | 7–15 天（保守） | 超过 3 天需同步 | 到货修好后提前解除 |
| 局部翻新 | 30–60 天 | 必须同步 | 按工期解除 |
| 长期停用 | 剔除出可售房 | 必须同步 | 重新启用时恢复 |
谁负责标、谁负责解
系统给了能力，流程得跟上。最容易出问题的是"没人解除"——房间早就修好了，系统里还标着维修，一间房白白空半个月。
建议明确一条：谁标的谁解除，工程部验收后当天解除。如果维修跨天，工程主管每天下班前花两分钟过一遍自己标的维修房，修好的解掉。
这两分钟省下的可能是几间房的收入。一间 300 元的房，多空三天就是近千元。