如何打造飯店訂房網站：房型、房價、可訂狀態與付款

飯店訂房網站讓客人選擇日期、查看每一晚住宿期間有哪些房間可訂、看到總價，然後付款或支付訂金，全程不需要有人來回寄信。要打造一個，你需要帶有房間數量的房型、可依日期變動的房價、一個會在儲存時重新檢查可訂狀態的訂房流程，以及給櫃檯使用的後台檢視。真正的難點不在於漂亮的頁面，而是確保同一間房絕不會被賣兩次，尤其當你同時在訂房平台上販售時。

網站需要什麼

頁面

• 公開頁面： 首頁、房型（照片、床型、坪數、設施、最多住宿人數）、以日期與人數搜尋、結果頁（每種房型的住宿總價）、訂房表單、付款，以及附有管理訂單連結的確認頁。
• 輔助頁面： 位置與交通指引、政策（入住與退房時間、取消、兒童、寵物）、常見問題、聯絡我們。
• 私人後台（員工）： 今日入住與退房名單、以夜為單位的房間月曆格、訂單列表、封鎖日期、房價與房間設定。

資料

請把入住與退房儲存為日期，而不是時間，並將退房視為不包含在內：從 10 號住到 12 號，使用的是 10 號與 11 號的兩晚。這個細節出錯，是最常見的可訂狀態錯誤。

權限

客人只能看到房價與某房型是否可訂，絕不能看到其他住客是誰。櫃檯人員可以看到訂單與客人資料；只有業主才能修改房價與政策。這表示員工登入至少要有兩種角色。

決策與取捨

需求確認或即時訂房

需求確認（客人送出日期與資料，由你以 Email 回覆確認）建置簡單得多，對小型民宿來說已經足夠。即時訂房需要非常嚴謹的可訂狀態與付款處理，但轉換率較高。許多物件先從需求確認開始，之後再切換。

販售房型或特定房間

客人通常是訂「房型」（「海景雙人房」），由員工之後再指派實際房間。直接販售特定房間比較容易建置，但會讓月曆更難填滿。

房價

一開始採用每種房型每晚一個價格，並可選擇為特定日期區間（旺季、假日）設定覆寫價格，以及最短住宿晚數。動態定價、優惠碼與套裝方案留到之後再做。

付款

選項依複雜度由低到高排列：入住時付款；透過 Stripe Checkout 等代管結帳頁收取訂金；不可退費的房價全額預付；或先儲存卡片、稍後再收費。付款規則、稅金與住宿稅因國家而異，請查閱當地法規或諮詢專業人士。我們的付款指南說明了運作機制。

其他通路

如果你的房間也在線上旅遊代理商或民宿平台上架，就必須保持行事曆同步。許多平台支援以 iCal 連結匯出與匯入行事曆；小型物件常以此方式同步，但會有延遲，不是即時的。通路管理系統則是專業的解決方案。

一句好用的第一個提示

為 Harbour House 打造直接訂房網站，這是位於蘇格蘭 Tobermory 的 9 房民宿。房型：雙人房（4 間，2 位客人，每晚 £120）、雙床房（3 間，2 位客人，£115）、家庭房（2 間，2 位成人加 2 位兒童，£165）。客人依入住日、退房日與人數搜尋，只會看到整段住宿每一晚都有空房的房型，並顯示總價。退房日不包含在內。7、8 月最短住宿 2 晚。訂房表單收集姓名、Email、電話與抵達時間；存為「待確認」，並在儲存前於伺服器端重新檢查可訂狀態。員工後台需登入：今日入住與退房名單、以夜為單位的房間月曆格、附狀態的訂單列表，以及封鎖日期的功能。每個訂房頁面都要顯示入住時間 15:00–20:00、退房時間 10:00，以及取消政策（入住前 7 天可免費取消）。設計沉穩、有海岸風格，以手機為優先。

建置步驟

1. 先建立房間與夜晚的模型。 房型、房間、房價與可訂狀態檢查。在做任何設計之前先測試。
2. 搜尋與結果頁。 日期選擇器、人數、整段住宿的總價，以及清楚的「已售完」狀態。
3. 訂房流程。 表單 → 伺服器端重新檢查可訂狀態 → 待確認訂單 → 附管理連結的確認頁。
4. 員工後台（需登入）：入住、退房、月曆格、封鎖日期。
5. Email 確認信，透過你自己的服務商寄出，內容包含日期、總價、地址與政策。參見寄送 Email。
6. 訂金使用 Stripe 測試模式，只有在付款成功後才確認訂單。付款 webhook 需要你的應用程式發布到公開網址。
7. 與其他通路同步行事曆（如果你有使用），初期每天手動檢查一次。
8. 測試邊緣情況： 兩個瀏覽器同時預訂最後一間房、跨越房價變動的住宿、取消後釋出的晚數，以及在最短住宿期間內的一晚住宿。
9. 發布，並親自完成一筆真實訂房，之後再停用舊的流程。

常見錯誤

• 只在瀏覽器端檢查可訂狀態。 總會有兩位客人在同一時刻預訂最後一間房。
• 把退房當晚算作已住（或沒有算入入住當晚）。請為兩晚的住宿寫一個測試。
• 只有單一價格。 多數物件至少需要季節性的覆寫價格。
• 直到最後一步才顯示總價。 在結果頁就要顯示整段住宿的完整價格，包括你已知的任何費用。
• 政策藏在頁尾。 取消條款要放在付款按鈕旁邊。
• 把 iCal 同步當成即時同步。 它不是即時的；接近客滿時請手動關閉日期。

什麼時候現成產品是較好的選擇

如果你經營的房間超過少數幾間、在多個線上旅遊代理商販售，或需要房務、開立發票與報表，那麼附有訂房引擎與通路管理系統的物業管理系統通常是更好的選擇。這類產品就是為了解決跨通路超賣的問題而存在的，要自己做好這件事成本很高。

自建網站則適合主要接受直接訂房的小型物件、特殊的住宿產品（露營帳篷區、共用設施的小木屋、附帶活動的房間），或是你希望擁有自己的設計與住宿體驗，而不想為每間房支付月費。有些業主會把自建網站搭配內嵌的代管訂房引擎，通常兩者的優點都能兼顧。

用 Mythex 打造

在 Mythex 中，你用對話描述物件，在即時預覽中檢視網站（包括手機尺寸框），準備好時再發布。當應用程式需要儲存資料時，訂單、房間與房價會存在 Postgres 資料庫中；閒置時它會休眠，並在下一次請求時醒來。員工登入、Email 確認信與訂金，都連接到你自己的服務商與金鑰——Mythex 沒有內建的終端使用者登入、Email 或付款產品——因此在加入訂金之前，請先閱讀 Stripe 食譜。使用 /test 讓代理程式模擬搜尋與訂房，並使用檢查點來還原會弄壞可訂狀態的變更。

若需要起始提示，可以參考飯店訂房系統建構工具、民宿訂房系統建構工具，或露營訂房網站範本。若是以小時或預約時段而非以夜數計算的訂位，請參見預約應用程式指南。

常見問題