库存与限制条件战术
一句话导语：价格决定「一个房间能卖多少钱」，库存决定「您到底还剩几个房间能卖」——后者一旦出错，前者做得再漂亮也没有意义。本模块把《法典》表 B（库存与限制条件配置）、表 E（超额预订）、表 J（免费升级）、表 L 超售过度分支（步行客人预案）四张表讲透，并用一个专章讲「撤除机制」——真实工作中最高频、也最致命的事故，不是设错限制条件，而是设对了却忘了撤。
- 能完整默写并套用《法典》表 B（5 行 × 4 列）与表 E（6 档基准超售率 + 4 个修正系数 + 3 条硬上限），并按三步法独立算出任意目标日的超售上限
- 能说出 MinLOS / MaxLOS / CTA / CTD / Stop Sell 五种限制条件各自的定义、启用时机、副作用、设置方法与撤除方法，并逐字背出「限制条件撤除五步法」
- 能独立执行 超售的房型级分配（套房不参与超售、最大余数法补齐），以及在超售开启日的三项配套准备（备用酒店名单、补偿包、升级台账）
- 能完整执行《法典》表 J 的免费升级四级排序（钻石>铂金>金卡>银卡 → 同档价高者先 → 同价住得久者先 → 同者复购多者先），并正确适用「最多升 1 档、套房每日 ≤3 间且须 L3 审批」两条硬约束
- 能逐字背出《步行客人预案》标准补偿包四步，并在到店无房场景下按序独立执行完毕
- 能判断 多张表同时给出库存类动作时的优先级（表 L > 表 B > 其余），并按表 O 完成仲裁与台账记录
前置要求：M01 指标与计算、M03 每日操作流水线（表 B / 表 E 已在 L1 用过）、M05 需求预测（预测 OCC 是表 B 的唯一输入）、M06 价格体系设计（房型代码与 10 个房型的平峰 BAR）。
本模块完整内嵌《法典》：表 B（库存与限制条件配置）、表 E（超额预订标准）、表 J（免费升级规则）、表 L（异常事件应急 · 超售过度分支与步行客人预案）；引用 表 A、表 C、表 D、表 F、表 H、表 I、表 M、表 O。全部阈值以《SPEC》第四章为唯一版本。
- 库存战术的坐标：为什么库存优先于价格
- 《法典》表 B · 库存与限制条件配置表（完整内嵌）
- 五种限制条件逐个讲：MinLOS / MaxLOS / CTA / CTD / Stop Sell
- ★ 撤除机制：真实工作中最高频的事故
- 《法典》表 E · 超额预订标准表（完整内嵌 · 三步法）
- 四个完整超售计算案例（一步步走完三步法）
- 超售的落地：房型级分配与三项配套准备
- 《法典》表 J · 免费升级规则表（完整内嵌）
- 《升级台账》与套房升级的 L3 审批
- 《法典》表 L · 超售过度与《步行客人预案》四步补偿包
- 主流系统操作路径映射表
- 讲师示范 ①：D2 高涨日（表 B 全四列 + 撤除计划）
- 讲师示范 ②：超售日 → 到店无房 → 启动步行客人预案
- 学员跟练（6 题）
- 判定表默写清单（当堂默写）
- 随堂测（5 题）
- 本模块产出物
一、库存战术的坐标：为什么库存优先于价格
《法典》表 O 把「表 B 库存」排在第 2 优先级，仅次于表 L 应急，高于表 A 价格。原因只有一条：
价格定高了，明天降回来，损失的只是中间这段时间的成交量。
库存放错了，房间被低价预订锁定，您就再也拿不回来了——除非付违约成本。
同理，超售少了只是少卖几间，超售多了就是客人到店无房，代价是《步行客人预案》的全套补偿 + 差评 + 忠诚会员流失，这个代价是单房收益的十几倍。
| 优先级 | 表 | 场景 | 与库存的关系 |
|---|---|---|---|
| 1 | 表 L 应急 | 异常事件，覆盖一切 | 「需求暴涨」分支含「设 MinLOS 2、关低价渠道」；「超售过度」分支启动步行客人预案 |
| 2 | 表 B 库存 | 库存安全（超售 / 关房） | 本模块主体 |
| 3 | 表 A 价格 | 常规价格调整 | 价格动作让位于库存动作 |
| 4 | 表 C ARI | 竞争定位微调 | — |
| 5 | 表 H 渠道 | 渠道开关 | 渠道开关本质是「库存投放」，与表 B 的「低价渠道 Stop Sell」重叠时以表 B 为准 |
| 6 | 表 D MPI | 份额诊断 | 多为分析而非动作 |
表 B 有一列叫「低价渠道 Stop Sell」，表 H 也有渠道开关的动作，两者都管渠道。冲突时以表 B 为准（优先级 2 > 5）。
具体规则：先按表 H 定出该档位的全渠道配置，再按表 B 的「低价渠道 Stop Sell」列做叠加关闭。表 B 要求关闭的渠道，无论表 H 说什么都关；表 B 未要求关闭的，按表 H 执行。
例：预测 OCC 92%（表 B 走 90–95% 行，要求「关闭尾房特惠」；表 H 走 90–95% 行，要求「OTA 国内开 2 家，批发商关」）→ 最终：OTA 国内开 2 家、尾房特惠关、批发商关（表 H 已关）、GDS 开、直销全开。
二、《法典》表 B · 库存与限制条件配置表（完整内嵌）
| 预测 OCC | MinLOS | CTA | 低价渠道 Stop Sell | 超额预订 |
|---|---|---|---|---|
| ≥95% | 2 晚（D1 峰值日 3 晚） | 启用 | 关闭尾房特惠 / 团购 / 批发商 | 不超售 |
| 90–95% | 2 晚 | D1 日启用 | 关闭尾房特惠 | ≤2 间 |
| 85–90% | 1–2 晚（周末 2 晚） | 否 | 保留 | 按表 E |
| 70–85% | 1 晚 | 否 | 全开 | 按表 E |
| <70% | 不设限 | 否 | 全开 + 上促销 | 不超售 |
2.1 定行规则（与表 A 完全一致，不许另创）
新人最常犯的错是把表 B 读成 4 行（≥95% / 85–95% / 70–85% / <70%），把「90–95%」吃掉。这会直接导致两处错误：
① 本该「≤2 间」的超售，被误读成「按表 E」算出一个更大的数；
② 本该「关闭尾房特惠」，被误读成「保留」。
五行的边界（含下界不含上界）：
≥95.0% →「≥95%」行
90.0% ≤ X < 95.0% →「90–95%」行
85.0% ≤ X < 90.0% →「85–90%」行
70.0% ≤ X < 85.0% →「70–85%」行
X < 70.0% →「<70%」行
2.2 逐行逐列展开
| 列 | 取值 | 含义 | 怎么落位（系统无关） | 易错点 |
|---|---|---|---|---|
| MinLOS 最少住期 |
3 晚 | 只接受连住 ≥3 晚的预订 | 在限制条件（Restriction）中，按「日期 × 房型 × 价格代码」三维写入最少住期 = 3 | 「1 晚」与「不设限」是同一个动作：清空 MinLOS 值，不是填入数字 1。填入 1 在某些系统里会被识别为「最少住 1 晚」，与清空效果相同；但在另一些系统里会与价格代码绑定产生意外限制，统一执行「清空」最安全 |
| 2 晚 | 只接受连住 ≥2 晚的预订 | 同上，写入 2 | ||
| 1 晚 / 不设限 | 不限制住期 | 清空 MinLOS 值 | ||
| CTA 不可入住 |
启用 | 该日不接受新到店，但允许延续入住（已在住的客人可以跨过这一天） | 在限制条件中对该日启用 Closed to Arrival | CTA ≠ 关房。CTA 只挡「新到店」，不挡「延续」；关房（Stop Sell / Close-out）是彻底不可售。混用会导致续住客人被系统自动拒绝 |
| 否 / D1 日启用 | 不限制新到店；「D1 日启用」意为该日若为 D1 峰值日则启用，否则不启用 | 查目标日需求等级代号，为 PEAK（D1）才启用 | ||
| 低价渠道 Stop Sell |
关闭尾房特惠 / 团购 / 批发商 | 三类低价通路全部停售 | 本店侧（PMS / 渠道管理器）+ 渠道侧（OTA 后台）两层都要关 | 只做本店侧，渠道缓存可能仍显示可售；只做渠道侧，其他通路仍在卖。两层都做并各留一张截图 |
| 关闭尾房特惠 / 保留 | 「保留」= 维持现状，不动 | 不动作（但要在台账备注写明「保留，未动作」） | ||
| 全开 / 全开 + 上促销 | 低价通路全部开放；「+ 上促销」指上架促销产品 | 确认三类通路均为开放态；上促销指上架「今日特惠」类尾房产品 | ||
| 超额预订 | 不超售 | 超售上限设 0 | 在超额预订功能中把上限设为 0（不是「不设置」） | 只有「85–90%」与「70–85%」两行走表 E。「90–95%」行直接取 ≤2 间；「≥95%」与「<70%」行不超售，不需要查表 E |
| ≤2 间 | 超售上限取 2 间 | 直接设 2 间 | ||
| 按表 E | 走表 E 三步法计算 | 见第 5、6 节 |
三、五种限制条件逐个讲：MinLOS / MaxLOS / CTA / CTD / Stop Sell
每加一道限制条件，就等于在预订漏斗上加一层筛子，必然漏掉一部分真实需求。所以设置限制条件的判断标准永远是：
筛掉的低价值需求 > 误筛掉的高价值需求。
想不清楚这个不等式，就不要设。
3.1 MinLOS（最少住期 · Minimum Length of Stay）
① 「周末 2 晚」的周末指周五、周六入住（对应《SPEC》2.5 中旺季周五六为 D2 高涨日），不是周六周日。
② MinLOS 只影响「以该日为入住日」的预订，不影响以该日为中间日的连住订单。所以要挡碎片化，必须对峰值日的每一天都设，不能只设中间那天。
③ D1 峰值日的 MinLOS = 3 晚只在「≥95%」行出现；「90–95%」行是 2 晚，即使该日是 D1 也不变——因为 90–95% 行专门写了「2 晚」，而「≥95%」行写的是「2 晚（D1 峰值日 3 晚）」。
3.2 MaxLOS（最多住期 · Maximum Length of Stay）
因此它不是每日流水线的标准动作，只在特定场景启用。启用必须满足两个条件：① 目标日为 D1 峰值日；② 预测 OCC ≥ 95%。两个条件缺一不启用。
启用与撤除都必须写进《调价台账》，触发表编号填「表 B」，并在备注第二段写明启用依据。不得凭口头要求设置。
3.3 CTA（不可入住 · Closed to Arrival）
3.4 CTD（不可离店 · Closed to Departure）
CTA（Closed to Arrival）= 不让您来。作用点是入住日，防止新客人在这天开始住。
CTD（Closed to Departure）= 不让您走。作用点是离店日，防止客人在这天结束住。
口诀：A 是 Arrival（来），D 是 Departure（走）。
典型组合（国庆 10 月 1–5 日）：10/1 设 CTA（防止单日客）＋ MinLOS 3 晚；10/5 设 CTD（防止客人在峰值最后一天退房造成 10/6 空档）。两个都要在假期结束后第一时间撤除。
3.5 Stop Sell（停售 / 关房 · Close-out）
3.6 五种限制条件速查卡
| 限制条件 | 挡什么 | 作用点 | 《法典》表 B 有无档位 | 云璟启用条件 | 撤除验证方式 |
|---|---|---|---|---|---|
| MinLOS | 住期太短的预订 | 入住日 | 有（5 行档位） | 按表 B 逐日配置 | 试订 1 晚，应被拒绝 |
| MaxLOS | 住期太长的预订 | 入住日 | 无 | D1 峰值日 且 预测 OCC ≥95% | 试订超长住期，应能订成功 |
| CTA | 该日新到店 | 入住日 | 有（3 行档位） | 按表 B 逐日配置 | 试订「该日入住 1 晚」，应能订成功 |
| CTD | 该日离店 | 离店日 | 无 | 表 L 需求暴涨 + L3 审批 | 试订「该日离店」，应能订成功 |
| Stop Sell | 全部预订（房型/价格码/渠道） | 视层级 | 有（低价渠道列） | 按表 B + 表 H | 两层都撤 + 缓存刷新后前台视角复查 |
四、★ 撤除机制：真实工作中最高频的事故
事故 A：国庆 10 月 2 日设了 MinLOS = 3 晚，10 月 8 日没撤。10 月 9 日起所有 1–2 晚的预订被系统静默拒绝，OTA 上酒店显示「不可订」，销售部连续 4 天没收到 OTA 订单，第 5 天才被发现。损失约 260 个房晚。
事故 B：展会日对 STD-K 设了 Stop Sell（为升级腾房），展会结束后忘了撤。STD-K 共 70 间，占房量 21.9%，连续 11 天零预订，前台以为是市场不好。损失约 480 个房晚。
事故 C：峰值日启用了 CTA，撤除时只关了本店侧，渠道侧（携程后台）的房态没同步改回。携程上该房型持续显示不可订 2 周，且 OTA 排名因此下滑。损失订单 + 排名权重下降。
三起事故的共同点：设置动作做得很规范，撤除动作完全没有流程。本节就是来解决这个问题的。
4.1 根本原因：限制条件有「生效日」但没有「到期日」
在系统里设置限制条件时，您填的是「从哪天开始」。系统不会问您「到哪天结束」——因为它的设计假设是「您会记得来撤」。而人一定会忘。
所以撤除机制的核心不是「提醒自己」，而是把到期日变成一个系统里的字段。
4.2 三重保险机制（云璟标准做法）
保险一 · 设置即登记：每一条限制条件都必须进《限制条件存量清单》
设置限制条件的同一个动作里，必须同步在《限制条件存量清单》里新增一行。这张表的字段固定 8 个：
| # | 字段 | 说明 |
|---|---|---|
| 1 | 限制条件类型 | MinLOS / MaxLOS / CTA / CTD / Stop Sell |
| 2 | 对象 | 日期 + 房型代码 + 价格代码 + 渠道代码（四元组，缺一不可） |
| 3 | 设置值 | 如「MinLOS = 3」「CTA 开」「Stop Sell 关（携程·STD-K）」 |
| 4 | 设置日期 | 操作当天的日期 |
| 5 | 生效区间 | 起始日 – 结束日。必须填结束日，不允许留空 |
| 6 | 到期日最关键 | = 生效结束日的次日。撤除动作在这一天执行 |
| 7 | 触发表编号 | 表 B / 表 H / 表 L / 表 J |
| 8 | 撤除状态 | 生效中 / 已撤除（含撤除日期与撤除人） |
第 6 列「到期日」是整个机制的支点。有了它，撤除就不再是「记得去撤」，而是「清单上写着今天该撤」。
保险二 · 每日扫描：08:30 查表环节的固定第 0 步
《法典》表 M 的 08:30 时段是「逐日查《法典》表 A/B/C/H，得出动作清单」。在这个动作之前增加一步固定扫描，耗时上限 3 分钟：
这 3 分钟是全部保险里性价比最高的。三起事故里有两起（A、B）都能被这一步直接拦住。
保险三 · 周一全量对账：表 N 的每周一动作
《法典》表 N 规定每周一做三件事（房型价差校验、未来 8 周预测更新、渠道开关复核）。云璟在此基础上增加第四件：限制条件全量对账。
做法：从系统中导出生效中的限制条件全量清单（这是真实数据，不是人工维护的表），与《限制条件存量清单》逐行比对，找出三类差异：
| 差异类型 | 表现 | 处置 |
|---|---|---|
| ① 系统有、清单无 | 系统里有一条生效中的限制条件，但存量清单里没有记录 | 最危险。说明有人设了没登记。立即补登记，追溯设置人与设置日期，登记为流程违规 |
| ② 清单有、系统无 | 清单显示生效中，但系统里已无此限制 | 说明已被撤除但未登记。核实撤除人与撤除依据，补登记撤除状态 |
| ③ 两边都有但值不同 | 记录的是 MinLOS = 3，系统里是 MinLOS = 2 | 核实哪次修改未留痕，以系统实际值为准回改清单，并追溯修改人 |
4.3 限制条件撤除五步法（背下来，每次撤除都按这五步走）
查到期日
在《限制条件存量清单》中筛出「到期日 = 今天」的全部行。不看系统的库存显示，只看清单——系统的显示不能告诉您是「本来就满房」还是「被限制挡住了」。
两层都撤
本店侧（PMS / 渠道管理器）：清空 MinLOS / 关闭 CTA / 关闭 CTD / 打开 Stop Sell。
渠道侧（OTA 后台）：把对应日期的房态恢复为可售。
限制条件是按「日期 × 房型 × 价格代码 × 渠道」四元组设的，撤除必须四元组对齐。只撤了「日期」这一维，会留下「某房型仍被限制」的残片。
试订验证（这一步不许跳）
| 撤的是什么 | 试订动作 | 成功 = 撤干净了 | 失败 = 怎么办 |
|---|---|---|---|
| MinLOS | 选该日入住、住 1 晚 | 能订成功 | 检查是否按房型/价格代码分开设了多份，逐一清空 |
| MaxLOS | 选该日入住、住 超出原上限的晚数 | 能订成功 | 同上 |
| CTA | 选该日为入住日、住 1 晚 | 能订成功 | 检查本店侧开关是否真的关了 |
| CTD | 选该日为离店日的订单 | 能订成功 | 同上，且注意当日夜审前必须完成 |
| Stop Sell（渠道） | 在该渠道前台视角搜索该日该房型 | 能搜到且可订 | 等缓存刷新后复查；仍不可订则联系渠道经理 |
截图存证
每张截图含 4 项：日期 / 四元组对象 / 设置项 / 撤除前后状态。试订成功的页面也要截图（这是「撤干净了」的证据）。
台账登记 + 清单更新
① 《调价台账》新增一条，动作类型填「撤 MinLOS / 撤 CTA / 撤 CTD / Stop Sell 关」，触发表编号填「表 B」（若由表 L 触发则填「表 L」）。
② 《限制条件存量清单》该行的「撤除状态」改为「已撤除（日期 + 撤除人）」。
③ 若发现「已过期仍生效」，额外登记为事故，在台账备注第二段写明「过期 X 天，期间损失房晚约 X 间」，并上报 L2。
设的时候就想好哪天撤 · 撤的时候必须试订验证 · 每周一全量对账一次。
这三句话能挡住 95% 的限制条件事故。剩下 5% 靠第 6 节之后的超售配套准备来兜底。
五、《法典》表 E · 超额预订标准表（完整内嵌 · 三步法）
第一步：查基准超售率
| No-show + 取消 合计 | 基准超售率 | 审批要求 |
|---|---|---|
| <5% | 0% | — |
| 5–10% | 2% | — |
| 10–15% | 3% | — |
| 15–20% | 5% | — |
| 20–30% | 7% | — |
| >30% | 10% | 需 L3 经理审批 |
<5.0% → 0% ｜ 5.0% ≤ X < 10.0% → 2% ｜ 10.0% ≤ X < 15.0% → 3%
15.0% ≤ X < 20.0% → 5% ｜ 20.0% ≤ X < 30.0% → 7% ｜ X ≥ 30.0% → 10%（需 L3 审批）
注意最后两档的跨度不同：20–30% 是 10 个百分点的跨度，>30% 是无上限的。一旦合计值 ≥30%，无论多高都取 10%，且必须 L3 审批——这正是「无上限档必须有人把关」的设计意图。
第二步：修正系数（连乘）
| # | 条件 | 系数 | 为什么这么设计 |
|---|---|---|---|
| 1 | D1 峰值日 / D2 高涨日 | × 0.5 | 需求旺的日子，房间本来就能卖掉；一旦超售失败，您要把客人送走，而附近的同档酒店在旺日也几乎没房，补偿成本与口碑损失成倍上升 |
| 2 | 担保预订（预付 / 信用卡担保）占比 >60% | × 0.5 | 担保预订的 No-show 率极低。担保多 = 兑现率高 = 不需要超售 |
| 3 | 会议团队占当日 >40% | × 0.5 | 团队是整块到店、整块离店，要么全来要么全不来，方差极大。团队日超售的失败代价是「一次送走几十个人」 |
| 4 | 协议客户集中度 >50% | × 0.8 | 协议客户是长期合约关系，把协议客送走的代价远高于把散客送走（可能丢掉整个公司客户），所以温和下修 |
这是表 E 最容易被低估的地方。假设基准超售率 5%，四个条件全中：
5% × 0.5 × 0.5 × 0.5 × 0.8 = 0.5%。按 320 间算 = 1.6 → 1 间。
设计意图非常明确：越是「需求旺 + 客人靠谱 + 有大团队 + 协议客多」的日子，越不该超售。
因为这类日子一旦超售失败，您要送走的是一个高价值客人或一个团队，代价远高于多卖一间房的收益。
第三步：硬上限（三条同时生效，取最小值）
| # | 硬上限 | 云璟（可售 320 间）对应值 | 说明 |
|---|---|---|---|
| 1 | 超售间数不超过可售房量的 5% | 320 × 5% = 16 间 | 随可售房量变动。若当日 OOO 8 间（可售 312），则为 312 × 5% = 15.6 → 比较时取 15.6 |
| 2 | 超售间数不超过 15 间 | 15 间 | 绝对值上限，与房量无关。这一条在云璟（320 间）比第 1 条更紧，实际起作用的通常是这一条 |
| 3 | 步行距离 30 分钟内无同档次备用酒店时，超售率减半 | 按实际备用酒店情况判定 | 注意是「超售率减半」，不是「超售间数减半」。减半发生在修正后的超售率上，然后重新计算间数并向下取整 |
完整的计算顺序是：
① 若 30 分钟内无同档备用酒店 → 修正后超售率 × 0.5，得到最终超售率；
② 超售间数（未取整）= 可售房量 × 最终超售率；
③ 取硬上限：min(未取整值, 可售房量 × 5%, 15)；
④ 最后一步才向下取整。
顺序错了结果就错。若先取整再比大小，会得到偏大的结果。
5.1 什么时候需要查表 E
回到表 B 的「超额预订」列：
≥95% → 不超售（超售上限 0，不查表 E）
90–95% → ≤2 间（直接取 2，不查表 E）
85–90% → 按表 E
70–85% → 按表 E
<70% → 不超售（超售上限 0，不查表 E）
判断顺序：先看表 B 的那一行怎么写的，只有写着「按表 E」才去算。很多新人一上来就套表 E，在 ≥95% 的峰值日算出 8 间超售，这是严重错误。
六、四个完整超售计算案例（一步步走完三步法）
第二步 · 修正系数（逐条核对） D1 峰值日 / D2 高涨日？否（D3 平峰日）→ × 1
担保预订占比 45% > 60%？否 → × 1
会议团队占当日 18% > 40%？否 → × 1
协议客户集中度 38% > 50%？否 → × 1
修正后超售率 = 3% × 1 = 3%
第三步 · 硬上限 有备用酒店 → 超售率不减半，最终超售率 = 3%
超售间数（未取整）= 312 × 3% = 9.36
硬上限①：312 × 5% = 15.6 硬上限②：15
取 min(9.36, 15.6, 15) = 9.36
向下取整 → 9 间
结论 11 月 12 日超售上限 = 9 间（无需 L3 审批，需 L2 复核）
第二步 · 修正系数（逐条核对） D1 峰值日 / D2 高涨日？是（D2） → × 0.5
担保预订占比 68% > 60%？是 → × 0.5
会议团队占当日 42% > 40%？是 → × 0.5
协议客户集中度 35% > 50%？否 → × 1
修正后超售率 = 7% × 0.5 × 0.5 × 0.5 = 7% × 0.125 = 0.875%
第三步 · 硬上限 有备用酒店 → 不减半，最终超售率 = 0.875%
超售间数（未取整）= 320 × 0.875% = 2.80
硬上限①：320 × 5% = 16 硬上限②：15
取 min(2.80, 16, 15) = 2.80
向下取整 → 2 间
结论 9 月 25 日超售上限 = 2 间
基准 7% 按 320 间算本来是 22.4 间，被三个 ×0.5 一路砍到 0.875%，只剩 2 间。
这正是表 E 想要的结果：展会日 + 担保客多 + 有大团队 = 「需求旺盛、客人靠谱、但一旦出事就是整块出事」。
此时超售的期望收益（多卖 20 间 × 均价 ¥900 = ¥18,000）远低于期望损失（若送走 5 个客人：房费差价 + 交通 + 升级补偿 + 积分 + 差评 ≈ ¥15,000，外加团队客户流失风险）。
所以宁可少卖，不可超卖。
严格来说，此时已不需要查表 E。下面仍走一遍，用于演示「无备用酒店时超售率减半」这条规则的用法：
第一步 · 基准超售率 6% 落在「5–10%」档 → 基准超售率 = 2%
第二步 · 修正系数 D1 峰值日？是 → × 0.5
担保预订占比 75% > 60%？是 → × 0.5
会议团队 10% > 40%？否 → × 1
协议客户集中度 55% > 50%？是 → × 0.8
修正后超售率 = 2% × 0.5 × 0.5 × 0.8 = 0.4%
第三步 · 硬上限 步行 30 分钟内无同档次备用酒店 → 超售率减半：0.4% × 0.5 = 0.2%
超售间数（未取整）= 320 × 0.2% = 0.64
硬上限①：16 硬上限②：15
取 min(0.64, 16, 15) = 0.64
向下取整 → 0 间
结论 10 月 3 日超售上限 = 0 间
① 表 B「≥95%」行直接规定「不超售」——这是最硬的一条，根本不需要算；
② 无备用酒店 → 超售率减半；
③ 向下取整把 0.64 变 0。
三条叠加，结果必然是 0。教学要点：查表顺序永远是「先查表 B 定要不要超售，再查表 E 定超多少」。顺序反了就会算出荒谬的结果。
第二步 · 修正系数 D1 / D2 日？否 → × 1
担保预订占比 30% > 60%？否 → × 1
会议团队 12% > 40%？否 → × 1
协议客户集中度 28% > 50%？否 → × 1
修正后超售率 = 10%（无任何修正）
第三步 · 硬上限 有备用酒店 → 不减半，最终超售率 = 10%
超售间数（未取整）= 312 × 10% = 31.2
硬上限①：312 × 5% = 15.6 硬上限②：15
取 min(31.2, 15.6, 15) = 15 ← 硬上限②（15 间）起作用
向下取整 → 15 间
结论 6 月 18 日超售上限 = 15 间（受硬上限封顶；需 L3 审批）
① 硬上限是「天花板」，不是「目标值」。算出的 31.2 间被 15 间的绝对上限压到 15 间。此时必须清醒：还有 16.2 间的 No-show 风险没有被覆盖。这不是计算错误，而是《法典》的风险容忍上限——超过 15 间，一旦失败就是一次送走十几个人，代价不可接受。
此时应改用非超售手段承接风险：提高担保预订占比（预售/预付产品）、收紧取消政策、对非担保订单做 24h 前外呼确认。
② No-show + 取消合计 33% 本身就是一个警报。正常情况下这个数应在 10–20%。33% 说明取消政策过松或存在大量无效占位订单，应专项排查（是否渠道超售？是否有恶意占位？），而不是靠超售去对冲。
6.1 四案例汇总对照
| 案例 | 目标日 | 表 B 行 | 基准率 | 修正系数 | 修正后 | 未取整 | 起作用的上限 | 结果 |
|---|---|---|---|---|---|---|---|---|
| ① | 11/12 D3 | 70–85% | 3% | 无（×1） | 3% | 9.36 | 无（未触及） | 9 间 |
| ② | 9/25 D2 | 85–90% | 7% | ×0.5 ×0.5 ×0.5 | 0.875% | 2.80 | 无（未触及） | 2 间 |
| ③ | 10/3 D1 | ≥95% | 2% | ×0.5 ×0.5 ×0.8 | 0.4% → 减半 0.2% | 0.64 | 表 B「不超售」+ 无备用酒店减半 | 0 间 |
| ④ | 6/18 D3 | 70–85% | 10% | 无（×1） | 10% | 31.2 | 硬上限② 15 间 | 15 间 |
七、超售的落地：房型级分配与三项配套准备
7.1 房型级分配（不能只设总数）
超售上限是一个总数，但系统里必须按房型设置。两条分配规则：
云璟的 STE-B（商务套房，8 间）与 STE-E（行政套房，2 间）不参与超售分配。
理由：① 套房间数极少（合计 10 间，占 3.1%），超售的统计意义不大；② 超售失败时，套房客人是最难送走的——您把付 ¥1,280 的套房客送到别的酒店，补偿成本与客诉烈度都远高于标准房客。
分配基数 = 总房量 − 套房间数 = 320 − 10 = 310 间。
① 各房型配额（未取整）= 该房型间数 ÷ 分配基数 × 超售总数
② 先向下取整分配给每个房型
③ 把剩余名额按小数部分从大到小依次 +1，直到分完（最大余数法）
| 房型代码 | 房型名称 | 间数 | 配额（未取整） | 取整 | 余数 | 最终配额 |
|---|---|---|---|---|---|---|
STD-K | 标准大床房 | 70 | 2.032 | 2 | .032 | 2 |
STD-T | 标准双床房 | 50 | 1.452 | 1 | .452 | 2 ← 余数第 3 |
SUP-K | 高级大床房 | 60 | 1.742 | 1 | .742 | 2 ← 余数第 1 |
SUP-T | 高级双床房 | 40 | 1.161 | 1 | .161 | 1 |
DLX-K | 豪华大床房 | 45 | 1.306 | 1 | .306 | 1 |
DLX-V | 豪华江景房 | 15 | 0.435 | 0 | .435 | 0 ← 余数第 4，名额已分完 |
EXE-K | 行政大床房 | 25 | 0.726 | 0 | .726 | 1 ← 余数第 2 |
EXE-T | 行政双床房 | 5 | 0.145 | 0 | .145 | 0 |
STE-B | 商务套房 | 8 | 不参与超售 | |||
STE-E | 行政套房 | 2 | 不参与超售 | |||
| 合计 | 9.000 | 6 | — | 9 ✓ | ||
| 房型代码 | 间数 | 配额（未取整） | 取整 | 余数 | 最终配额 |
|---|---|---|---|---|---|
STD-K | 70 | 3.387 | 3 | .387 | 3 |
STD-T | 50 | 2.419 | 2 | .419 | 3 ← 余数第 4 |
SUP-K | 60 | 2.903 | 2 | .903 | 3 ← 余数第 2 |
SUP-T | 40 | 1.935 | 1 | .935 | 2 ← 余数第 1 |
DLX-K | 45 | 2.177 | 2 | .177 | 2 |
DLX-V | 15 | 0.726 | 0 | .726 | 1 ← 余数第 3 |
EXE-K | 25 | 1.210 | 1 | .210 | 1 |
EXE-T | 5 | 0.242 | 0 | .242 | 0 |
STE-B / STE-E | 10 | 不参与超售 | |||
| 合计 | 15.000 | 11 | — | 15 ✓ | |
7.2 开启超售日的三项配套准备（缺一不可）
准备 1 · 30 分钟内同档次备用酒店名单可用。名单必须含：酒店名称、档次、距离（步行/车程分钟数）、当日实时可售状态、协议价或前台价、24 小时联系电话。名单每周更新一次，且超售日当天 17:00 二次巡检时必须重新确认一次房态——上周能订不代表今天还能订。
准备 2 · 《步行客人预案》标准补偿包已备妥。含：备用酒店协议（承担差价与交通的财务授权）、本店下次升级券模板、忠诚会员积分补偿的授权额度（5,000 积分/人次）、已预签的总经理致歉信（留出填空的客人姓名与日期，总经理签名须为原件预签，不得事后补签）。
准备 3 · 《升级台账》已准备。超售日大概率触发《法典》表 J 的免费升级（超售需要腾房）。台账表单、L3 审批通道、前厅执行话术必须提前就位，不能等客人站在前台了才临时找人批。
7.3 《超售日监控表》（超售日 17:00 二次巡检固定动作）
| # | 字段 | 说明 |
|---|---|---|
| 1 | 目标日 / 可售房量 / 超售上限 | 来自表 E 计算结果 |
| 2 | 当前在手（含超售部分） | 实时值，17:00 抓取 |
| 3 | 超售余额 = 超售上限 −（在手 − 可售） | 为正 = 还能再收；为 0 = 立即关闭超售；为负 = 已超限，立即上报 L2 |
| 4 | 今日实际 No-show 间数 | 夜审后回填，用于校验表 E 的 No-show 参数是否还成立 |
| 5 | 今日实际 24h 内取消间数 | 同上 |
| 6 | 备用酒店当日房态 | 17:00 实时确认，记录确认时间与确认人 |
| 7 | 是否启动步行客人预案 | 是 / 否；若为「是」关联到《步行客人处置记录单》编号 |
| 8 | 免费升级间数 | 关联《升级台账》，不得超过表 J 的套房 ≤3 间上限 |
八、《法典》表 J · 免费升级规则表（完整内嵌）
| 项目 | 内容 |
|---|---|
| 升级触发 | ① 超售需要腾房；② 目标日高档房预测空置 >20%；③ 会员权益兑现 |
| 执行顺序 （严格按序） |
1. 忠诚会员：钻石 > 铂金 > 金卡 > 银卡 2. 同档内：预订价高者优先 3. 同价：入住天数长者先 4. 相同：复购次数多者先 |
| 升幅限制 | 每次最多升 1 档（标准 → 高级 → 豪华 → 行政 → 套房），禁止连跳 2 档（除 L3 特批） |
| 套房升级 | 每日不超过 3 间，且须 L3 审批 |
| 记录 | 每次升级写入《升级台账》，注明原因、房号、会员等级 |
8.1 三个触发条件的逐个解释
被动升级。到店客人多于可用房间，必须把一部分客人升级到更高房型，腾出低档房给后到的人。
判定：当日「在手 − 可售房量 > 0」且已无法再安排步行客人时触发。
优先级最高——这是救火，不是福利。
主动升级。目标日高档房（DLX 及以上）预测空置率 >20% 时，把低档房客人升级上去，腾出低档房继续卖。
算式：高档房空置率 = 高档房剩余间数 ÷ 高档房总间数 × 100%。云璟高档房 = DLX-K 45 + DLX-V 15 + EXE-K 25 + EXE-T 5 + STE-B 8 + STE-E 2 = 100 间，>20% 即剩余 >20 间。
注意：这是「空置」不是「已售」，别把分母搞反。
合约升级。会员条款中写明「钻石会员到店可免费升 1 档」，属于必须履行。
判定：客人出示有效会员等级且在住期间。
注意：会员权益升级同样受「最多升 1 档」限制，不能因为「他是钻石」就连跳两档；套房升级同样计入每日 ≤3 间。
8.2 四级排序的逐条解释（最容易出错的是第 2 级）
| 级别 | 规则原文 | 含义 | 常见误读 |
|---|---|---|---|
| 1 | 忠诚会员：钻石 > 铂金 > 金卡 > 银卡 | 先按会员等级排序。非会员排在所有会员之后 | 误以为「会员等级相同才比下一级」——不对，等级不同时第 1 级就分出胜负了，不再往下比 |
| 2 | 同档内：预订价高者优先 | 同等级会员之间，谁的原预订价高谁先升 | 最常错误读成「全店比价」。是同一会员等级内部比，一个银卡付 ¥900 的人不会优先于一个钻石付 ¥600 的人 |
| 3 | 同价：入住天数长者先 | 预订价也相同，则住得久的先升 | 误读成「先到店者先升」。表 J 没有「先到先得」这条规则，不要自己加 |
| 4 | 相同：复购次数多者先 | 都相同，则历史累计入住次数多者先升 | 把「复购次数」误读成「累计消费金额」。表 J 写的是复购次数，按次数不按金额 |
硬约束 1 · 每次最多升 1 档。云璟的房型阶梯是：标准（STD）→ 高级（SUP）→ 豪华（DLX）→ 行政（EXE）→ 套房（STE）。
所以 STD 只能升到 SUP，不能升到 DLX；DLX 只能升到 EXE，不能直接升到 STE。
唯一例外：L3 特批。特批必须在《升级台账》注明特批人姓名与理由。
硬约束 2 · 套房升级每日不超过 3 间，且须 L3 审批。云璟的套房共 10 间（STE-B 8 + STE-E 2），每日最多放出 3 间用于升级。
计数口径：按办理升级的日期计数，不是按入住日计数。也就是说，10 月 2 日办理的升级，无论客人住几天，都计在 10 月 2 日这一天的 3 间额度内。
三个触发条件共享这 3 间额度——超售腾房、高档房空置、会员权益，加起来一天最多 3 间套房升级。
8.3 升级排序实操（一个完整的排序练习）
| 客人 | 会员等级 | 原预订价 | 入住天数 | 复购次数 | 排序 |
|---|---|---|---|---|---|
| 客人甲 | 金卡 | ¥680 | 2 | 5 | ? |
| 客人乙 | 钻石 | ¥580 | 1 | 2 | ? |
| 客人丙 | 银卡 | ¥820 | 3 | 12 | ? |
| 客人丁 | 钻石 | ¥680 | 1 | 7 | ? |
| 客人戊 | 钻石 | ¥680 | 3 | 4 | ? |
| 客人己 | 无会员 | ¥960 | 5 | 0 | ? |
排序过程：
第 1 级（会员等级）：钻石 = 乙、丁、戊（3 人）→ 进入下一级；金卡 = 甲；银卡 = 丙；无会员 = 己（排最后）。
所以前 3 名必在 {乙、丁、戊} 中产生，2 个升级名额全部给钻石会员，甲、丙、己本轮无份。
第 2 级（同档内比预订价）：乙 ¥580 < 丁 ¥680 = 戊 ¥680 → 乙出局，丁与戊进入第 3 级。
（关键：丙的 ¥820 比丁戊都高，但丙是银卡，第 1 级就已经被淘汰了，不参与比价。）
第 3 级（同价比入住天数）：丁 1 天 < 戊 3 天 → 戊第 1，丁第 2。
最终排序：① 戊（升级）② 丁（升级）③ 乙 ④ 甲 ⑤ 丙 ⑥ 己
升档：戊与丁均从 STD 升到 SUP（升 1 档），不得升到 DLX。
九、《升级台账》与套房升级的 L3 审批
| # | 字段 | 填写规范 | 为什么要有 |
|---|---|---|---|
| 1 | 日期 | 办理升级的日期（不是入住日） | 套房每日 ≤3 间按此日期计数 |
| 2 | 客人姓名 / 会员号 | 必填 | 复购次数与积分补偿都靠它关联 |
| 3 | 会员等级表 J 要求 | 钻石 / 铂金 / 金卡 / 银卡 / 非会员 | 第 1 级排序依据；也是后续积分补偿的判定依据 |
| 4 | 升级原因表 J 要求 | 下拉：① 超售腾房 ② 高档房空置 >20% ③ 会员权益兑现 | 三个原因的性质完全不同（被动/主动/合约），混在一起统计会让高档房空置率分析失真 |
| 5 | 原房型代码 | 如 STD-K | 校验是否只升 1 档 |
| 6 | 升级后房型代码表 J 要求（房号） | 房型代码 + 实际房号 | 房号是前厅排房与客史追溯的唯一凭据 |
| 7 | 升档数 | 填 1（正常）或 2 及以上（须 L3 特批） | 自动标红 = 1 的记录，触发 L3 特批核查 |
| 8 | 原预订价 / 升级后房价 | 两个都要填 | 升级的机会成本 = 升级后房价 − 原预订价，是月度升级成本分析的输入 |
| 9 | 是否套房升级 | 是 / 否 | 触发 L3 审批与每日 3 间额度核查 |
| 10 | 审批人 | 常规升 1 档：L2；套房升级或连跳 2 档：L3 | 表 J 硬约束的取证 |
| 11 | 执行人 / 备注 | 前厅执行人姓名 + 客人反应 | 客诉追溯 |
① 前厅确认当日已有套房升级间数（查《升级台账》当日「是否套房升级 = 是」的条数）；
② 若已 3 间，直接拒绝，不得再升——改用「升级到 EXE 行政房 + 赠送双早」替代；
③ 若 <3 间，发起 L3 审批（书面或系统审批流），注明客人姓名、会员等级、升级原因、原房型与目标房型；
④ 取得 L3 书面确认后办理，并把审批人姓名填入《升级台账》第 10 列；
⑤ 夜审时由 L2 复核当日套房升级总间数 ≤3。
红线：先办后批视为违规，与表 A 约束 5（D1 峰值日调价须 L3 前置审批）同理——审批是前置条件，不是事后补签。
十、《法典》表 L · 超售过度与《步行客人预案》四步补偿包
10.1 表 L「超售过度」分支原文
| 事件类型 | 判定信号 | 立即动作（2 小时内） | 24 小时内 | 复盘 |
|---|---|---|---|---|
| 超售过度 （到店无证可住） |
到店无房 | 启动《步行客人预案》：就近同档酒店、承担差价、升级补偿、次日优先回本店 | 赔偿结算、客人回访 | 重算表 E 参数 |
在手超过可售房量是常态（这就是超售的目的），不是异常。
真正的判定信号是：夜审/排房时点，实际到店（或已确认必到）的客人数量 > 实际可用房间数量。
具体触发时点：当日 18:00 后，把「在手 − 已取消 − No-show」与「可售 − OOO 新增 − 维修房」做一次实时比对，若前者 > 后者，即判定「到店无房」，立即启动预案，不等客人站到前台。
提前两小时知道，和让客人站在大堂才知道，是两个完全不同的事故等级。
10.2 《步行客人预案》标准补偿包（四步，按序执行，不许跳步）
安排同档或更高档酒店，承担房费差价 + 交通费
执行标准：
· 档次要求：同档或更高档。云璟是中高端全服务（准五星/四星+），备用酒店必须 ≥ 此档次，不得降级安排。
· 承担范围：房费差价 + 往返交通费。差价 = 备用酒店房费 − 客人在本店的成交房价（按客人的实际成交价算，不是按 BAR 算）。
· 承担天数：本店无法提供的全部夜次。若次日仍无房，继续承担至客人可回本店为止。
· 执行人：值班经理（须有预先授权的财务额度，不得现批现报）。
本店下次入住免费升级 1 档 + 双早
执行标准：
· 升级 1 档（严格按表 J 的房型阶梯：STD→SUP→DLX→EXE→STE），不因本次事故而连跳 2 档——若客人要求连跳，须走 L3 特批。
· 双早指两份自助早餐（云璟早餐门市价 ¥128/人，含早加价 ¥68/人）。按门市价 ¥128 × 2 = ¥256 计入补偿成本，不是按 ¥68 的加价计。
· 有效期：自发放之日起 12 个月。过期作废且不延期——这条必须写在券面上，否则会形成无限期的成本敞口。
· 发放形式：实体券或系统内权益，必须记录券号并写入《升级台账》备注。
忠诚会员额外补偿 5,000 积分
执行标准：
· 仅对忠诚会员发放（钻石 / 铂金 / 金卡 / 银卡）。非会员不发放——非会员拿不到积分也没有意义。
· 金额固定 5,000 积分，不按会员等级差异化。表 L 原文写的是「忠诚会员额外补偿 5,000 积分」，没有分级。
· 发放时点：当场发放并短信通知，不等客人投诉后再补——主动补偿与被动赔偿在客诉转化率上差一个数量级。
· 成本归属：按会员渠道（LOY）综合成本率 4% 折算积分成本，计入本次事故成本。
总经理签名致歉信 + 当日值班经理全程跟进
执行标准：
· 致歉信必须由总经理亲笔签名（预签原件，留出客人姓名与日期的填空位）。打印签名或事后补签视为未执行。
· 致歉信内容四项要素：① 明确承认是本店超售失误（不许写「因不可抗力」）；② 说明已安排的同档酒店与承担范围；③ 写明后续补偿（升级券 + 积分）；④ 留下总经理与值班经理的直接联系方式。
· 全程跟进：当日值班经理负责：送客人上车 → 到备用酒店确认入住 → 次日致电确认回本店安排 → 客人离店后 72 小时内回访。
· 交接：值班经理交接班时，未闭环的步行客人必须逐位书面交接，不允许口头交接。
假设某日送走 3 位客人（2 位非会员 + 1 位钻石会员），备用酒店同档房价 ¥720，客人本店成交价 ¥680，住 1 晚：
第 1 步：房费差价（720 − 680）× 3 = ¥120；交通费（往返打车约 ¥80）× 3 = ¥240 → ¥360
第 2 步：下次升级 1 档的差价（SUP ¥680 − STD ¥580）× 3 = ¥300；双早 ¥256 × 3 = ¥768 → ¥1,068
第 3 步：5,000 积分 × 1 人 × 4% 折算（按云璟积分价值约 ¥0.01/分估算）→ 约 ¥50
第 4 步：致歉信与值班经理人力成本 → 约 ¥300
合计直接成本 ≈ ¥1,778，约 ¥593/人次。
对照：多卖 1 间房的收益 = 1 × ¥680 = ¥680。
结论：送走 1 个人的代价（¥593）几乎等于多卖 1 间房的收益（¥680），还没算差评与忠诚会员流失的长期损失。这就是为什么表 E 的三个 ×0.5 与三条硬上限设计得如此保守。
10.3 事后复盘：重算表 E 参数
① 重算 No-show 率与 24h 内取消率：取事发当月全月数据重算，看是否显著高于表 E 计算时所采用的历史值。若高出 5 个百分点以上，说明表 E 的输入已经过时。
② 核查修正系数的判定是否漏项：事发当日是否属于 D1/D2？担保占比多少？会议团队占比多少？协议集中度多少？逐条回看，看有没有漏乘的 ×0.5 / ×0.8。
③ 核查备用酒店假设：事发当日 30 分钟内的同档备用酒店是否真的有房？若没有，第三步的「无备用酒店 → 超售率减半」是否被正确应用？
④ 重设未来 30 天的超售上限：按修正后的参数重算，并在《调价台账》备注写明「依表 L 复盘重算，原上限 X 间调整为 Y 间」。
产出物：《超售过度复盘报告》，7 天内完成（表 L 的「复盘」列对需求暴跌分支写明「事后 7 天复盘报告」，超售过度分支沿用同一时限）。
十一、主流系统操作路径映射表
| 通用动作 | 通用术语 | 国际连锁常见 PMS （Opera 类） | 国产常见 PMS （西软 / 绿云类） | 渠道管理器 （Channel Manager） |
|---|---|---|---|---|
| 设最少住期 | MinLOS / 最少连住 | Restriction → Min Length of Stay | 房价控制 / 限制条件 → 最少入住天数 | 通常不设，由 PMS 推送 |
| 设最多住期 | MaxLOS / 最多连住 | Restriction → Max Length of Stay | 房价控制 → 最多入住天数 | 通常不设 |
| 设不可入住 | CTA / Closed to Arrival | Restriction → Closed to Arrival | 限制条件 → 不可入住 | 不设 |
| 设不可离店 | CTD / Closed to Departure | Restriction → Closed to Departure | 限制条件 → 不可离店 | 不设 |
| 停售某房型 | Stop Sell / Close-out | Room Type → Close-out / Stop Sell | 房态管理 → 关房 / 停售 | 房型级停售（同步至各 OTA） |
| 停售某渠道 | Channel Stop Sell | Channel / Source → Stop Sell | 渠道管理 → 渠道停售 | 主战场：渠道 → 停止投放 |
| 设超售上限 | Overbooking Limit | Room Type → Overbooking Limit | 房态管理 → 超售设置 | 部分支持，通常不设 |
| 办理免费升级 | Room Upgrade | Reservation → Room Move / Upgrade | 在住客人 → 换房 / 升级 | 不涉及 |
| 导出限制条件清单 | Restriction Report | Reports → Restriction Report | 报表 → 房价控制明细 | 渠道投放明细导出 |
本学院要求写「在限制条件中，按日期 × 房型 × 价格代码设置 MinLOS = 2」，而不是「点击 XX 按钮第 3 个 Tab」。
原因有二：① 学员毕业后会去不同的酒店用不同的系统，记住按钮没有迁移价值；② 系统升级后按钮位置会变，但「日期 × 房型 × 价格代码」这个三维模型不会变。
上面这张表是给「需要落地到具体系统」时的索引，不是教学内容本身。
十二、讲师示范 ①：D2 高涨日（表 B 全四列 + 撤除计划）
已知条件
第 1 步 · 定行
定行 90.0% ≤ 92.2% < 95.0% → 表 B「90–95%」行（不是「85–90%」行）
第 2 步 · 读四列并落位
| 列 | 表 B 值 | 落位动作 | 四元组 | 截图 |
|---|---|---|---|---|
| MinLOS | 2 晚 | 在限制条件中把 MinLOS 从「1 晚（不设限）」改为 2 晚 | 9/19 × 全 10 房型 × BAR 及衍生价（不含 CORP 与 GDS 价） | F0912-01 |
| CTA | D1 日启用 | 本日为 D2 高涨日，非 D1 → 不启用（动作：确认 CTA 为关闭态，写台账「CTA 否」） | — | F0912-02 |
| 低价渠道 Stop Sell | 关闭尾房特惠 | 本店侧 + 渠道侧两层都关「尾房特惠」渠道；团购与批发商本档不要求关闭（那两条只在 ≥95% 行出现），但需按表 H 复核 | 9/19 × 尾房特惠渠道 × 全房型 | F0912-03 |
| 超额预订 | ≤2 间 | 直接设超售上限 2 间，不查表 E（表 B 本行已直接给值） | 按房型分配，见下 | F0912-04 |
第 3 步 · 超售 2 间的房型分配
配额 STD-K：70 ÷ 310 × 2 = 0.452 → 0（余 .452）
STD-T：50 ÷ 310 × 2 = 0.323 → 0（余 .323）
SUP-K：60 ÷ 310 × 2 = 0.387 → 0（余 .387）
SUP-T：40 ÷ 310 × 2 = 0.258 → 0（余 .258）
DLX-K：45 ÷ 310 × 2 = 0.290 → 0（余 .290）
DLX-V：15 ÷ 310 × 2 = 0.097 → 0（余 .097）
EXE-K：25 ÷ 310 × 2 = 0.161 → 0（余 .161）
EXE-T：5 ÷ 310 × 2 = 0.032 → 0（余 .032）
取整合计 0，需补 2 个名额 → 余数最大的两档：STD-K（.452）、SUP-K（.387）
结论 超售 2 间 = STD-K 1 间 + SUP-K 1 间
第 4 步 · 配套准备（超售 2 间也要做，不能因为少就省）
- 备用酒店名单：确认步行 30 分钟内同档酒店当日有房（记录确认时间 08:52、确认人）
- 《步行客人预案》补偿包：升级券、积分授权、预签致歉信已在前台保险柜
- 《升级台账》表单已打印放前台；L3 审批电话通道已确认（本日若需套房升级需 L3 批）
- 《超售日监控表》已建行，17:00 二次巡检时更新
第 5 步 · ★ 撤除计划（设置的同时就写好）
| 类型 | 对象（四元组） | 设置值 | 设置日期 | 生效区间 | 到期日 | 触发表 | 撤除状态 |
|---|---|---|---|---|---|---|---|
| MinLOS | 9/19 × 全房型 × BAR 及衍生价 | 2 晚 | 09-12 | 09-19 ~ 09-19 | 09-20 | 表 B | 生效中 |
| Stop Sell | 9/19 × 尾房特惠 × 全房型 | 关 | 09-12 | 09-19 ~ 09-19 | 09-20 | 表 B | 生效中 |
| 超售 | 9/19 × STD-K 1 / SUP-K 1 | 2 间 | 09-12 | 09-19 ~ 09-19 | 09-20（自动失效） | 表 B | 生效中 |
9 月 20 日 08:30 的扫描环节会筛出这三行（到期日 = 09-20）。届时按撤除五步法执行：
① 查到期日 → ② 两层都撤（MinLOS 清空、尾房特惠本店侧+渠道侧都开）→ ③ 试订验证（选 9/20 入住 1 晚，必须能订成功；在携程搜 9/20 该房型，必须可订）→ ④ 截图 → ⑤ 台账登记（动作类型「撤 MinLOS」「Stop Sell 关」）+ 清单更新撤除状态。
超售那一行的到期日写「自动失效」，但 9 月 20 日仍需确认超售上限已归零——部分系统的超售设置按日期区间生效，区间结束后会自动归零；另一些系统需要手动清零。必须实查，不能假设。
十三、讲师示范 ②：超售日 → 到店无房 → 启动步行客人预案
时间线
08:30
17:00
备用酒店 A 江畔万枫（1.2km，280 间）确认当日有房 12 间，房价 ¥700；备用酒店 E 云栖亚朵 S（2.0km，200 间）确认有房 8 间，房价 ¥660。
20:30
324 > 310 → 缺口 14 间。判定信号成立
+10 min
把 14 位最低优先级的 STD/SUP 客人升级到 DLX（升 1 档，符合表 J），腾出 14 间 STD/SUP。
按表 J 四级排序挑人：优先升级非会员且预订价低的客人（因为他们排在升级队列最末，但本场景是「必须腾房」，所以逻辑反过来——优先动排在队尾的人，把好房间留给高等级会员）。
套房升级额度核查：本次不涉及套房（只升到 DLX），无需 L3 审批；若需升到 STE，则当日上限 3 间且须 L3 批。
实际缺口 3 间 → 启动《步行客人预案》，表 L 优先级 1，覆盖一切。
步行客人预案执行（3 位客人）
| 客人 | 会员等级 | 本店成交价 | 去向 | 第 1 步 | 第 2 步 | 第 3 步 | 第 4 步 |
|---|---|---|---|---|---|---|---|
| 客人 A | 钻石 | ¥580 （STD-K 协议价） |
A 江畔万枫 （1.2km，¥700） |
差价 ¥220 + 交通 ¥80 = ¥300 |
升级券 1 张（升 1 档 + 双早，值 ¥100 + ¥256 = ¥356） | 5,000 积分 | 总经理预签致歉信 + 值班经理全程跟进 |
| 客人 B | 非会员 | ¥660 （SUP-K BAR） |
A 江畔万枫 （¥700） |
差价 ¥40 + 交通 ¥80 = ¥120 |
升级券 1 张（¥356） | 不适用（非会员） | 致歉信 + 跟进 |
| 客人 C | 金卡 | ¥660 （SUP-K 会员价） |
E 云栖亚朵 S （2.0km，¥660） |
差价 ¥0 + 交通 ¥120 = ¥120 |
升级券 1 张（¥356） | 5,000 积分 | 致歉信 + 跟进 |
| 直接成本合计 | ¥540 | ¥1,068 | 2 人 × 5,000 分 ≈ ¥100 |
人力 + 信函 ≈ ¥300 | |||
对照：本日超售 9 间带来的增量收益 9 间 × 平均 ¥640 ×（1 − 渠道综合成本率 10%）= ¥5,184
净结果 5,184 − 2,008 = +¥3,176（仍为正，超售策略本身成立）
本日超售 9 间，最终送走 3 人，直接成本 ¥2,008，但超售带来的增量净收益 ¥5,184，净赚 ¥3,176。
策略是成功的。需要改进的只是执行细节：20:30 才判定缺口，如果能在 18:00 就开始升级腾房，客人的等待时间会短很多，补偿成本中的「客人情绪成本」也会下降。
复盘的正确方向不是「不该超售」，而是「判定缺口的时间点要提前」。这就是表 L「复盘」列写「重算表 E 参数」而不是「禁止超售」的原因。
事后复盘（7 天内完成）
| # | 复盘项 | 结论 | 动作 |
|---|---|---|---|
| 1 | 重算 No-show + 取消率 | 本月实际 17%，表 E 计算时采用 14%，高出 3 个百分点 | 仍在「15–20%」档内（基准 5%），但已接近下档边界。下月改用 17% 重算 |
| 2 | 修正系数是否漏项 | D3 平峰（×1）、担保 45%（×1）、会议 18%（×1）、协议 38%（×1）→ 无漏项 | 无 |
| 3 | 备用酒店假设 | 两家备用酒店当日均有房，假设成立 | 无 |
| 4 | 重设未来 30 天超售上限 | 按 17% 重算：17% 落「15–20%」→ 基准 5%，无修正 → 312 × 5% = 15.6，硬上限 15 → 15 间 | 上限从 9 间提高到 15 间，但在《调价台账》备注写明「No-show 参数已升至 17%，连续 2 个月观察后再定是否稳定」 |
| 5 | 流程改进（本条最重要） | 缺口判定时间 20:30 太晚 | 增加 18:00 缺口预检：18:00 做一次实时比对，若缺口 >0 立即启动升级腾房，不必等到实际到店 |
十四、学员跟练（6 题）
要求：每题限时 12 分钟，先独立作答再展开答案。凡涉及超售计算的题，必须写出完整的三步法过程。
请：① 算预测 OCC 并定表 B 的行；② 写出四列动作与落位方式；③ 说明 CTA 这一列在本例怎么判断。
查看答案与解析
② 四列动作：
MinLOS = 2 晚 → 落位：在限制条件中，按「10/24 × 全 10 房型 × BAR 及衍生价」写入最少住期 2（不含 CORP 与 GDS 价，避免误伤商旅客）。现状 1 晚（不设限）→ 改为 2 晚。
CTA = D1 日启用 → 本日为 D2 高涨日，非 D1 → 不启用。
低价渠道 Stop Sell = 关闭尾房特惠 → 本店侧 + 渠道侧两层都关；团购与批发商本档不要求关闭（只在 ≥95% 行才要求）。
超额预订 = ≤2 间 → 直接设 2 间，不查表 E。
③ CTA 的判断方式：CTA 列在「90–95%」行写的是「D1 日启用」，这是一个条件式取值——必须先查目标日的需求等级代号。本日为 D2（HIGH），不是 D1（PEAK），所以条件不成立，不启用。
易错点：把「D1 日启用」读成「启用」，或读成「待定」。正确读法是「仅当该日为 D1 峰值日时启用，否则不启用」。
补充：若本日预测 OCC 是 96.0%（≥95% 行），CTA 列直接写「启用」，此时不看需求等级，一律启用。
请：① 判断是否需查表 E；② 完整走三步法算出超售上限；③ 按房型分配（写出每档配额与余数补齐过程）。
查看答案与解析
② 三步法：
第一步：11% 落「10–15%」档 → 基准超售率 = 3%
第二步：D1/D2？否（D3）→ ×1；担保 58% > 60%？否（58 < 60）→ ×1；会议团队 22% > 40%？否 → ×1；协议集中度 62% > 50%？是 → × 0.8
修正后超售率 = 3% × 0.8 = 2.4%
第三步：有备用酒店 → 不减半，最终 2.4%
超售间数（未取整）= 312 × 2.4% = 7.488
硬上限①：312 × 5% = 15.6 硬上限②：15
min(7.488, 15.6, 15) = 7.488 → 向下取整 = 7 间
超售上限 = 7 间
③ 房型分配：分配基数 = 312 − 套房 10 = 302 间（注意：本例可售 312 而非 320，OOO 8 间分布未知，本学院统一按「套房间数 10 间不参与」扣减，得 302）
STD-K：70 ÷ 302 × 7 = 1.623 → 1（余 .623）
STD-T：50 ÷ 302 × 7 = 1.159 → 1（余 .159）
SUP-K：60 ÷ 302 × 7 = 1.390 → 1（余 .390）
SUP-T：40 ÷ 302 × 7 = 0.927 → 0（余 .927）
DLX-K：45 ÷ 302 × 7 = 1.043 → 1（余 .043）
DLX-V：15 ÷ 302 × 7 = 0.348 → 0（余 .348）
EXE-K：25 ÷ 302 × 7 = 0.579 → 0（余 .579）
EXE-T：5 ÷ 302 × 7 = 0.116 → 0（余 .116）
取整合计 = 1+1+1+0+1+0+0+0 = 4，需补 3 个名额
余数排序：SUP-T .927（第 1）、STD-K .623（第 2）、EXE-K .579（第 3）、SUP-K .390（第 4）…
最终分配：STD-K 2 / STD-T 1 / SUP-K 1 / SUP-T 1 / DLX-K 1 / EXE-K 1 / DLX-V 0 / EXE-T 0 = 7 间 ✓
易错点提醒：担保占比 58% 是精心设计的数字——刚好差 2 个百分点不触发 ×0.5。这类「差一点」的数字在考试和实务中都会出现，必须严格比大小，不许四舍五入。
请：① 先查表 B 判断要不要超售；② 即便如此，仍走一遍表 E 三步法验证；③ 说明三重约束分别是哪三条。
查看答案与解析
② 表 E 验证（仅作演示）：
第一步：9% 落「5–10%」档 → 基准 = 2%
第二步：D1 峰值日 → ×0.5；担保 82% > 60% → ×0.5；会议 5% ≯ 40% → ×1；协议 30% ≯ 50% → ×1
修正后 = 2% × 0.5 × 0.5 = 0.5%
第三步：无备用酒店 → 超售率减半：0.5% × 0.5 = 0.25%
超售间数 = 320 × 0.25% = 0.8；硬上限 16 / 15 未触及
向下取整 → 0 间
③ 三重约束：
约束 1（最硬）：表 B「≥95%」行直接规定「不超售」。这是优先级 2 的表 B 给出的结论，根本不需要进入表 E。
约束 2：无备用酒店 → 超售率减半（表 E 第三步第 3 条）。
约束 3：向下取整把 0.8 变成 0。
三条叠加，结果必然为 0。
教学要点：查表顺序永远是「先表 B 定要不要超售，再表 E 定超多少」。若顺序反了，直接套表 E 会算出 2% × 0.5 × 0.5 = 0.5% → 320 × 0.5% = 1.6 → 1 间，在峰值日多超售 1 间，而这一天您几乎不可能找到地方送走客人。
请：① 估算损失房晚（STD-K 共 70 间，同期其余房型平均 OCC 78%，STD-K 历史占比 22%）；② 说明三重保险中哪几重失效了；③ 写出补救动作与后续防复发措施。
查看答案与解析
过期天数 = 9/26 至 9/30（含）= 5 天
全店日均已售房晚 = 320 × 78% = 249.6 间
STD-K 历史占比 22% → 日均应售 STD-K = 249.6 × 22% = 54.9 间
5 天损失房晚 ≈ 274 间；按 STD-K 平峰 BAR ¥580 ×（1 − 渠道综合成本率 10%）= 净 ¥522/间
直接经济损失 ≈ 274 × 522 = ¥143,028
注：这是保守估算——实际还有一部分需求会转移到 SUP 等更高房型（升档销售），真实损失会低于此数；但也会有对价格敏感的客人直接流失，真实损失也可能更高。报告时应写明估算口径与不确定性。
② 三重保险的失效情况：
保险一（设置即登记）：失效。若已登记进《限制条件存量清单》并填了到期日 9-26，则下面两重至少有一重能拦住。5 天未被发现，高度怀疑根本没登记。
保险二（每日扫描）：失效。9/26–9/30 连续 5 天的 08:30 扫描都没有筛出这一行。要么扫描动作根本没执行，要么清单里没有这一行。
保险三（周一全量对账）：部分生效。9 月 30 日（周一）的对账发现了问题——这是唯一起作用的一重，但晚了 5 天。
根因：保险一没做。后面两重都依赖于第一重产生的清单。
③ 补救与防复发：
补救：① 立即撤除（本店侧 + 渠道侧两层），按撤除五步法执行并试订验证；② 在《调价台账》登记为事故，备注写明「过期 5 天，损失房晚约 274 间，直接损失约 ¥143,028」；③ 上报 L2 与驻店经理；④ 立即筛查 9/26–9/30 期间被 OTA 拒单的客人，能召回的做定向挽回（直销专享价 + 会员积分）。
防复发：① 把「设置即登记」写入 L1 的岗位操作卡，未登记的限制条件视为未设置，不得执行；② 在《限制条件存量清单》加一列「登记人」，与设置人交叉复核；③ 把周一全量对账改为每日晨会（10:05）口头确认一次到期项，把周期从 7 天压到 1 天；④ 用系统的限制条件报表做自动导出（见 M04 第 12 节自动化改造第 5 条），不依赖人工维护的清单。
甲：钻石，预订价 ¥680，住 2 晚，复购 5 次
乙：铂金，预订价 ¥820，住 1 晚，复购 20 次
丙：钻石，预订价 ¥660，住 4 晚，复购 3 次
丁：钻石，预订价 ¥680，住 2 晚，复购 9 次
戊：银卡，预订价 ¥880，住 7 晚，复购 31 次
己：金卡，预订价 ¥750，住 3 晚，复购 1 次
请：① 给出完整排序与理由；② 指出哪两位入选；③ 若第 3 位客人坚持要升到 STE 套房，该怎么处理？
查看答案与解析
第 1 级 · 会员等级：钻石 {甲、丙、丁} > 铂金 {乙} > 金卡 {己} > 银卡 {戊}。
3 个名额全部在钻石组内产生，乙、己、戊本轮无份。
（关键：戊的 ¥880 最高、住 7 晚最久、复购 31 次最多，但他是银卡，第 1 级就被淘汰了，后面三项都不再比。）
第 2 级 · 同档内比预订价：丙 ¥660 < 甲 ¥680 = 丁 ¥680 → 丙出局。
第 3 级 · 同价比入住天数：甲 2 晚 = 丁 2 晚 → 平手，进入第 4 级。
第 4 级 · 复购次数：丁 9 次 > 甲 5 次 → 丁第 1，甲第 2。
第 3 名回到钻石组剩余者：丙（第 2 级被淘汰，但钻石组只有 3 人，第 3 个名额仍给丙）。
完整排序：① 丁 ② 甲 ③ 丙 ④ 乙 ⑤ 己 ⑥ 戊
② 入选：丁、甲、丙，均从 SUP 升到 DLX（升 1 档，符合表 J「最多升 1 档」）。
③ 若第 3 位客人坚持升到 STE 套房：
SUP → STE 是连跳 2 档（SUP → DLX → STE），表 J 明令禁止，除 L3 特批。
处理步骤：① 明确告知客人：按规则最多升 1 档（到 DLX）；② 若客人不接受，不得擅自办理，立即发起 L3 特批，说明客人等级、原因、原房型与目标房型；③ 取得 L3 书面确认后办理，并在《升级台账》第 7 列「升档数」填 2、第 10 列「审批人」填 L3 姓名、备注写明特批理由；④ 若涉及套房，还要核查当日套房升级是否已满 3 间，满 3 间则即使 L3 特批也不得办理（两条硬约束独立生效）。
替代方案（不占用套房额度）：升级到 DLX + 赠送双早（¥256）+ 行政酒廊权益，成本远低于套房，且不受 3 间额度限制。这是前厅应优先提出的方案。
请：① 按四步补偿包逐项写出对两位客人的处置；② 估算直接成本；③ 写出事后复盘必须做的四件事。
查看答案与解析
第 1 步 · 安排同档酒店 + 承担差价与交通：
客人 X：B 滨江希尔顿花园（中高端，与本店同档 ✓），房费 ¥720，本店成交价 ¥680 → 差价 ¥40；交通 2.5km 往返打车约 ¥120 → 小计 ¥160
客人 Y：同酒店，房费 ¥720，本店成交价 ¥563 → 差价 ¥157；交通 ¥120 → 小计 ¥277
注意差价按「客人实际成交价」算，不是按 BAR ¥680 算。客人 Y 买的是 STD-K 促销价 ¥563，差价就是 ¥720 − ¥563 = ¥157。
第 2 步 · 下次入住免费升级 1 档 + 双早：
两位各发 1 张券：升级 1 档（X：SUP→DLX，差价 ¥140；Y：STD→SUP，差价 ¥100）+ 双早（¥128 × 2 = ¥256）
X：140 + 256 = ¥396 Y：100 + 256 = ¥356 小计 ¥752
券面必须写明有效期 12 个月，并记录券号。
第 3 步 · 忠诚会员额外补偿 5,000 积分：
仅客人 X（铂金）发放 5,000 积分；客人 Y 非会员，不适用。不按等级差异化——若 X 是钻石，同样是 5,000 积分。
成本 ≈ 5,000 × 约 ¥0.01/分 ≈ ¥50（按 LOY 渠道 4% 综合成本率折算口径记账）
第 4 步 · 总经理签名致歉信 + 值班经理全程跟进：
两位各一封总经理亲笔预签的致歉信（含四项要素：承认超售失误 / 说明已安排的同档酒店与承担范围 / 写明后续补偿 / 留总经理与值班经理直联方式）。
值班经理：送客人上车 → 到店确认入住 → 次日致电确认回本店安排 → 离店后 72 小时内回访。
成本（信函 + 人力）≈ ¥200
② 直接成本合计：160 + 277 + 752 + 50 + 200 = ¥1,439（约 ¥720/人次）
③ 事后复盘四件事（表 L：重算表 E 参数）：
a. 重算 No-show 率与 24h 内取消率：取 11 月全月数据重算，与表 E 计算时采用的历史值对比。若高出 5 个百分点以上，说明输入已过时。
b. 核查修正系数是否漏项：11/12 为 D3 平峰（×1）、担保占比多少？会议团队占比多少？协议集中度多少？逐条回看，看有没有漏乘的 ×0.5 / ×0.8。
c. 核查备用酒店假设：11/12 当日 30 分钟内的同档备用酒店是否真有房？本次 B 酒店有房，假设成立；若无房，第三步的减半是否被正确应用？
d. 重设未来 30 天的超售上限：按修正后的参数重算，并在《调价台账》备注写明「依表 L 复盘重算，原上限 9 间调整为 X 间」。
产出物：《超售过度复盘报告》，7 天内完成。
十五、判定表默写清单
- 《法典》表 B 的 5 行边界：≥95% / 90.0–95.0% / 85.0–90.0% / 70.0–85.0% / <70.0%（含下界不含上界）
- 《法典》表 B 的四列：MinLOS / CTA / 低价渠道 Stop Sell / 超额预订（四列同时配置，不是四选一）
- 表 B 各行的 MinLOS：≥95% → 2 晚（D1 峰值日 3 晚）；90–95% → 2 晚；85–90% → 1–2 晚（周末 2 晚）；70–85% → 1 晚；<70% → 不设限
- 表 B 各行的 CTA：≥95% → 启用；90–95% → D1 日启用；其余三行 → 否
- 表 B 各行的超额预订：≥95% → 不超售；90–95% → ≤2 间；85–90% → 按表 E；70–85% → 按表 E；<70% → 不超售
- 《法典》表 E 第一步六档：<5%→0%、5–10%→2%、10–15%→3%、15–20%→5%、20–30%→7%、>30%→10%（需 L3 审批）
- 《法典》表 E 第二步四个修正系数：D1/D2 → ×0.5；担保 >60% → ×0.5；会议团队 >40% → ×0.5；协议集中度 >50% → ×0.8
- 《法典》表 E 第三步三条硬上限：≤可售房量 5%（云璟 320 间 → 16 间）；≤15 间；30 分钟内无同档备用酒店 → 超售率减半
- 表 E 计算顺序：先减半 → 再比大小（取 min）→ 最后向下取整
- 超售房型分配两条规则：套房（STE-B 8 + STE-E 2 = 10 间）不参与；按比例 + 最大余数法补齐
- 《法典》表 J 三个触发条件：① 超售需要腾房 ② 高档房预测空置 >20% ③ 会员权益兑现
- 《法典》表 J 四级排序：钻石>铂金>金卡>银卡 → 同档内预订价高者先 → 同价入住天数长者先 → 相同复购次数多者先
- 《法典》表 J 两条硬约束：最多升 1 档（禁连跳 2 档，除 L3 特批）；套房升级每日 ≤3 间且须 L3 审批
- 《升级台账》表 J 要求的三个必记项：原因、房号、会员等级
- 《步行客人预案》四步：① 同档或更高档酒店 + 承担房费差价与交通费 ② 本店下次升级 1 档 + 双早 ③ 忠诚会员 5,000 积分 ④ 总经理签名致歉信 + 值班经理全程跟进
- 限制条件撤除五步法：查到期日 → 两层都撤 → 试订验证 → 截图存证 → 台账登记 + 清单更新
- 《限制条件存量清单》8 个字段，其中第 6 列「到期日」= 生效结束日的次日
- 三重保险：设置即登记 / 每日 08:30 扫描（3 分钟）/ 每周一全量对账
十六、随堂测（5 题）
查看答案与解析
解析：CTA（Closed to Arrival，不可入住）的作用点是入住日——它拒绝「以该日为入住日的新订单」，但已经在住的客人可以正常延续跨过这一天。
Stop Sell（停售/关房）是把该房型/价格代码/渠道在某日整体置为不可售，与库存余量无关，任何人都订不到。
误用后果：若本想做 CTA（挡新客、保留续住）却设成了 Stop Sell，会把已经在住客人的续住请求一起挡掉——系统会把续住视为「该日的新预订」而拒绝。结果是：满房日的续住客人在前台被告知「系统订不了」，引发严重客诉，且前厅需要用手工单绕开系统，造成房态与账务不同步。
反之，若本想 Stop Sell 却设成 CTA，房间仍会被延续入住占用，达不到腾房目的。
查看答案与解析
解析：正确顺序是——① 修正后超售率 × 0.5 → 最终超售率；② 超售间数（未取整）= 可售房量 × 最终超售率；③ 取硬上限 min(未取整值, 可售×5%, 15)；④ 最后向下取整。
错误示范：假设修正后超售率 3%，可售 320 间。
正确：3% × 0.5 = 1.5% → 320 × 1.5% = 4.8 → 4 间
错误（先取整再减半）：320 × 3% = 9.6 → 取整 9 间 → 9 ÷ 2 = 4.5 → 4 间（本例巧合相同）
换个数字就能看出差异：修正后超售率 1%，可售 320 间。
正确：1% × 0.5 = 0.5% → 320 × 0.5% = 1.6 → 1 间
错误：320 × 1% = 3.2 → 取整 3 → 3 ÷ 2 = 1.5 → 若再取整得 1 间，若不取整得 1.5 间（非法，房间不能是小数）
更关键的是「超售率减半」而非「间数减半」在大幅超售时的差异：若修正后 10%、可售 312：
正确：10% × 0.5 = 5% → 312 × 5% = 15.6 → 硬上限 15 → 15 间
错误：312 × 10% = 31.2 → 硬上限 15 → 15 → 15 ÷ 2 = 7.5 → 7 间
两者相差 8 间。所以顺序必须对。
查看答案与解析
解析：表 J 的四级排序是严格按序的层级判定，不是加权打分。第 1 级（会员等级）就能分出胜负时，后面三级根本不再比较。
钻石 > 银卡 → 第 1 级已定胜负 → 钻石会员先升。
「预订价高者优先」是第 2 级规则，只在第 1 级打平时才启动——即两个都是钻石、或两个都是铂金时，才去比谁的原预订价高。
这个规则的设计意图：会员等级代表客人的长期价值，预订价只代表本次交易的金额。一个钻石会员即使是本次订了低价房（比如用了积分或协议价），他的生命周期价值仍高于一个偶尔订高价的银卡会员。
常见错误：把四级规则当成「综合评分」加权计算，这是彻底误读。表 J 写的是「执行顺序（严格按序）」。
查看答案与解析
解析：排除套房的两个理由：
① 统计意义不足。云璟套房共 10 间（STE-B 8 + STE-E 2），占房量 3.1%。按 3% 的比例分配，10 间 × 超售率只能分到零点几间，对整体超售目标贡献微乎其微。
② 失败代价不对称。超售失败时，把付 ¥1,280 的套房客送走，补偿成本（需安排同档或更高档的套房，本区域同档套房极少且极贵）+ 客诉烈度（套房客通常是高价值或纪念日客人）+ 忠诚会员流失风险，远高于多卖一间标准房的收益。
若一定要给套房设超售：① 必须 L3 特批，写明理由；② 单独计算，不纳入表 E 的常规分配基数（即 310 间的分配不受影响）；③ 必须有确定的同档或更高档套房作为备用（普通房不算「同档」）；④ 在《超售日监控表》与《升级台账》中单独标记。
本学院立场：默认不给套房设超售。上表的四个条件只是「万一要做时的最低要求」，不是鼓励去做。
查看答案与解析
解析：具体例子：9 月 19 日设 MinLOS = 2 晚时，操作人按房型逐个设置，设了 STD-K / STD-T / SUP-K / SUP-T / DLX-K 五档（当时只想着挡散客主力房型）。撤除时，操作人在「限制条件」页面按日期批量清空——但系统里 MinLOS 是按「日期 × 房型 × 价格代码」存的，批量清空只清了当前筛选条件下显示的那几档，DLX-V / EXE-K / EXE-T 三档的 MinLOS = 2 仍在生效。
表现：9 月 20 日起，STD 与 SUP 能订 1 晚，但 DLX-V / EXE-K / EXE-T 只能订 2 晚以上。OTA 上这三个房型显示「不可订（1 晚）」，客人以为售罄。而收益专员看「全店可售房量」是正常的，完全看不出问题。
后果：这三个房型共 45 间（DLX-V 15 + EXE-K 25 + EXE-T 5），占房量 14%，在平峰日连续多天接不到单晚商务客。
试订验证能拦住它：按表 7-6 的试订矩阵，撤 MinLOS 后要试订「该日入住 1 晚」——但必须逐房型试订，不能只试一个房型。若只试 STD-K 成功就认为撤干净了，仍会漏掉 DLX-V / EXE / EXE-T。
所以试订验证的操作标准是：逐房型、逐价格代码试订，并把试订成功的页面截图存证。
十七、本模块产出物
- 《库存与限制条件配置卡》——表 B 的 5 行 × 4 列一页纸版，含四列的执行要点与易错点，前台与收益人手一份
- 《限制条件存量清单》——8 字段，含「到期日」列；设置为生效中时必登记，撤除后更新状态
- 《撤除五步法检查卡》——含表 7-6 试订矩阵（逐房型、逐价格代码），贴在工位
- 《超售计算表》——表 E 三步法的 Excel 自动计算模板，输入 5 个参数自动输出超售上限与房型分配（含套房排除与最大余数法）
- 《超售日监控表》——8 字段，含超售余额自动告警（余额 ≤0 时标红并提示关闭超售）
- 《升级台账》——11 字段，含升档数自动标红（>1 即触发 L3 特批核查）与套房每日 3 间额度自动计数
- 《步行客人预案包》——备用酒店名单模板（含实时房态确认栏）+ 四步补偿包执行单 + 总经理预签致歉信模板 + 补偿成本速算表
- 《超售过度复盘报告》模板——四项复盘动作（重算 No-show、核查修正系数、核查备用酒店、重设 30 天上限）
- 表 B / 表 E / 表 J 默写卷——当堂完成，错一格重默
库存管好了，接下来要管「这些房间通过谁卖出去」。M08 渠道与分销管理会把《法典》表 H（渠道开关判定表，6 档 OCC × 5 类渠道）讲透，并回答一个本模块埋下的伏笔：表 B 的「低价渠道 Stop Sell」列到底在关哪些渠道、关了之后少赚多少。
您会学到 7 个渠道的真实成本（直销 3%、会员 4%、协议 8%、GDS 13%、OTA 国内 16%、OTA 国际 18%、批发商 26%），以及一个反直觉的结论：OTA 卖 ¥600（净 ¥504）不如直销卖 ¥530（净 ¥514）——便宜 70 元反而多赚 10 元。理解了这一点，您才会明白为什么表 B 要在旺日去关那些看起来「卖得很好」的渠道。