客房与布草：房态一眼清，翻房有闭环

客房这门生意，卡在三个"看不见"上

不管是三十间房的民宿，还是一百多间房的连锁酒店，前台和客房部每天打的仗都很像：

• 房态看不见。 哪个房间住了人、哪个已经退房待清扫、哪个马桶漏水在等维修，全靠前台脑子里的那张表和对讲机。交接班时说不清，保洁在走廊里一间间敲门找活干，客人提前到店却发现房间还没翻好。
• 翻房看不见。 退房之后那四十分钟最关键：谁去扫、什么时候扫完、主管验收了没有。这些环节没有记录，出了问题只能凭印象追责；周末满房时到底哪几间拖慢了，事后也说不清。
• 布草看不见。 床单、被套、毛巾、牙具拖鞋，每次翻房换了几件、这个月耗了多少、报损了多少，多数靠仓库发一堆、月底点一次。差额去了哪里，谁也说不清，成本就摊在毛利里。

三件事的共同点是：过程没有留在系统里。下面这套搭法不追求做一套完整的酒店 PMS，只把"房、单、物、修"四件事记清楚——房态有流水、翻房有任务、耗用有登记、报修有闭环，再用页面和手机端把它们用起来。

第一步：底表怎么建——先定"房态到底记在哪"

这是整套模块最关键的一个设计决定，值得在动手前想清楚。

房间档案（主数据）

• 房号（唯一标识）、楼栋与楼层、房型、可住人数、床型、朝向/备注
• 当前房态字段：住客中、空净（可售）、待清扫、维修中、停用
• 房间标签：无烟房、可加床、相邻房等，方便前台调配

房态流水（只增不改的记录）

• 每次房态变化记一条：房号（引用房间档案）、原状态、新状态、变更时间、变更人、关联的住宿批次（哪一单客人）、备注
• 这张表只增不改：状态改错了，不是回头改记录，而是再记一条正确的变更

为什么要两张表而不是只看一个状态字段？因为两者的用途不一样。

• 房间档案上的当前房态是给房态板看的，要快，要一眼扫到；
• 房态流水是给"追"用的：这间房今天几点退的、几点扫完、谁验收的、中间被谁挂成维修中——这些都要能查。翻房时长、房态异常、每日可用房变化，全部从流水算出来，不需要再让谁去填报表。

这也是搭这类模块的通用经验：当前值放主档，变化过程放流水。把两者混在一张表里（比如一条记录既存当前状态又存历史），通常会越用越乱。

住宿批次（客人在店的这一段）

• 关联订单号（或渠道单号，手填或引用本企业已有订单模块）、入住人、人数、入住日期、预离日期、实际退房时间
• 一个房间可以先后有多个住宿批次，一个批次也可能占两个房间

有了住宿批次这条线，"这间房这次住的是哪拨客人、换了多少布草"才有地方挂，而不是把客人名字直接写在耗用记录里。

顺带两个省事的平台能力：

• 下拉选项统一口径：房型、房态、布草品项、报修类型这类"选项有限"的字段，用平台的 数据字典 集中维护。以后加一个新布草品项，改一处、所有页面同步生效，不会出现"浴巾/浴巾条/大毛巾"三种写法各占一行。
• 跨模块引用：保洁任务、报修单、耗用记录里的房号，走平台的引用引擎（一种软外键机制，让一个模块直接引用另一个模块的档案数据源，不用把房号再抄一遍）。房间改号或调整房型，历史单据上显示的仍是同一间房，追溯不会断。住宿批次关联的订单，如果本企业已有销售或订单模块，也是同一个引用方式接过来。

第二步：另外三张表，把翻房和耗用接住

保洁任务（翻房的执行单据）

• 房号（引用房间档案）、任务类型：退房清扫、续住整理、深度保洁、计划保养
• 来源：由退房动作自动生成，或主管手工补单
• 要求完成时间（比如退房后 40 分钟内）、指派给谁、实际开始与完成时间
• 结果：完成 / 待返工 / 房间被挂维修中，附完工照片
• 验收：验收人、验收时间、验收结论

设计上有个细节值得先定：保洁任务不要和房态流水合并。任务讲"谁在什么时限内干了活"，房态流水讲"房间现在是什么状态"，一次退房会同时产生一条任务和一条房态变更，分开记才既能排班又能对账。

布草与易耗品耗用记录

• 品项（引用品项档案：床单、被套、毛巾、浴巾、牙具、拖鞋、矿泉水等）、类型：布草 / 易耗品
• 关联房号与住宿批次、登记时间、登记人
• 动作类型：更换、补充、报损；数量
• 备注（如"客人反映被套有污渍，已换新"）

这里容易踩坑的是把"这次用了多少"和"仓库还剩多少"写进同一张表。建议拆开：

