暑期档收官、开学季临近，一个酒店人聊聊动态定价怎么落地

暑期档电影票房刚破 117 亿收官，开学季的脚步也近了。对酒店人来说，这意味着一件事：从 7、8 月的旺季，正式转入 9 月的平季。

房价该怎么定？这是每年这个时候最让人纠结的问题——定高了怕空房，定低了怕少赚。

我在酒店行业干了近10年，参与过从工地到筹建的全过程。这篇聊的"动态定价"，不是什么高深算法，而是酒店经营里最朴素也最值钱的一件事：让房价跟着真实需求走，而不是跟着感觉走。

一、先搞懂：动态定价的核心，是 RevPAR 倒推

前面几篇我们反复提到三个数：入住率 Occ、平均房价 ADR、每间可售房收入 RevPAR（RevPAR = Occ × ADR）。

动态定价的本质是：先定一个"目标 RevPAR"，再倒推"我需要什么入住率、配什么房价"。

举例：一间 100 间房的酒店，昨天满房（Occ 100%）但 ADR 只有 400，RevPAR 才 400；今天空一半（Occ 50%）但 ADR 涨到 700，RevPAR 还是 350。两种都不理想。

聪明做法是：旺季前看历史，知道某个周末常年满房，那就敢把 ADR 从 400 提到 650——满房状态下，每多 100 元房价，RevPAR 就多 100。而平季空房多时，与其守着高价空着，不如降到能填满入住率的价位，空房间每多住一间都是纯增量。

这就是"倒推"：不是先想"我要卖多少钱"，而是先想"我要这天 RevPAR 到多少"，再反算价格。

二、AI 在这个环节能帮什么忙？

说实话，倒推逻辑一个 Excel 就能算。真正难的是两件事：预测明天/下周的需求，以及解释为什么该这么定。

大模型擅长的是后者。把过去一年的价格、入住率、竞对价格、本地事件（会展、节假日、考试季）整理成表格，喂给模型，它能直接回答：

• "去年开学前两周，周中入住率掉到多少？我今年该提前几天降价？"
• "会展那几天，我的 ADR 比周边同档低了多少？下次怎么跟？"
• "哪些日期是'满房但房价偏低'的漏钱点？"

这里有一个很新的行业动向值得说：腾讯高管汤道生这两天明确表态，"场景是 AI 最厚的底牌"，很多产品会同时接多个模型，按能力强弱和价格高低，把任务分派给最划算的那个。这句话我深以为然——动态定价这种活，高频的历史数据分析用便宜模型跑，关键的策略建议才动用强模型，成本结构才健康（这也是我前面成本篇讲过的"模型分层"）。

同时，元宝这两天刚升级了长文本和表格问答能力，对酒店这种"数据都在 Excel 里"的场景，正好是刚需。

三、落地三步（复用前面架构）

• 数据层：把 PMS 历史价、入住率、竞对价、本地事件日历汇总起来（接第 1 篇的经营看板，数据先"上线"）。
• 模型层：用大模型做需求归因和价格建议，规则引擎负责把建议转成可执行的调价区间。
• 应用层：每周给店长推一份"下周建议价"，附理由，店长确认后下发各渠道。

三个踩坑提醒

• 坑一：只涨不降。旺季敢涨，平季不敢降，结果空房更亏。动态的核心是"双向"，降对了比涨对了更显功力。
• 坑二：把 AI 当黑盒。模型给的建议必须能解释"为什么"，店长要懂逻辑才能拍板，否则就是换个地方拍脑袋。
• 坑三：忽略客人预期。渠道展示价要一致、预付与到店价要透明，别踩价格欺诈的红线。

写在最后

动态定价不是"让房价变来变去"，是让每一个价格都对应一个真实的需求判断。8 月底这个旺季转平季的节点，正是最好的练习场。

本系列围绕"酒店数字化 + 腾讯云"展开：经营看板、大模型复盘、多模态开源模型、AI 成本账、机器人落地，到这篇的动态定价——下一篇聊聊 AI 智能体（Agent）怎么在门店真正跑起来，把前面这些能力串成一条自动化流水线。

我是薇妹Wynn，我们下次见。