客房部每天开工的第一件事，是把昨晚空着的房间标成净房。
听起来是个小动作，实际耗时不小：一栋楼二十间空房，在 APP 上要一间一间点开、选状态、确认，二十次点击、二十次等待。如果分三个楼层，就是六十次。这些时间不产生任何价值，但必须有人做完，否则前台不敢卖房。
选住云管家八月批次的更新把这件事改成了批量操作：APP 实时房态批量操作模式新增「置净」「置脏」入口，对齐前台 PC 端的业务规则，支持房间卡片勾选式选择，单批次最多 20 个房间。
三条规则值得记住
单批上限 20 间
不是无限勾选。分楼层操作更稳妥，一栋楼一次刚好。
业务规则对齐 PC 端
和前台电脑上的批量操作走同一套判断，不会出现"手机能改、电脑不能改"的情况。
勾选式而非全选
要一间间勾。这是有意的——防止手滑把整栋楼都置净。
第三条其实是个防错设计。全选看着更快，但客房部最常见的错误就是"以为这层都扫完了"。强制勾选让人必须看一眼房号，误操作的概率会低很多。
省下来的是哪段时间
逐间操作
20 间 × （点开 + 选状态 + 确认）≈ 3–5 分钟。若有 3 层，10 分钟以上。这段时间客房主管没法去巡楼。
批量操作
1 次勾选 20 间 + 1 次确认 ≈ 15–20 秒。省下的不是十分钟，是主管早上的整块注意力。
这里要说清楚：真正值钱的不是那几分钟，而是这几分多钟原本是碎片化的打断。主管一边点房态一边接前台电话一边回答员工问题，注意力被切成三块，早上最容易出错的就是这种状态。
置脏的用处可能更大
置净是常规操作，置脏反而容易被忽略。
场景：客人早上退了房，房务还没上去，前台已经把房间标成脏房——这一步现在是逐间的。如果遇到团队集中退房（20 间同时走），逐间置脏要花好几分钟，中间这段时间系统里这些房间还是"净房"状态，晚到的散客可能被排进去。
批量置脏之后，团队退房的第一时间就能把整批房间标脏，房态和现实对齐，不会出现"客人被排进正在打扫的房间"这种尴尬。
团队退房在京津冀的商务酒店里非常集中——早上七点半到九点，一整层楼的客人几乎同时下楼吃早饭然后退房。这个时段的房态准确性，直接影响上午的散客入住体验。
和另外两条更新的配合
八月批次里还有两条和房态相关：
拖动换房支持当天在住的和预订的拖拽换房。预订单换房原本只能换预订单，现在可以把今天入住的预订单和今天已入住的在住单互相拖动换房。APP 同步支持。
这条解决的是"到店后想换房"的场景。客人下午到店，前台发现给他排的房间朝北，想换到朝南那间——但那间现在有客人住着，明天走。以前要在两个模块里分别操作，现在直接拖动。
实时房态单酒店界面优化。顶部经营指标布局和入住人字段展示做了调整。
单店界面的信息密度一直是难点：房间数、在住、待排、待扫、维修，五六个指标挤在顶部。优化之后指标层级更清楚，扫一眼能拿到关键数。
落地时的两个注意
权限要配好
批量置净置脏属于会改房态的操作，建议只开给客房主管和值班经理，普通房务员仍用单间操作。
批量不等于免检查
一次点 20 间的前提是这 20 间真的扫完了。建议保留"扫完一层、点一层"的习惯，而不是收工前一次性点完。
工具让操作变快，但房态的准确性最终取决于现场有没有真的做完。批量操作如果被用来"提前点完再慢慢扫"，那就是把问题藏起来了——脏房会以净房的身份被卖出去，客人推门进去看到的还是上一个客人留下的样子。
这类事故在中小酒店并不少见，多数不是因为员工偷懒，而是因为流程上允许他先点完再扫。系统的默认行为，最好和正确的做法一致。