• 耗用记录只负责"这间房这次换了几件"，一张房次一条，只增不改；
• 结存交给库存那一侧——如果企业已有通用库存模块，直接引用；没有的话，可参照 通用库存管理 那套入库、出库、盘点的思路另建一张出入库表来承接。

这样一来，月底要的"耗了多少"从耗用记录按品项加总，"仓里还剩多少"从出入库表看，两个问题各有各的答案，不用互相迁就。

报修单（房间设施的问题单）

• 房号、故障类型（水电、空调、卫浴、门锁、家具、网络等）、报修人（前台 / 保洁 / 住客）、报修时间
• 状态线：待接单 → 处理中 → 已完成；旁路出口：转外修、暂不修理（房间挂停用）
• 处理人、完工时间、使用材料、完工照片、验收人

报修必须和房态联动，这是本文最想强调的一条规则：

报修单建立时，房间房态自动置为"维修中"；维修完工后，房间回到"待清扫"，而不是直接回到"空净"。

为什么不让它直接变"可售"？因为修完的房间通常是脏的（师傅进去拆过面板、踩过地），跳过清扫就把房卖给客人，是最容易招致投诉的一类失误。这条规则在系统里用数据流规则配出来（下一节），人就不用记了。

第三步：按角色分页面，别让所有人对着一张表

底表建好只是地基，日常用的是页面。同一个模块，四个角色看到的东西应该完全不一样。

前台：房态板

• 按楼层分组的房态板，每间房一张卡片，颜色区分住客中 / 空净 / 待清扫 / 维修中
• 卡片上直接显示：住客姓名（或"空"）、预离日期、上一次房态变更时间
• 一键改房态：办理入住置"住客中"，退房置"待清扫"——点了就生成保洁任务
• 待办侧栏：今日预抵、今日预离、待清扫超时的房间

客房主管：任务与验收

• 今日保洁任务列表，按要求完成时间排序，超过时限未完成的整行高亮
• 批量指派：选一批待清扫任务，分给某位保洁员
• 验收区：保洁提交完成后进入待验收，主管看照片、点通过或返工
• 布草耗用日报：今日各品项耗用与报损数量，异常行（比如某间房一次报损 5 条毛巾）单独标出

工程部：报修工单池

• 待接单列表按房间和故障类型筛选，接单即置处理中
• 完工时上传照片、登记材料，提交后房间自动转"待清扫"
• 转外修的单据单独一个页签，跟进外部维修单位

店长/管理层：三张日报

• 翻房效率：按天统计退房到清扫完成的平均时长、超时任务数（数据来自房态流水与保洁任务，不需要额外填报）
• 布草成本：按品项、按月汇总耗用与报损数量，看哪一类消耗异常
• 房间可用性：每天有多少间因维修或停用不可售，报修平均响应与完工时长

需要提醒的是：这些指标是"算得出来的口径"，不是行业基准。系统负责不漏记、可汇总、可追溯，具体到多少分钟算合格，得由各店按自己的房量和服务标准来定。

第四步：四类自动化，把重复动作交给系统

模块搭完之后，最值钱的一步是把"人记得住"的事情变成"系统会做"的事情。这套客房管理可以配四类：

1. 数据流规则（条件触发的数据变换）

• 住宿批次登记实际退房时间 → 房态置"待清扫" + 自动生成一条退房清扫任务，指派到当班保洁组
• 报修单建立 → 房态置"维修中"；报修完工 → 房态转"待清扫"
• 保洁任务标记完成并通过验收 → 房态转"空净"，进入可售池

数据流规则的好处是规则只有一处：以后想把"退房后必须主管确认才可售"加进去，改这一条规则就行，不用培训每个人记住新流程。

2. 定时任务（按 Cron 定期执行）

• 每天早上生成当日预抵预离清单，推给前台当班人
• 每 30 分钟扫一次保洁任务，把超过要求完成时间仍未完成的挑出来提醒主管
• 报修单超过约定时长未完工，每天升一级提醒（具体时长按企业自己的服务承诺定）
• 月末最后一天提醒做布草盘点

定时任务留执行记录——上一次跑成功没有、挑出了多少条，都可以回查。上线时建议先手动触发一次，看清楚它生成了什么，再交给时间表。

3. 通知

• 任务指派、超时未完成、报修完工待验收，各推一条给对应的人
• 通知走平台的站内信通道，手机端也能收到，不用再建一个群发指令的群

4. 审批流（不是所有事都要审批，但这几件建议要）

• 布草报损超过一定数量，需主管确认——避免报损成为耗用的黑洞
• 房间长期停用（大修、改造）需店长确认，因为直接影响可售房量
• 房间免单、延迟退房超出规定时长，走审批留痕

