酒店里有一类事故最难查：房态改错了。
客人被排进一间还没打扫的房间，推门看到上一个客人留下的样子。前台说「系统里是净房」，客房说「我没点过净房」。两边都有道理，但事情已经发生了。
以前这种争执没有结论，因为系统里只记录「当前状态」，不记录「谁把它改成这样的」。
11 月批次新增的房态变更表解决的就是这件事：记录客房房态变更的全量明细，包括变更前、变更后房态，以及操作人、操作来源、操作时间。
五个字段各自的作用
| 字段 | 能回答的问题 |
|---|---|
| 变更前 / 变更后 | 这间房从什么状态变成了什么状态 |
| 操作人 | 是谁改的（账号维度） |
| 操作来源 | 从哪个端改的（前台 PC / APP / 自助机 / 系统自动） |
| 操作时间 | 什么时候改的 |
| 房号 | 哪一间 |
第三个字段「操作来源」是这张表最有价值的地方。同一个账号可能在手机和电脑上都登录过，来源能区分到底是哪个端做的操作。这在批量操作出错时特别有用——批量置净是从 APP 做的还是从 PC 做的，处理方式不一样。
三种典型的异常模式
模式一：批量置净后被打回
早上 7:40 一次性把 20 间房置净，8:20 其中 6 间又被置脏。说明置净的时候并没有真的扫完。
模式二：深夜频繁变更
凌晨两点到四点，同一间房的房态变了四五次。可能是系统自动逻辑在打架，也可能是有人在反复试。
模式三：一人改全楼
某个账号在一分钟内改了三十间房。正常操作不可能这么快，一定是批量功能被误用。
第一种模式最值得警惕。它说明批量置净被当成了「先点完再慢慢扫」，这是个流程问题，不是系统问题。但只有数据能证明它存在。
怎么用这张表查一次事故
第一步：定位房号与时间
客人投诉「房间没打扫」，先确认他的入住时间，锁定那间房在入住前两小时的变更记录。
第二步：看最后几次变更
谁在什么时候把它改成净房的。如果是客房员工在 7:40 批量置净、8:10 前台排房，中间只有半小时——那问题在流程，不在人。
第三步：看操作来源
如果是从 APP 批量操作，说明是「扫完一层点一层」的习惯没养成；如果是从 PC 端，可能是前台图省事。
第四步：改流程，不追责
查出来的结论如果是「流程允许提前点完」，那要改的是流程，不是骂人。
第四步是这个工具真正的价值所在。绝大多数房态错误不是员工不认真，是流程上允许他提前点完。这张表让「允许」这件事变得可见。
一个反过来的用法：这张表也能保护员工。员工被冤枉「把净房改成脏房」时，可以调记录自证。有了留痕，管理反而更公平。
数据量要注意
全量明细意味着记录很多。一家 80 间房的店，每天房态变更可能有几百条（含系统自动变更）。
按需查
出问题时按房号 + 日期查，几秒钟出结果。这是主要用法。
天天翻
每天把全量明细看一遍。数据量大、噪音多，看两天就放弃了。
合理的用法是每周抽查一次：随机挑 5 间房，看它们一周的变更记录。抽查比全看有效，因为抽查会形成「随时可能被查」的预期。
和房扫绩效的关系
这张表和房扫业绩能对上。房扫业绩看「扫了多少间」，房态变更表看「什么时候点的净房」。
两个数放在一起，能算出平均打扫时长：从置脏到置净之间的时间差。这个数比「扫了多少间」更能反映真实效率。
| 指标 | 算法 | 看什么 |
|---|---|---|
| 平均打扫时长 | 置净时间 − 置脏时间 | 效率趋势 |
| 异常短时长 | 低于 10 分钟的置净 | 可能是提前点完 |
| 打回率 | 置净后又被置脏的比例 | 打扫质量 |
第二行是关键。一间 25 平米的房，正常打扫要 20–30 分钟。如果系统里显示 8 分钟就置净了，那基本可以确定没扫完。
一个提醒
这张表上线后，第一件事不是查员工，是查自己。
先看一周的数据，回答三个问题：
- 我们店的房态平均多久更新一次
- 有没有「先点完再扫」的模式
- 批量操作被用得多不多
先看清现状，再谈改进。上来就拿这张表当监控工具，团队会立刻开始防着你，数据反而失真。