如何建立酒店訂房網站：房間、房價、空房及付款

酒店訂房網站讓客人選擇入住日期，查看每一晚都有空房的房間，看到總價，並付款或支付按金，整個過程無需與酒店反覆電郵聯絡。要建立這樣的網站，你需要附有房間數量的房間類型、每晚的空房模型、可按日期變動的房價、一個在儲存時重新核對空房的訂房流程，以及供前台使用的管理介面。真正困難的地方並不是漂亮的頁面，而是確保同一間房永遠不會被重複出售，尤其是當你同時在訂房平台上出售的時候。

網站需要什麼

頁面

• **公開頁面：**首頁、房間（相片、床型、面積、設施、最多入住人數）、日期及人數搜尋、按房型列出總價的結果、訂房表格、付款，以及附有管理訂房連結的確認頁。
• **輔助頁面：**位置及交通方法、政策（入住及退房時間、取消、小童、寵物）、常見問題、聯絡我們。
• **私人（員工）頁面：**今日到達及離開的客人、按晚顯示房間的日曆格、訂房清單、封鎖日期，以及房價及房間設定。

資料

把入住及退房日期儲存為日期，而不是時間，並把退房日視為不包括在內：由 10 號入住至 12 號，只佔用 10 號及 11 號這兩晚。這一點若出錯，就會造成最常見的空房錯誤。

權限

客人可以看到房價及某房間類型是否有空房，但絕不可以看到其他人正在入住。前台員工可以看到訂房及客人資料；只有業主可以更改房價及政策。因此需要一個至少有兩種角色的員工登入功能。

決定與取捨

要求訂房或即時訂房

要求訂房（客人提交日期及資料，你再透過電郵確認）簡單得多，對小型民宿來說已經足夠。即時訂房則需要萬無一失的空房與付款處理，但成交率會較高。很多物業一開始採用要求訂房，之後才改為即時訂房。

出售房間類型，還是指定房間

客人通常預訂的是房間類型（「海景雙人房」），由員工之後再指派實際房間。直接出售指定房間較容易建立，但會令日曆較難填滿。

房價

起初可以每種房型每晚一個價錢，並可為日期範圍（旺季、假期）設定例外價格，以及最少入住晚數。動態定價、推廣代碼及套票可以留待以後再加。

付款

選項按複雜程度由低至高排列：入住時付款；透過 Stripe Checkout 等代管結帳頁支付按金；不可退款的房價全額預付；或儲存信用卡，稍後才扣款。付款規則、稅項及旅遊徵費因國家而異，應查核當地規定，或諮詢專業人士。我們的付款指南介紹了技術運作方式。

其他渠道

如果你的房間同時在網上旅行社或度假屋平台上刊登，就必須保持日曆一致。很多平台可以把日曆匯出及匯入為 iCal 連結；小型物業經常以這種方式同步，但同步會有延遲，而不是即時。專業的做法是使用渠道管理系統。

有效的首個提示

為 Harbour House 建立一個直接訂房網站，這是位於蘇格蘭 Tobermory 的 9 房民宿。房間類型：雙人房（4 間，2 位客人，每晚 £120）、雙床房（3 間，2 位客人，£115）、家庭房（2 間，2 位成人加 2 位小童，£165）。客人以入住日期、退房日期及人數搜尋，只會看到每一晚都有空房的房間類型，並顯示整個住宿的總價。退房日不包括在內。7 月及 8 月最少入住 2 晚。訂房表格收集姓名、電郵、電話及到達時間，並儲存為「待確認」，在伺服器保存前重新核對空房。員工區需要登入：今日到達及離開的客人、按晚顯示房間的日曆格、附有狀態的訂房清單，以及封鎖日期的功能。每個訂房頁面都要顯示入住時間為下午 3 時至 8 時、退房時間上午 10 時，以及取消政策（於入住前 7 日前取消免費）。設計採用平靜的海岸風格，以手機為先。

建立步驟

1. **先建立房間及晚數的模型。**房間類型、房間、房價及空房檢查。在任何設計工作開始前先測試它。
2. **搜尋及結果。**日期選擇器、人數、整個住宿的總價，以及清楚的「售罄」狀態。
3. **訂房流程。**表格 → 伺服器重新核對空房 → 待確認訂房 → 附有管理連結的確認頁。
4. 員工區（需要登入）：到達及離開的客人、日曆格、封鎖日期。
5. 電郵確認，透過你自己的服務供應商發送，內容包括日期、總額、地址及政策。參閱發送電郵。
6. 按金先在 Stripe 測試模式下進行，只有在付款成功後才確認訂房。付款 webhook 需要你的應用程式已發布到公開網址。
7. 與其他渠道同步日曆（如果你使用其他渠道），開始時每日人手檢查。
8. 測試邊緣情況：兩位客人同時預訂最後一間房、橫跨房價變動的住宿、取消後釋出的晚數、最少入住期間的單晚住宿。
9. 發布，並由你親自完成一次真實訂房，然後才停用舊有的流程。

常見錯誤

• **只在瀏覽器檢查空房。**兩位客人最終會在同一時間預訂最後一間房。
• 把退房當晚計為已佔用（或沒有計算入住當晚）。為兩晚的住宿撰寫測試。
• **只有單一價錢。**大部分物業至少需要季節性的例外價格。
• **直到最後一步才顯示總額。**在搜尋結果中就要顯示整個住宿的總價，包括你已知的所有費用。
• **政策藏在頁尾。**應把取消條款顯示在付款按鈕旁邊。
• **把 iCal 同步當作即時。**並非即時的；接近滿房時應人手關閉日期。

何時現成產品較合適

如果你經營超過少數房間、透過多個網上旅行社出售，或需要房務、發票及報告，附有內建訂房引擎及渠道管理系統的物業管理系統，通常會是較正確的選擇。這些產品的存在，就是為了解決跨渠道的超額訂房問題，而要自行做好這一點是非常昂貴的。

自訂網站適合主要接受直接訂房的小型物業、特殊的庫存（露營帳篷營地、設有共用設施的小屋、附帶活動的房間），或希望擁有自己的設計及客人體驗，又不想按房間每月付費的情況。有些業主會把自訂網站與嵌入其中的代管訂房引擎結合使用，這往往是兩全其美的做法。

使用 Mythex 建立

在 Mythex 上，你可以在對話中描述物業，在即時預覽中檢視網站（包括手機大小的畫面），然後在運作正常時發布。當應用程式需要儲存資料時，訂房、房間及房價會存放於 Postgres 資料庫，閒置時會休眠，並在下一個請求到達時喚醒。員工登入、電郵確認及按金都接駁你自己的服務供應商及金鑰——Mythex 沒有內建的終端用戶登入、電郵或付款產品——因此在加入按金之前，請先閱讀 Stripe 指南。使用 /test 讓代理逐步完成搜尋及訂房，並可使用檢查點還原一個破壞空房功能的更改。

如需起始提示，可參考酒店訂房系統建立工具、民宿訂房系統建立工具，或露營帳篷訂房網站範本。如果你的預訂是按小時或按預約時段計算，而非按晚計算，請參閱訂房應用程式指南。

常見問題