审批走平台的工作流机制，"谁在什么条件下做什么"是配置出来的，后面调整审批人不需要重做页面。

另外两项建议一并配好：审计日志会记录关键数据的改动（谁在什么时候改了房态、改了耗用数量），出问题时能对上账，具体用法见 AI 监控与审计日志；角色与权限则决定保洁员看不到布草成本、前台不能删任务，配置思路见 角色与权限配置。

第五步：移动端——翻房的人不在电脑前

客房这门业务，真正干活的人几乎全天在走廊里。所以这套模块能不能用起来，关键看手机端好不好使。平台的一个省心之处是：PC 上用 AI 构建器搭好的模块，会自动出现在移动端，不用为手机另做一套（机制与使用细节见 移动端使用指南）。

保洁员（手机）

• 打开就是"我的任务"：房号、任务类型、剩余时间，按紧急程度排好
• 一键开始 / 完成，完成后拍一张房间照片提交
• 发现设施故障，就地开一张报修单——不用回办公室说，也不用等主管转达
• 布草耗用就地登记：选品项、填数量，几秒钟一条

前台（手机或电脑）

• 随时随地查房态板，客人提前到店时直接看哪间房空了
• 改房态、登记住客需求（加床、送水、延迟退房）
• 收到超时提醒后当场催办

客房主管与工程部（手机）

• 主管在手机上验收、返工、临时改派
• 工程部收到报修提醒，接单、完工、拍照上传

权限在这里的作用很实在：保洁员只看到派给自己的任务，看不到房价和成本；前台能改房态但不能删改历史流水。这套隔离配好，手机才敢发给一线员工用。

上线前，这几件事先查一遍

1. 房态流转规则是不是闭环：五个状态（住客中 / 空净 / 待清扫 / 维修中 / 停用）每条都有出口吗？维修完工是不是回到"待清扫"？停用的房间能不能被前台误卖？
2. 双轨跑几天：上线第一周，纸质或对讲机的老办法别急着停，每天收工前和系统对一次房态。对不上的地方，通常是状态规则没覆盖到的死角。
3. 字典是否统一：房型、房态、布草品项、报修类型是不是都从数据字典取，没有手输的口子？
4. 引用关系对不对：保洁任务、报修单、耗用记录里的房号走的是引用吗？房间改号后历史单据会不会跟着变？
5. 权限逐个角色验一遍：用保洁、前台、主管、工程四个账号各登录一次，确认该看见的看见了、不该点的点不了。
6. 移动端菜单挂好：保洁员能不能在手机上找到"我的任务"，房态板在手机竖屏下是不是还看得清。
7. 自动规则手动验一遍：退房 → 生成任务 → 完成验收 → 房态变可售，这条链路手工跑两次；报修建单 → 房态转维修 → 完工转待清扫，也跑一次。
8. 定时任务先手动触发：确认它挑出来的清单真的是想提醒的那些，再交给时间表。
9. 发布预检跑一遍：用平台的模块测试与发布流程把配置问题在上线前挑出来，步骤见 模块的测试与发布。

之后可以怎么延伸

这套骨架搭好，后续需求多数能顺着长出来：

• 客房消费挂账：迷你吧、洗衣、加床这些消费记到住宿批次上，退房时一单结清
• 布草洗涤外包对账：洗涤厂的送洗与送回数量按批次登记，月度对账有据
• 多店 / 多楼栋：加一个门店或楼栋字段，同一套页面切换看不同物业的房态板，适合连锁或"民宿 + 自营公寓"混合经营
• 设施报修与外部维修协同：房间报修单里"转外修"的那部分，与 物业报修 那条链路的思路相通，可以互相参照着改
• 保洁员工作量统计：从任务记录里出每人每日完成间数与返工率，作为排班与激励的参考

这套方案不做什么

写清边界，比列功能更有用：

• 不是完整的酒店 PMS：不涉及房价策略、渠道分销、OTA 直连、账务日结这些专业模块。有这类需求，本模块适合作为客房执行层的补充，而不是替代。
• 不做硬件对接：门锁、房控、门牌灯这些设备联动不在 AI 构建器的交付范围内，房态仍由人在页面或手机上变更。
• 指标只反映系统里记录的事实：翻房时长、报修响应这些数字，取决于一线是否按实操作登记；它们适合作为内部管理依据，不适合直接写进对客服务承诺。

把房态、任务、耗用、报修这四本账先用起来，客房部每天的忙乱就会少掉一大半：客人问房，前台看板就有答案；主管问进度，列表里就有；老板问布草花了多少，报表里就有。这就是"能开发出来的业务模块"和"买一套大系统"的区别——从一个最痛的墙面开始，用起来，再往上长。