马来西亚 homestay 用 channel manager，能不能真正挡住重复订单，看的不是「有没有同步」，而是它怎么处理那些安静的失败：推了一半被当成功、系统断线期间的订单、把改期当成重复、打款跟订单对不上。这是我们在新山和 Desaru 管 100 多间单位踩过的 7 个坑，和每个坑的检查方法。
Google 上每一个 channel manager 的页面都写同一句话：「实时双向同步，告别重复订单。」我们当年也信。后来单位过了 100 间，同时接着 Airbnb、Agoda、Booking.com 和自己的直订网站，才发现真正花钱的问题从来不是明摆着的那种。日历看起来是同步的，钱还是短。
下面不是功能清单，是按「亏过的顺序」排的出事清单，每一条配上我们后来写进 AntlerHub 的规矩。如果你在马来西亚做 homestay，正在挑 channel manager，先把这 7 个问题丢给销售，再问价钱。
为什么日历明明「已同步」还是会重复订单？
因为「推送成功」和「每一天都被接受」是两回事。
你一次推 14 晚的价格或空房，有些渠道会回一个「部分成功」：11 天收了，3 天拒了，原因通常是你从没看过的规则——最低价保护、某天被关、某个价格方案过期。很多系统把这种回应记成成功，因为那次网络请求本身没失败。被拒的那 3 晚继续用旧价卖，或者你想关却还开着。
我们的规矩是：只要有一天没交代清楚，整次推送就算失败。 渠道说「部分接受」但不讲是哪几天，我们把整笔当失败、重推。它有列出失败日期，就只把那几晚丢回队列，收下的不动，免得撞渠道的频率限制。
问销售一句：「Agoda 收了 14 天里的 11 天，我会看到什么？」如果答案是「一个绿色勾」，你的第一笔重复订单已经在路上了。
系统断线期间进来的订单去哪了？
消失了。无声无息。客人站在门口你才知道。
任何连线都会断：你的服务器重启、渠道那边故障、凌晨两点 token 过期。一个天真的同步程序恢复后问「从现在起有什么新的？」，等于把断线期间进来的订单全部丢掉。没有报错。客人手上有 Airbnb 的确认，你的日历那晚是空的，而且很可能已经再卖一次。
我们的规矩是：同步进度永远不推到「现在」，只推到上一个真正处理完的时间窗的末端。重启之后从停下的地方接着跑，把断掉那段补回来。如果断的时间比渠道允许回看的范围还长，那就标成「真实、不可恢复的资料遗失」，当天由人手去渠道后台逐条核对。很无聊，但这就是这份工。
客人改订单，算新订单还是重复订单？
这题很细，而且两个方向都会咬人。
客人从住 2 晚改成 3 晚，渠道把同一个订单号再发一次，日期不一样。如果你的系统只用订单号去重，它会说「这个看过了」，把延住丢掉——第三晚还在卖。反过来，如果每条讯息都当新的，同一个入住在日历上出现两次，清洁阿姨被派去一间还有人住的房。
我们的规矩是：改订单＝同一个订单号＋更新的版本号，而且是新工作。 去重用订单号加版本号，由数据库的唯一键强制，不是先查「我看过没有」——因为两个轮询程序可能同一瞬间查，两个都说没有。我们还留一份讯息内容的指纹：同一个订单号同一个版本却带着不同日期进来，直接浮给人看，不悄悄合并。
换 channel manager 的那一周，日历归谁管？
如果不小心，大约一个星期是没人管的。那个星期就是房间被卖两次的时候。
换系统是 homestay 营运里最危险的一刻。旧系统还连着，因为新的还没测完；新系统在两个渠道上线了，第三个还没。两边都往 Agoda 推空房，各自以为自己是唯一的声音。
我们的规矩是：推送权是「每个房源、每个渠道」记录在数据库里的事实，不是代码里的假设。 一个房源同一时间只属于一个系统。新系统不会往它不拥有的渠道推，哪怕对应关系建好了、价格也准备好了。而且它拒绝在渠道那边的 property ID 还没登记之前接手——否则的下场很难看：旧系统被叫停，新系统推送失败因为没地方可送，这个房源现在挂在一个没人更新的 OTA 上。
我们自己的 FAQ 讲得很白：日历只能由一个系统掌管。我们先把你现有的订单导入，再在你选的日期切换，不会提前。
「已取消」有几种写法？
比你想的多，而且错的方向永远是危险的那边。
我们收过的订单资料里出现过 Cancelled、cancelled_by_guest、CANCELED、Cancelled by host，还有更多。一份精确的「取消状态清单」在渠道改措辞之前都是对的；改了之后失败是无声的：没认出来的取消会被当成有效订单。 那晚继续被锁，房间空着，屋主月结少一笔，没人解释得出为什么。
我们的规矩是：状态里含有「cancel」字样的一律释放那晚，no-show 也释放。no-show 这条比听起来重要。一个没出现的客人隔天才到、硬是在入住环节混过去，否则会拿到一间已经卖给别人的单位的门锁密码。
顺带讲日期：所有计算都按马来西亚墙上时钟（UTC+8），退房日一律算不含。半夜到早上八点之间，一台设成 UTC 的服务器还以为是昨天——今早退房的客人就是这样被系统问要不要「延到明天」。
为什么房间脏了、在维修，还是挂着在卖？
因为我们知道的 channel manager 没有一个——包括我们自己的——知道清洁阿姨和维修师傅知道的事。
这是同步的诚实上限。Channel manager 在你的日历和渠道之间搬三样东西：价格、空房、订单。它不知道 12 号单位被弄到要清四个小时不是两个小时，也不知道热水器在退房时坏了。AntlerHub 里每间单位有翻房状态（可售、有人住、待清洁）和维修状态（待修、维修中、已修好），清洁团队和维修师傅都看得到，但标成「待清洁」或「维修中」的单位不会自动从渠道下架。空房只由订单决定，就这样。
我们考虑过自动化，暂时决定不做。旺季单位 100% 入住的周末，清洁阿姨下午三点手滑点了「待清洁」，损失的销售远大于它偶尔救到的一次当天维修。所以这条规矩是营运的，不是技术的：维修会拖到下一组入住时，由营运负责人手动关日期，维修工单带着单位和截止时间。销售跟你说他们的同步「有处理维修」，问清楚到底什么会触发下架、谁可能不小心触发。
为什么平台打款跟订单对不上？
因为打款单和订单资料从来就不是设计来互相吻合的，而只同步日历的 channel manager 永远不会让你看到差在哪。
Airbnb 或 Agoda 上的一笔订单是别人欠你的钱，不是你有的钱。几个星期后钱才到，扣掉佣金，有时一笔打款包 40 个入住，有时一笔马币转帐里夹着新币或美元的行。Agoda 和携程的汇款单常常根本没有确认码，只有客人名字和入住日期。
我们的规矩，也是建议你拿去问任何供应商的：
- 没有人看过的东西不入帐。 对帐单是人做出来的档案：选错分页、选错月份、同一个档拖进去两次。每次导入先生成草稿批次，营运确认了才过帐。
- 对不上的行照样导入、打标、留着可查。 银行入帐是真的，不管后面每一笔订单叫不叫得出名字。
- 配对要严。 先用确认码；没有确认码的，客人名字和入住日期两个都要对上，名字有歧义就留着不配，不去猜——猜错一次，钱就悄悄记到别的屋主头上。
- 混币种不换算。 一笔转帐里的明细加起来对不上总额、原因是有几行是新币，系统就照实讲，按声明的金额入帐。
- 同一份对帐单再导一次，只更新还没过帐的批次，已过帐的不碰。
多屋主的营运，钱大多从这里漏。日历同步是入场券，结算对帐才决定你的屋主月结对不对。
7 个坑一张表
| # | 出什么错 | 看起来像什么 | 检查方法 |
|---|---|---|---|
| 1 | 推了一半被当成功 | 3 晚还在用旧价卖 | 「部分成功但没明细」算失败、重推 |
| 2 | 断线后从「现在」继续 | 客人拿着你没见过的订单到门口 | 进度只推到上一个处理完的时间窗末端 |
| 3 | 改订单被当重复丢掉 | 延住那晚还在卖 | 订单号＋版本号去重，数据库强制 |
| 4 | 换系统期间两边都在推 | 切换那周房间卖两次 | 每个房源每个渠道只记一个推送拥有者 |
| 5 | 没认出来的取消写法 | 空房还被锁着 | 含「cancel」的状态和 no-show 都释放 |
| 6 | 待清洁／维修中还在卖 | 客人站在正在修的单位门口 | 不是同步问题：营运手动关日期，维修工单带截止时间 |
| 7 | 打款跟订单对不上 | 屋主月结短一截，没人知道为什么 | 草稿批次、严格配对、混币种标记 |
马来西亚 homestay 用 channel manager 要多少钱？
比较供应商时，拿到「每间单位每月」的数字，而且确认里面包含 channel manager，不只是日历。
AntlerHub 公开的价格所有人一样：每积分 RM 1.50，每个在线单位每月用 10 积分，也就是每间每月 RM 15（未含 SST）。这包含全部渠道的 channel manager、直订网站和自助入住、AI 回 WhatsApp、押金和收款、屋主门户和派款。新账号送 50 积分，够 5 间单位用一个月；没有安装费，积分不过期，没有合约。支付网关手续费由 Stripe 或 Xendit 按它们公布的费率收。最新数字以价格页为准。
到底该买 channel manager，还是继续手动？
5 间以下，老实说，一个有纪律的人拿两支手机跟得上——这要花多少小时我们在自己做 Airbnb 还是交给托管那篇算过。过了 10 间，问题就不再是要不要用 channel manager，而是上面 7 个坑里，你现在用的那个正在无声地犯哪一个。
AntlerHub 是我们为了管自己的单位做出来的系统，这篇里每一条规矩都是先交了学费才有的。与其读，不如用你自己的房源看一遍：AntlerHub 页面可以申请演示，30 分钟、走你的单位，不是看简报。