第 3 章 · 预计阅读 17 分钟
到店、房态与住中服务
系统显示有空房，为什么前台仍不能立刻给客人房卡？
前台要同时确认身份、担保、预订和真实净房状态，入住后再协调需求、维修和换房。
先放回整门生意
先知道这一章为什么存在
先把“到店、房态与住中服务”理解成一段有触发、有负责人、有记录、也有完成标准的业务，而不是一组部门名词。
上一章“预订、担保与到店准备”应先形成：订单要经过渠道传递、酒店确认、担保核验和到店前检查，才能成为可履行承诺。
本章把“前台要同时确认身份、担保、预订和真实净房状态，入住后再协调需求、维修和换房。”从一句目标变成可执行、可交接、可核验的工作。
结果将交给下一章“退房、对账与收益复盘”：要把房费、附加消费、押金退款、渠道代收和支付流水核对后，营业日才能关闭。
- 收入怎么受影响
- 大理风起二十四间酒店管理有限公司通过客房房晚、早餐与接送和延迟退房或房型升级收费。本章形成的“闭环的住中服务”要和“入住登记、房卡和房账”、“清扫、查房和维修记录”和“宾客需求、投诉与补偿记录”一起核对，才能继续判断验收、结算或后续经营；现金时点按以下规则判断：直订在预订或退房时收款，OTA 通常在离店后 7—15 天结算；租金、人工和维护不随入住率同步下降。
- 风险在哪里出现
- 全程要警惕“空置率、超售、卫生安全、渠道依赖和价格失控”。本章至少要用“入住登记、房卡和房账”、“清扫、查房和维修记录”和“宾客需求、投诉与补偿记录”留下可追溯证据。
读完这一章，你应该能自己解释
- 能用自己的话解释“系统显示有空房，为什么前台仍不能立刻给客人房卡？”，并说出它为什么会影响客户价值或经营结果。
- 能按依赖顺序还原3个业务步骤，并指出每一步的负责人、记录和交接物。
- 能区分业务流、钱流、信息流和责任流，不把“做过动作”误当成“完成交付”。
- 遇到相似情境时，能用“产出是否形成、证据能否核对、风险是否受控”作出判断。
先建立业务直觉
可售库存最终要落到一间真实可住房
系统房态若落后于清扫或维修现场，就会把脏房或故障房分给客人。前厅和客房必须通过明确状态和交接记录保持一致。
把它放进大理风起二十四间酒店管理有限公司的经营现场：本章只聚焦“到店、房态与住中服务”这一环，追踪它怎样承接已有输入，并把“前台要同时确认身份、担保、预订和真实净房状态，入住后再协调需求、维修和换房”变成可以执行和复核的工作。
本章从“核验并办理入住”开始，依次经过“核验并办理入住”、“清扫、检查与更新房态”和“处理住中需求与异常”，最后得到“闭环的住中服务”。判断是否完成，要把动作、产出、业务记录和下一位接手者放在一起核对。
至少同时满足三件事：产出“闭环的住中服务”；关键记录“入住登记、房卡和房账”、“清扫、查房和维修记录”和“宾客需求、投诉与补偿记录”可以相互核对；相关负责人清楚下一步由谁接手。
完整案例推演
跟着大理风起二十四间酒店管理有限公司，把“到店、房态与住中服务”完整跑一遍
现在把镜头放到大理风起二十四间酒店管理有限公司的“到店、房态与住中服务”：系统显示有空房，为什么前台仍不能立刻给客人房卡？ 先读下面的经营底账，后续每一步都会复用这些数字与约束。
贯穿全课的虚构案例
大理风起二十四间酒店管理有限公司
一家 24 间客房的精品客栈按日期销售房晚，空着过去的房间无法留到未来再卖，还要协调渠道、清洁和现场服务。
- 月可售房晚
- 720 间夜24 间房乘 30 天形成当月容量；每个未售房晚在当天结束后永久失效。
- 月入住率
- 70%售出 504 间夜，平均房价 360 元，房费收入约 18.144 万元。
- 渠道获客成本
- 约 1.225 万元45% 房晚来自 OTA，按这部分房费的 15% 支付佣金；渠道带来客人，也会侵蚀房价收入。
- 月经营贡献
- 约 4.3 万元房费扣除每间夜 42 元清洁布草、渠道佣金和约 10.5 万元租金人工水电后所得，尚未覆盖装修折旧和税费。
客户为什么付钱
客房房晚、早餐与接送、延迟退房或房型升级
钱在什么时候进来
直订在预订或退房时收款，OTA 通常在离店后 7—15 天结算；租金、人工和维护不随入住率同步下降。
利润最容易被什么吃掉
租金与装修折旧、前台和客房人工、清洁布草、OTA 佣金、空置与超售处理
这笔业务怎样一步一步形成可交付结果
- 01核验并办理入住合法且可入住的住客状态
- 02清扫、检查与更新房态与现场一致的可售房态
- 03处理住中需求与异常闭环的住中服务
核验并办理入住
在大理风起二十四间酒店管理有限公司，团队先面对一条共同事实：“月可售房晚”为720 间夜。24 间房乘 30 天形成当月容量；每个未售房晚在当天结束后永久失效。
核对身份、预订、担保和入住人数，确认可售净房后分房并建立房账。
这一步真正要判断：复核身份、担保、分房与房卡；确认日期、房型、入住人和取消条件
如果本步没有形成“合法且可入住的住客状态”，下一步“清扫、检查与更新房态”就没有可靠输入。
- 谁在参与
- 前厅主管、住客／预订人
- 关键记录
- 入住登记、房卡和房账
- 形成产出
- 合法且可入住的住客状态
- 交给下一步
- 把“合法且可入住的住客状态”交给客房主管和前厅主管，继续处理“清扫、检查与更新房态”。
如果没做好：如果前厅主管没有复核身份、担保、分房与房卡，或者没有留下“入住登记、房卡和房账”，即使动作已经做过，下一步也无法确认“合法且可入住的住客状态”是否可靠。
清扫、检查与更新房态
上一步已经形成“合法且可入住的住客状态”。与此同时，案例里的“月入住率”为70%，售出 504 间夜，平均房价 360 元，房费收入约 18.144 万元。
客房按优先级清扫，检查卫生与设施，将维修问题封房并及时更新系统。
这一步真正要判断：安排清扫、查房和维修封房；复核身份、担保、分房与房卡
如果本步没有形成“与现场一致的可售房态”，下一步“处理住中需求与异常”就没有可靠输入。
- 谁在参与
- 客房主管、前厅主管
- 关键记录
- 清扫、查房和维修记录
- 形成产出
- 与现场一致的可售房态
- 交给下一步
- 把“与现场一致的可售房态”交给宾客关系专员、住客／预订人和前厅主管，继续处理“处理住中需求与异常”。
如果没做好：如果客房主管没有安排清扫、查房和维修封房，或者没有留下“清扫、查房和维修记录”，即使动作已经做过，下一步也无法确认“与现场一致的可售房态”是否可靠。
处理住中需求与异常
上一步已经形成“与现场一致的可售房态”。与此同时，案例里的“渠道获客成本”为约 1.225 万元，45% 房晚来自 OTA，按这部分房费的 15% 支付佣金；渠道带来客人，也会侵蚀房价收入。
记录噪音、维修、换房或投诉，协调部门响应并按授权提供补救。
这一步真正要判断：记录需求并协调响应；确认日期、房型、入住人和取消条件；复核身份、担保、分房与房卡
这是本章最后一项可核验产出，用来判断团队是否真的完成了“到店、房态与住中服务”。
- 谁在参与
- 宾客关系专员、住客／预订人、前厅主管
- 关键记录
- 宾客需求、投诉与补偿记录
- 形成产出
- 闭环的住中服务
- 交给下一步
- 把“闭环的住中服务”作为本章完成证据，交给下一章节继续使用。
如果没做好：如果宾客关系专员没有记录需求并协调响应，或者没有留下“宾客需求、投诉与补偿记录”，即使动作已经做过，下一步也无法确认“闭环的住中服务”是否可靠。
案例结束时，不是因为所有人都完成了自己的动作就算成功，而是因为“闭环的住中服务”已经形成、证据可以追溯，并且宾客关系专员、住客／预订人和前厅主管能够解释结果怎样产生、风险怎样被控制。前台要同时确认身份、担保、预订和真实净房状态，入住后再协调需求、维修和换房。
换一个视角再看
同一笔业务，同时跑着四条线
业务流说明事情怎样发生，钱流解释收入、成本与现金，信息流留下共同事实，责任流决定谁执行、谁确认、谁承担后果。点击切换，观察同一章节怎样变化。
围绕“系统显示有空房，为什么前台仍不能立刻给客人房卡？”，业务必须按依赖关系推进，不能把一串并行任务误当成已经交付。
- 01
核验并办理入住 → 合法且可入住的住客状态
- 02
清扫、检查与更新房态 → 与现场一致的可售房态
- 03
处理住中需求与异常 → 闭环的住中服务
出现这个信号要警惕：如果前厅主管没有复核身份、担保、分房与房卡，或者没有留下“入住登记、房卡和房账”，即使动作已经做过，下一步也无法确认“合法且可入住的住客状态”是否可靠。
岗位、记录与业务语言
一家公司靠什么把多人协作变成同一个结果
岗位不是孤立的名称，记录也不是多余的表格。前者分配判断与责任，后者让不同人能够核对同一件事是否真的发生。
谁负责什么，结果交给谁
| 角色 | 本章负责 | 最关心 | 交给谁 |
|---|---|---|---|
| 业务职能前厅与客房运营 | 提供本章所需的约束、输入或审批 | 把预订、真实房态、入住和清洁维护衔接起来；重点关注：办理入住、分房、换房和退房 | 下一章节或业务结果的接收方 |
| 业务职能宾客服务与经营对账 | 提供本章所需的约束、输入或审批 | 解决住中问题、归集消费并完成每日收入核对；重点关注：记录并闭环住客需求与投诉 | 下一章节或业务结果的接收方 |
| 业务职能预订与销售 | 提供本章所需的约束、输入或审批 | 接收、核验和修改来自直销与平台的订房请求；重点关注：确认房型、日期、价格、担保和取消条件 | 下一章节或业务结果的接收方 |
| 外部参与者住客／预订人 | 核验并办理入住、处理住中需求与异常 | 选择住宿条件、提供入住信息并支付或担保费用；重点关注：确认日期、房型、入住人和取消条件 | 客房主管、前厅主管 |
| 代表岗位前厅主管 | 核验并办理入住、清扫、检查与更新房态、处理住中需求与异常 | 协调住客到店、房间分配和现场异常；重点关注：复核身份、担保、分房与房卡 | 客房主管、宾客关系专员、住客／预订人 |
| 代表岗位客房主管 | 清扫、检查与更新房态 | 确保房间真实状态与系统记录一致；重点关注：安排清扫、查房和维修封房 | 宾客关系专员、住客／预订人、前厅主管 |
| 代表岗位宾客关系专员 | 处理住中需求与异常 | 在住宿期间协调需求、补救和服务反馈；重点关注：记录需求并协调响应 | 下一章节或业务结果的接收方 |
哪些记录能证明业务真的发生了
| 业务记录 | 在哪产生 | 谁形成 | 证明什么 | 下一步怎么用 |
|---|---|---|---|---|
| 入住登记、房卡和房账 | 核验并办理入住 | 前厅主管和住客／预订人 | 合法且可入住的住客状态 | 清扫、检查与更新房态 |
| 清扫、查房和维修记录 | 清扫、检查与更新房态 | 客房主管和前厅主管 | 与现场一致的可售房态 | 处理住中需求与异常 |
| 宾客需求、投诉与补偿记录 | 处理住中需求与异常 | 宾客关系专员、住客／预订人和前厅主管 | 闭环的住中服务 | 判断本章是否完成并进入下一章节 |
本章术语：先用白话理解，再回到正式定义
- 业务术语房态
- 白话：房间现在有人住、待打扫、已查好还是坏了不能卖。
- 正式定义：一间房在系统中的占用、清洁、检查、维修和可售状态。
- 放进业务里：客人退房后先变为脏房，清扫查房完成才转为可售净房。
- Folio宾客账单／房账
- 白话：这位客人在酒店发生了哪些费用、付了多少、还差多少。
- 正式定义：记录某次住宿房费、餐饮、押金、调整和支付的明细账户。
- 放进业务里：房费由公司结算，迷你吧由住客个人支付，可拆分到不同账窗。
- 业务术语担保预订
- 白话：酒店为晚到客人留房，客人也承担约定未到店费用。
- 正式定义：客人以预授权、预付或信用承诺保证酒店保留房间的预订。
- 放进业务里：信用卡担保订单可保留至深夜，未到店按取消条款收费。
新手最容易误解的地方
可以，只要口头说清扫过
为什么不对：房态必须由可追溯的检查与系统状态共同确认。
应该继续追问：如果改成“不能，应完成查房和系统房态确认后再分房”，需要谁确认、留下什么证据？
“核验并办理入住”只要动作做完，就可以直接进入下一步。
为什么不对：如果前厅主管没有复核身份、担保、分房与房卡，或者没有留下“入住登记、房卡和房账”，即使动作已经做过，下一步也无法确认“合法且可入住的住客状态”是否可靠。
应该继续追问：是否已经形成“合法且可入住的住客状态”，并留下“入住登记、房卡和房账”供下一步核对？
“清扫、检查与更新房态”只要动作做完，就可以直接进入下一步。
为什么不对：如果客房主管没有安排清扫、查房和维修封房，或者没有留下“清扫、查房和维修记录”，即使动作已经做过，下一步也无法确认“与现场一致的可售房态”是否可靠。
应该继续追问：是否已经形成“与现场一致的可售房态”，并留下“清扫、查房和维修记录”供下一步核对？
先复盘，再做判断
现在，试着不用页面原话把这一章讲出来
- 为什么本章必须先做“核验并办理入住”，如果跳过会影响哪一步？
- 在“清扫、检查与更新房态”中，谁执行、谁提供约束，应该留下什么记录？
- 本章怎样影响客房房晚、早餐与接送和延迟退房或房型升级？结合“直订在预订或退房时收款，OTA 通常在离店后 7—15 天结算；租金、人工和维护不随入住率同步下降。”判断它何时才会形成收入或现金。
- 如果只看到“闭环的住中服务”的口头结论，你还会要求核对哪些业务记录？
客房说已清扫，但系统仍是脏房，前台赶时间能直接发房卡吗？
住客正在等待。