报修之后，怎么确认这间房已经不可售？先看首页维修房数，再对房情表和房态日历

发现设施问题，先处理，再决定这间房还卖不卖

行业里处理设施故障的顺序很清楚：发现设施或卫生问题时先处理，再决定是否继续售卖对应房源。旺季前的运营检查，也应把客房卫生、设施可用性和当前可售状态一起覆盖，并明确检查责任人与频率。

如果旺季遇到突发性房源减少，例如漏水、设备故障导致维修房增加，行业实践是优先保障已预订客人的房间分配，再考虑超额预订客人的安置。顺序处理错了，损失的不只是一晚收入，还可能损伤品牌声誉。

第一眼：从首页工作台看维修房数

每天开工的第一屏，路客云 SPMS 首页工作台把今日房态与经营的关键数字放在上方一排，其中包括预抵、在住、预离、可售、维修房、脏房、异常和总营业收入；维修房数与可售、脏房等并列显示，方便经营者日常扫一眼，先判断当天哪些房处于非可售状态。这些数字按当前门店或账户汇总，并会随昨日/本月、本周/上周等切换变化。

看到维修房数抬头，经营者接下来要问的是：增加的是哪些房型、哪几间，以及它们有没有真正进入不可售。首页提供的是快速总览与快捷入口，要把数量账和具体房间逐条对上，还要继续看房情表和房态日历。

首页经营看板

对账：房情表里维修房和总可用房怎么算

房情表把全店房间的“数量账”一屏摊开：按房型逐行，给出总房间数、已售、剩余可售、总关房，以及停用、保留、维修、联动关房等各类关房，再给出总可用房。来源中的口径是，总可用房等于总房间数扣除各类关房后可用于销售的房间数；剩余可售数小于总房间数，是因为已售和各类关房都被扣掉了。

产品资料还提到，路客云 PC 端升级包含房情、维修房、夜审、经营数据等数据模块。落到这张表上，想判断某房型今天还能放多少，看剩余可售数；想确认一间故障房有没有被算进不可售，就看它所在房型的维修房或停用房，以及总可用房是否相应变化。

如果故障房仍留在可售里，渠道就可能继续卖；这时要回到房态侧确认是否做了关房或停用，而不是只看首页维修房总数。

单日房情表

落到具体房间：日房态看关房统计，月房态看“停用”

日房态把全店房间按房型分组平铺，每张房间卡片显示房间号和房型名；右侧“房态”统计里有关房数，被关闭、不可售的房间计入其中，不进入可售。

月房态换成日期×房型的跨天网格，表头每一列是日期并标出“余N间”，表示该门店当日总可售量；房型行在各日期格显示剩余可售数。某个房间某一天被停用，会标为橙色的“停用”、不可售；“售罄”则是该房型该日已无余房。两者都不进入可售，但原因不同。

对一间已知故障房，日房态回答的是“它是否处于关房”，月房态回答的是“它在哪几天被停用”。经营者至少要在故障影响到的日期上核对它不再显示为可售，再决定预订与排房怎么调整。

日房态一屏总览

月房态跨天可售

恢复之后：用房态日志核对谁在什么时候改了什么

恢复或恢复前的每一次变动，可以到房态日志里追溯。房态日志把每一次房态/库存变动记下来，表格列出房型、房间、房态调整日期、操作内容、调整方式、同步渠道、渠道库存变更、操作人、操作时间。一条记录能回答：哪间房、哪天的房态被改，改了什么，是手动调整还是系统触发，是否同步到渠道，渠道库存怎么变，谁在什么时候操作。

房态日志是只读审计，只记录、不改动房态；发生过房态/库存调整才有记录，没有变动时列表为空。

对本次维修，处理完成后可以按房型、房间或调整方式定位这次变动，核对操作内容、同步渠道与渠道库存变更，判断线上渠道库存是否同步到位。至于这间房是否马上恢复销售，还要结合当日房况、后续预订和实际处理结果决定。

房态日志

工具给的是可核对的视线，流程仍需各店自己定

行业经验里，退房后的保洁调度、设施报修的分派与完成确认，是影响客房周转速度的关键环节，做法是建立明确的触发标准与责任分工；保洁与维修任务的自动化，也取决于作业流程能否被拆成可枚举、可验证的状态节点。

智能维修工单的行业最佳实践，是记录报修、接单、完成三个时间节点，用这些数据发现哪类问题最频发、哪些房间维修间隔最短、哪些维修人员响应最慢，进而做出设备更换和人员调整的决策。

本文依据的能力只回答到“关房是否进入不可售、恢复是否有记录可查”这一层。什么算处理完毕、谁负责逐条核查日志、是否需要把报修、接单、完成都纳入考核，仍要按各店自己的分工和现有工具来确定。