收益管理里有个反直觉的现象：周末明明天天满房，月底一算 RevPAR 却没涨多少。拆开看才发现，大量的"只住周五"或"只住周六"的零散单，把本可以连住两晚的客人挤掉了，还拉高了清扫和调换成本。
解决这类碎片化的工具，叫最少连住限制（Length of Stay，LoS）：在高峰段要求"至少住 N 晚"，把碎片需求重新拼成整块。
LoS 解决的是什么
碎片化
高峰里塞满单晚客，整块连住需求反而接不进，房量被切碎。
高变动成本
每多一次退房入住，就多一次清扫、布草、能耗与人工，单晚客更贵。
供需错配
热门夜被单晚客占满，想连住的客订不到，整体客单价上不去。
预测失真
看似满房，实际可售连住房被零散单吃掉，收益口径被误导。
什么时候该上 LoS
误用场景
- 平日也强设连住，把本来就不多的客推走
- 所有房型一刀切，商务短住客被误伤
- 节假日全程锁死，反而接不散客补位
合理使用
- 只在高满房预期的峰值夜启用
- 按房型分层，灵活房型可豁免
- 临近日期动态松绑，留出散客补位空间
落地三步走
1
看历史入住节奏
先弄清哪些夜是"被单晚客切碎"的高峰，再决定在哪几天上限制，而非凭感觉。
2
设阶梯而非铁板
峰值核心夜设连住两晚，周边夜放宽；越临近日期越灵活，避免空置。
3
配合渠道说明
在 OTA 与官网显著标注"该日期最少连住 N 晚"，减少下单后争议与取消。
一个提醒
LoS 是收益工具不是拒客工具。它的目的是把"能连住的客人"留下来，而不是把"只住一晚的客人"赶走——后者该用价格而非限制去引导。
LoS
最少连住控制
峰值
仅高峰启用
阶梯
非一刀切
临近
动态松绑