马来西亚 homestay 动态定价怎么做：我们 100 多间单位在跑的四层价格

马来西亚 homestay 的动态定价，最好拆成四层，而不是一个神奇的数字：每个星期几一个预设价、学校假期和长周末用的季节规则、定时触发的当天／隔天调价（有底价挡着）、还有只给建议不自动推价的同行比价。这是我们在新山和 Desaru 给 100 多间单位定价的方法，也包括每一层会在哪里出问题。

Google 搜「Airbnb 动态定价」，第一页是 PriceLabs、Beyond、Wheelhouse、Hospitable，讲需求系数和机器学习。它们是好工具，但它们是为客人提前几个星期订房的市场设计的。没有一篇是写给这样的业者：星期五晚的客人是星期五下午在关卡才决定的、Agoda 的订单跟 Airbnb 一样多、channel manager 有时会悄悄拒掉一个价格三个星期。这篇文章是我们在 AntlerHub 里真的在跑的定价结构，一层一层讲，包括还是手动的部分，和那个靠代码自己「抱怨」才抓到的失败。

新山 homestay 的「动态定价」到底是什么意思？

意思是客人看到的某一晚的价格，不是你某天打进去的一个数字，而是一叠规则算出来的结果：每个星期几一个基础价，碰到季节规则再调，碰到定时规则再调一次，然后跟附近单位的价格比一比。每一层的任务不同，变动的速度也不同。

顺序很重要。第一层是其他所有东西的地基。如果一间单位某个星期几没有预设价，系统那天就什么都不推——这是故意的，推一个零或乱猜，比不碰 channel manager 更糟。

第一层：为什么预设价要按星期几，不能只有一个数字？

因为新山的 homestay 没有一条需求曲线，是两条。星期五、六晚是新加坡家庭和吉隆坡下来的周末客；星期日到四是另一个市场：出差、看医生、活动外溢。两边用同一个价，要么周末少赚，要么周中空着。我们 Desaru 的单位更明显，Desaru 周末满、周中空那篇讲过。

所以我们 PMS 里每间单位带七个预设价（一个星期几一个），加七个对应的底价。底价是后面任何一层都不能跌破的数字，除非有人在那一条规则上明确勾「允许低于底价」。

每晚马来西亚时间 00:30 到 01:59 之间，排程会把「有效价格」（预设价叠上季节规则）推到 channel manager，但只推刚进入滚动日历窗口的那几天（预设窗口 730 天）。只推新的天。它从不重铺已经推出去的日期，因为那会每天早上把季节、定时和手动改的价全部盖掉。这条规则听起来理所当然，直到你去看工具的论坛，一堆屋主抱怨手动改的价一觉醒来不见了。

有一个细节我们审计之后才做对：以前推送只在 00:30 那一分钟跑。程序刚好在那一分钟重启、或伺服器忙，那天就跳过，而且日历最远那一端的空洞永远补不回来，因为下一次只看最新的一天。现在窗口是 90 分钟，而且是按「距离上次成功推送过了几天」来算，漏掉一晚，隔晚会补上。任何号称「每天跑」的定价系统，都该被问一句：没跑的那天会怎样？

第二层：季节规则怎么设才不会乱？

我们系统里一条季节规则＝一段日期、这段日期里的哪几个星期几、范围（全部单位或指定单位）、一个调整：加或减一个百分比或固定金额。例如：2026-12-18 到 2027-01-03，只限星期五、六，全部单位，+40%。

三个设计决定让它在 100 多间的规模下不会变成一团乱。

规则重叠时取最高价。 学校假期的规则和长周末的规则可能同时盖到同一个星期六。我们不叠加（40% 再加 25% 等于一个没人订的价），也不按先建的算。两条都算，留高的。这是旺季安全的选择：重叠只会把价抬高，不会不小心打折。

按基础价分级调整。 一律 +RM50，对 RM170 的 studio 是跳 30%，对 RM800 的别墅只是 6%。所以一条规则可以带分级：基础价 RM0–200 加 25%、RM201–400 加 20%、RM400 以上加 15%。一条规则就能合理地盖住整个组合。

推送之前全部是草稿。 新建、修改、或把新单位绑进规则，都不会动到任何渠道。规则变灰，意思是「改过但还没推」，业者准备好才推。每次推送按单位记录，Agoda 收了 97 间、拒了 3 间，画面会列出那 3 间让你重推。我们在channel manager 同步最常出错的 7 个地方讲的「部分成功被当成功」，价格跟空房一模一样会中招。用 Excel 批量上传也一样：每一行变成草稿，坏的行按行号报回来，什么都不推。

第三层：定时调价计划是什么？为什么触发时间是固定的？

定时调价计划是一条这样的规则：在这个时间、针对这个入住日期、调这么多。它就是国外工具说的「最后一分钟折扣」，但按这里客人真正的订房习惯来做。

调整可以是百分比或固定金额，可加可减。比触发清单更重要的是两道护栏。

它从渠道的现价调，不是从预设价调。 15:00 排程先问 channel manager 今晚的价到底是多少，再把规则套上去。如果季节规则已经把那晚抬到 RM280，当天减 10% 得到 RM252，不是拿一个过时的预设价减 10%。每条计划对每个目标日期只碰一次（以日期＋触发做键），所以 3pm 那刀和 6pm 那刀不会叠成你没打算的数字。

