你最喜欢什么?
Little Hotelier 让在各大OTA上在线销售客房变得简单,只需一个平台即可操作。Demand Plus 和 Channels Plus 提升了我们的曝光度和流量,这是我们自己无法实现的,我也喜欢你们在AI渠道上的早期布局,将库存输入到像 ChatGPT 这样的平台,让客房可以在客人搜索的任何地方被销售。就价格而言,它是一个全面的平台:它很好地完成了所有基础功能,也涵盖了相当多的高级功能。支持非常出色,从入门团队到实时聊天,回复都很迅速。Live Chat 的 Ravi 是一个很好的例子,而 AI 助手 Sim 比我预期的更强大。
您不喜欢或认为可以改进的地方是什么?
先说两个主要的问题,然后是其他的。我直言不讳,因为这样对你们更有帮助,而不是客套。
1. 让我们设计预订引擎,或者让我们在你们的基础上构建自己的引擎。这个引擎是我们转化率最低的环节,我从分析中可以看出:访客访问我们的着陆页,了解房屋信息,浏览多个页面,输入日期,然后交由 Little Hotelier 引擎处理后离开。那里的退出率是整个流程中最高的,原因在于我们能改变的空间很有限。选择颜色不是定制。每周我们都会被问到的一个例子:一栋一卧室的房子显示一个“4”的人形图标,实际上是两位成人、一名儿童和一名婴儿。这个图标会引起混淆和邮件咨询,我们无法编辑或解释它。我们需要的是要么真正的设计控制,即自定义HTML、CSS和代码注入到引擎中,要么更好的是无头预订API(搜索、报价、预留、预订、支付),这样我们就可以构建自己的前端,直接连接到 Little Hotelier。目前的设计平庸到让像我们这样的酒店考虑迁移到其他系统,以免我们辛苦建立的潜在客户变成预订。
2. API 不够用。获取实时可用性和价格到此为止。没有办法写入价格或限制条件,没有预订到达时的Webhook,没有iCal导出,也没有预订信息流,你们的条款也禁止抓取,因此没有官方授权的方式让运营者的工具对账户进行操作。我们开发了一个脚本,每30分钟轮询一次API,只为在我们网站上显示实时可用性,每次价格变动仍需手动通过网页界面操作。我的团队主要通过AI(尤其是Claude)工作,现在大多数小型运营者也是如此。我们通过让AI构建连接我们的PMS和POS的系统,发展迅速,而 Little Hotelier 是无法连接的部分。一个完善的读写API、Webhook和官方的AI助手集成,将让像我这样的运营者更高效地管理酒店,也会让你们成为客户的首选。
3. 虚拟房间。将多个房间作为一个单元出售,或将一个单元拆分为多个,是我们酒店的基本需求,Cloudbeds 多年来一直支持此功能。我很惊讶它缺失了。
4. 关闭的价格计划显示为“售罄”。当我停止销售某个折扣计划的特定日期时,客人会看到该计划在同一房屋的标准价格旁边显示为“售罄”,让人误以为没有空房。被关闭的价格计划在搜索日期范围内不应出现。相关:没有规则规定“此价格计划不适用于触及这些日期的住宿”,因此唯一的工具是逐渠道停止销售。引擎会自动翻译我们的房屋名称。当客人的浏览器设置为泰语时,“White House”变成ทำเนียบขาว(美国总统官邸), “Turquoise”变成颜色,而我们的描述中夹杂着日语片段。专有名词绝不能自动翻译,我们需要逐语言审查或覆盖翻译。
1. 批量价格更新会默默覆盖。最后保存的价格在某个日期上胜出,因此在一段时间内的基础价格会覆盖已存在的周末和节日价格。没有预览功能,没有撤销,也没有价格变动的审计轨迹。我们现在采用严格的三轮操作顺序,以避免破坏自己的定价策略,任何运营者都不应以失败为教训。
2. 无法控制的标签。每个价格在引擎中都显示“需支付30%押金”,这是由设置开关决定的,无论是否连接支付网关,都如此,也无法编辑或隐藏。与入住图标类似:引擎会告诉客人一些我们未曾说过的内容。
3. 安全措施对每天使用的人来说过于繁琐。频繁登出、每几个月强制更改密码、在应用中也是如此。信任设备、密钥或在已知设备上延长会话时间可以在保证安全的同时减少日常操作的摩擦。虽然令人沮丧,但成本远低于上述问题。
两个较小的问题。Airbnb的长住折扣不通过渠道管理软件管理,因此价格平价只能手动维护。报告也是导出数据而非洞察:我们自己做了分析,了解预订在哪些环节流失,这也是我们知道第一点是真的原因。
感谢您的询问。我们喜欢这个产品,这也是为什么预订引擎和API对我们如此重要。