會找「線上訂房系統」的多半是旅館、民宿或包棟住宿的經營者，手上的問題很具體：房況散在電話、通訊軟體與各家訂房通路上，要靠人工一個一個改，稍微一忙就會出現同一間房賣兩次。也有人是希望降低通路抽成，想把客人拉回自己的官網下訂。這篇從住宿業實際的營運狀況出發，談房型與房量該怎麼建、房況同步為什麼會出錯、訂金與取消規則怎麼寫進系統，以及淡旺季房價的設定方式。
房型、實體房間與可售庫存要先分清楚
訂房資料有三個層次，混在一起就會出問題。房型是規格，例如雙人房、四人房、家庭房；實體房間是一間一間的存在，各有房號與狀態；可售庫存則是某個日期、某個房型還剩幾間能賣。
只建房型不管房號，遇到指定房間、無障礙需求、有無電梯這類要求就處理不了；只建房號不建房型，往通路上架時又無法對應。實務上兩層都要有，並明確定義哪幾間房屬於哪個房型；維修或整理中的房間要能單獨鎖住，不影響其他房量的販售。
房況同步：超賣為什麼總在連假前後發生
超賣的成因幾乎都一樣：同一份房量同時掛在多個銷售管道上，而更新不是即時的。平日訂單稀疏，人工更新來得及；一到熱門日期，同一分鐘內可能有好幾個管道成交，慢個幾分鐘就重複賣出。
- 設定安全庫存：熱門日期在通路上保留一部分不釋出，留給官網與電話訂房，是最直接的緩衝。
- 訂單成立當下就扣庫存，而不是等付款完成才扣；未付款的訂單給一個保留時限，逾時自動釋放。
- 同一間房只能有一個庫存來源，各管道都向這個來源取數，不要各自維護一份。
- 保留人工覆核的機制，當自家資料與通路資料不一致時，要看得出來是哪一天、哪一筆出了狀況。
訂金、取消與退款要寫成系統算得出來的條件
住宿業的糾紛大多來自取消。政策寫在網頁上是一回事，系統能不能自動判斷是另一回事。要落進系統裡，規則必須拆成可計算的條件：以入住日往前推幾天為分界、各區間退還多少比例、熱門檔期是否另有規定、天災或政府公告停班停課時如何處理。
訂金比例、是否要求全額預付、能否線上退款，都會影響取消流程的複雜度。如果退款必須人工作業，系統至少要能標記狀態，讓後台知道哪幾筆還沒退、各退了多少。
淡旺季與連假的房價設定方式
住宿定價以日期為單位，這跟一般商品很不一樣。系統至少要支援幾種設定：用星期幾區分平日與假日、指定區間套用旺季價、單獨指定某一天的特殊價、以及熱門檔期的最少住宿天數限制。
加人加床、寵物、早餐、停車位這類項目，最好做成可勾選的加購，而不是另外開一個房型，否則房型數量會膨脹到難以維護，上架到通路時也會很混亂。連續入住的折扣若要自動計算，訂房頁的金額顯示方式要一併設計，避免客人看到的價格與最後付款金額不同。
官網直訂與通路訂房的取捨
訂房通路帶客能力強，境外客源尤其明顯，代價是抽成、規則與價格政策都不在自己手上。官網直訂沒有抽成，客人資料完整留下，日後要經營回頭客才有基礎，缺點是流量得自己想辦法。
務實的策略不是二選一，而是讓官網提供通路給不了的東西：可指定房間、專屬加購方案、彈性的入住時間、老客人的招待項目。價格方面要留意與各通路的價格條款，直接標低價可能違反合約，用價值差異來競爭通常比較安全。
入住前後的流程也該一起規劃
訂房完成不是終點。系統若能自動寄出訂房確認、入住前提醒、交通與停車資訊，可以省下大量重複的客服往返。住客資料的蒐集要有明確用途說明與同意機制，並依個人資料保護的相關規定妥善保存，證件影本與聯絡方式尤其要小心。
後台則要能一眼看出當日的入住與退房名單、尚未收齊尾款的訂單，以及各房間的清潔狀態。這些資訊如果還得靠紙本或另一份表格維護，系統帶來的效益會被抵銷掉一大半。
導入之前先把這些資料整理出來
- 房型清單，以及每個房型對應的實際房號、可住人數與床型配置。
- 各房型的平日價、假日價、旺季區間與需要特別指定的日期。
- 訂金比例與完整的取消退款級距。
- 加購品項及其計價方式，是依人、依晚還是依次計算。
- 目前合作的訂房通路，以及房量在各通路之間的分配原則。
這些資料不論最後選用哪一套系統都會用到，事先整理可以大幅縮短導入時間，也常常會在整理過程中發現自己的規則其實互相矛盾。
常見問題
已經在訂房通路上架了，還需要自己的訂房功能嗎？
如果目前訂單量還小、房間也不多，先靠通路運作是合理的。但當抽成金額開始有感，或同一批客人重複入住的比例提高時，自有訂房就值得投入，因為它能讓你直接握有客人資料與再訪機會。另一個常見的觸發點是超賣次數變多，那代表人工同步已經到了極限。
包棟或整層出租要怎麼設定？
包棟的難處在於它會同時佔用多個房間。做法是把整棟建立成一個獨立的銷售單位，並與旗下各房間的庫存互相連動：包棟售出時，所屬房間全部鎖住；任一房間單獨賣出時，該日期的包棟就不能再賣。這層連動關係要在導入前講清楚，事後補做通常很麻煩。
客人一次住好幾晚，剛好跨到旺季怎麼算錢？
正確做法是逐日計價，每一晚各自套用當天的房價再加總。用入住當天的價格乘以晚數，遇到跨平日假日或跨檔期就會算錯。訂房頁面最好把每一晚的金額分開列出，客人看得到組成方式，事後也比較不容易爭議。
臨時要加人加床，系統該怎麼處理？
把加人與加床做成附加項目，設定各房型可加的上限與計價方式，並允許在訂單成立後補加。要注意的是房間實際可容納的人數必須設為硬性限制，不能超過安全與法規允許的範圍。若加價需要另外收款，訂單應該產生一筆補款紀錄，而不是直接把總價改掉。
只有幾間房的小型民宿，值得導入系統嗎？
要看時間成本。如果每天花在回訊息、確認空房、手動記帳的時間已經很可觀，或是常因為漏看訊息而流失訂單，那即使房間不多也划算。房數少的經營者可以從最基本的空房查詢與線上下訂開始，先解決最耗時的環節，其餘功能等營運穩定後再逐步補上。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「線上訂房系統」相關的規劃，可以參考我們的系統開發需求討論，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