它遵守星期几的底价。 除非计划明确勾「允许低于底价」，否则算出来的结果会被拉回那个星期几的底价。RM150 的星期六、底价 RM140，减 20% 得到的是 RM140，不是 RM120。这是最重要的一道护栏，因为计划不知道今晚附近有场演唱会卖光了。底价是你的判断，写下来一次就好。

老实的限制在这里：定时计划不会检查那一晚是不是还空着。 它对范围内每一间启用的单位都推调整后的价。已经订出去的那晚，新价格改变不了那张订单，所以不会亏钱，但也表示这一层不是国外工具说的那种「看入住率决定」。我们在自己的规模下接受这一点，因为减的幅度小、底价挡着。如果你只有三间单位、想要系统先看订房速度再决定打不打折，这一层不是那个东西，我们宁可先说清楚。

第四层：AI 同行比价真的做什么？

要用的时候，针对一间单位、一个入住日期，它去 Booking.com 和 Agoda 爬单位座标附近、同样房间数的可比房源，最多 20 家，把它们那一晚的价跟我们在各渠道的价比。它报出市场中位数、我们离中位数几个百分点、一个建议价（中位数；没有中位数就取最低同行加 RM10），和三个字之一：调高、调低、不动。只要我们在正负 8% 以内，答案一律是「不动」，因为 5% 的差距是杂讯，不是讯号。

然后它就停了。它不推任何东西。 一个人看建议再决定。我们是故意这样做的：爬虫可能把青年旅舍的床位当成 studio、漏掉清洁费、或在某个房源日历怪怪的时候拿星期五比星期四。一个会在凌晨两点把这种错误自动套到 100 间单位的工具，不是功能。另外每间单位每个日期有一分钟的冷却时间、跑的时候有八分钟的锁，两个员工不会同时对同一间发两次爬取。座标没填、房间数没填、或状态不是启用的单位，一开始就会被拒——比价只会跟房源资料一样准。

这算是大工具说的那种「AI 定价」吗？不算。它是一个同行快照，上面加一条规则。产品页叫它 AI pricing，是因为爬取和配对用了模型；定价的决定还是人。如果有供应商说他们的演算法「会学你的市场」，请他拿出某一个具体晚上它学的那组比较对象来看。

推价失败、没人发现，会怎样？

这段是我们最不想写、却是整篇最有用的。有好几个星期，我们三间单位每次定时计划推价，channel manager 都回 403 错误。每一次失败都有记录。排程印出来了，资料库存着。没有人被告知，因为一行没人读的 log 是收据，不是讯号。那三间就一直用最后一次被接受的价在卖。

解法不是做一个新的警示画面——那是第二个要看的地方，第二个要看的地方就是会被忘记的地方。解法是一条规则：失败按「计划＋单位」连续计数，连续第三次失败那一刻，系统在员工每天早上本来就会开的那个营运任务清单里开一张任务。不是第一次就开，因为单次超时通常下一轮自己好。不是第三次之后每次都开，因为那会把人淹掉。一次成功就清零；同一间之后再坏，算新的一轮、新的编号，开新任务，而不是悄悄改写一张别人已经关掉的。任务写的是「channel manager 拒收这间单位」，不是「HOSTPLATFORM_403」，因为一张不能动手的任务等于没有任务。

不管你选什么定价工具，问一句：某一间单位的推价连续失败第五天，谁会知道、在哪里知道？

动态定价真的多赚钱吗？我们会说和不会说的

国外工具的说法是比固定价多赚 10% 到 40%。我们不报数字，因为同一段时间里我们的组合在变大、单位类型在变、渠道也在变，没办法干净地把定价规则的效果从其他因素里切出来。跑下来能说的是：星期几预设价加底价，挡掉了最糟的周中低价；季节分级让我们不用在每个学校假期前手动改 100 份日历；当天减价填掉了一些本来会空的晚上，而且是用事先决定的价格，不是晚上七点慌张时定的。

两件事我们不会做：承诺系统比你更懂你的市场；或隐瞒第三、第四层比国外工具的宣传册简单。四层结构就是把你的判断写下来一次，让它每天没有你也在跑，下面有底价撑着，上面有警报看着。

要多少钱？开始要准备什么？

AntlerHub 的公开价是一个价：每个 credit RM 1.50，每间启用的单位一个月用 10 个 credit，等于每间每月 RM 15（未含 SST），新帐号送 50 个 credit，没有设置费、没有合约。四层定价全部包含在内，不是付费加购。最新数字以 AntlerHub 价格页为准。

开始之前每间单位要有：每个星期几一个预设价、每个星期几一个底价（设在「宁可空着也不卖」的那个价）、要用比价的话要有座标和房间数、还有 channel manager 的连接。然后设一条下个学校假期的季节规则，草稿、推送；再设一条针对你最慢的平日晚的当天计划，幅度小一点。跑一个月，看推送记录，然后才加规则。每多一条规则就多一个可能重叠的地方，少而有底价的规则，胜过一叠你已经看不懂的聪明规则。

想在真实的日历上看这四层怎么运作再决定，AntlerHub 页面用的就是我们自己单位在跑的同一套系统。