如何搭建酒店预订网站：房型、房价、可订性与支付

酒店预订网站让客人选择入住日期，查看每个晚上有哪些房间可订，看到总价，然后付款或支付押金——无需任何人来回发邮件。搭建它需要有房型及其房间数量、按晚计算的可订性模型、可按日期变化的房价、在保存时重新检查可订性的预订流程，以及供前台使用的后台视图。真正的难点不在于漂亮的页面，而在于确保同一间房永远不会被卖两次，尤其是当你也在预订平台上销售时。

网站需要什么

页面

• 公开页面： 首页、房间（照片、床型、面积、设施、最多入住人数）、带日期和人数的搜索、按房型显示总价的结果页、预订表单、付款，以及带有管理预订链接的确认页。
• 辅助页面： 位置和交通指引、政策（入住和退房时间、取消政策、儿童、宠物）、常见问题、联系方式。
• 私有页面（员工）： 当天的入住和离店名单、按晚显示房间的日历网格、预订列表、锁定日期、房价和房间设置。

数据

请将入住和离店存储为日期而非时间，并把离店视为不包含在内：从10日入住到12日离店，计入的是10日和11日两个晚上。这一点处理错误，是最常见的可订性缺陷。

权限

客人可以看到价格和某种房型是否可订——但永远不能看到其他住客是谁。前台员工可以看到预订和客人详细信息；只有业主可以修改房价和政策。这意味着需要一个至少有两种角色的员工登录系统。

决策与取舍

申请预订还是即时预订

申请预订——客人发送日期和信息，你通过邮件确认——要简单得多，对小型民宿完全够用。即时预订需要严密的可订性和付款处理，但转化率更高。许多物业先从申请开始，之后再切换。

出售房型还是具体房间

客人通常预订的是房型（“海景双人房”），员工稍后再分配实际房间。直接出售具体房间在开发上更简单，但会让日历更难填满。

房价

起步时，每种房型每晚一个价格，并可选择为日期范围（旺季、节假日）设置覆盖价，以及最少入住晚数。动态定价、促销码和套餐留待以后再做。

付款

按复杂度由低到高的选项：到店付款；通过Stripe Checkout等托管收银页支付押金；不可退款房价的全额预付；或保存银行卡以便之后扣款。付款规则、税费和旅游附加费因国家而异——请查阅当地规定或咨询顾问。我们的支付指南介绍了具体机制。

其他渠道

如果你的房间也在在线旅行社或度假租赁平台上挂牌，就必须保持日历同步。许多平台支持以iCal链接导出和导入日历；小型物业常用这种方式同步，但会有延迟，并非即时。渠道管理系统是更专业的解决方案。

一个有效的首次提示词

为苏格兰Tobermory的Harbour House（一家9间房的民宿）搭建一个直销预订网站。房型：双人房（4间，2人入住，每晚120英镑）、双床房（3间，2人，115英镑）、家庭房（2间，2位成人加2名儿童，165英镑）。客人按入住日期、离店日期和人数搜索，只看到整个住宿期间每晚都有空房的房型，并显示该住宿期的总价。离店为不包含在内。7月和8月最少入住2晚。预订表单收集姓名、邮箱、电话和到达时间；保存为“待处理”，并在服务器端保存前重新检查可订性。员工区需要登录：当天的入住和离店名单、按晚显示房间的日历网格、带状态的预订列表，以及锁定日期的功能。在每个预订页面上显示入住时间15:00–20:00、退房时间10:00，以及取消政策（入住前7天前免费取消）。设计沉稳的海滨风格，以手机为优先。

搭建步骤

1. 先建模房间和晚数。 房型、房间、房价和可订性检查。在做任何设计工作之前先测试。
2. 搜索和结果。 日期选择器、人数、整个住宿期的总价，以及清晰的“已售完”状态。
3. 预订流程。 表单 → 服务器端重新检查可订性 → 待处理预订 → 带管理链接的确认页。
4. 员工区（需要登录）：入住、离店、日历网格、锁定日期。
5. 通过你自己的服务商发送邮件确认，包含日期、总价、地址和政策。参见发送邮件。
6. 在Stripe测试模式下收取押金，只有在付款成功后才确认预订。付款Webhook需要你的应用发布到公共URL。
7. 与其他渠道的日历同步（如果你使用这些渠道），并在初期每天手动核对一次。
8. 测试边界情况： 两个浏览器同时预订最后一间房、住宿期跨越房价变化、取消后释放的晚数、最少入住期间的单晚预订。
9. 发布，并在停用旧流程之前，亲自完成一次真实预订。

常见错误

• 只在浏览器中检查可订性。 两位客人最终会在同一时刻预订最后一间房。
• 把离店当晚计为已占用（或者没有计入入住当晚）。请为两晚的住宿编写测试。
• 只有一个统一价格。 大多数物业至少需要季节性覆盖价。
• 直到最后一步才显示总价。 应在搜索结果中显示整个住宿期的完整价格，包括你已知的所有费用。
• 政策藏在页脚。 应在付款按钮旁边显示取消条款。
• 把iCal同步当作即时。 并非如此；接近满房时要手动关闭日期。

何时现成产品更合适

如果你经营的房间超过少量几间，在多个在线旅行社销售，或需要客房清扫、开票和报表，那么带有内置预订引擎和渠道管理的物业管理系统通常是更正确的选择。这些产品的存在，就是为了解决跨渠道超售问题，而要自己做好这件事成本很高。

自建网站适合主要接受直订的小型物业、非常规的房源（露营小屋、共享设施的小木屋、附带活动的客房），或者当你希望拥有自己的设计和客人体验，而不必为每间房支付月费时。有些业主会把自建网站与嵌入其中的托管预订引擎结合起来——这往往是两全其美的做法。

用Mythex搭建

在Mythex中，你可以在聊天中描述物业，在实时预览（包括手机尺寸框架）中查看网站，并在满意后发布。当应用需要保存数据时，预订、房间和房价都存储在代理添加的Postgres数据库中；空闲时它会休眠，并在下一次请求时唤醒。员工登录、邮件确认和押金都连接到你自己的服务商和密钥——Mythex没有内置的终端用户登录、邮件或支付产品——因此在添加押金之前，请先阅读Stripe配方。使用/test让代理完成搜索和预订流程，并使用检查点回滚会破坏可订性的更改。

如需起始提示词，可以参考酒店预订系统构建器、民宿预订系统构建器，或露营预订网站模板。如果你需要按小时或预约式而非按晚的预订，参见预订应用指南。

常见问题