旅館業者提到飯店訂房系統時，講的往往不是同一件事。有人指的是掛在官網上讓客人自行下訂的那一頁，有人指的是櫃檯每天在操作的後台，也有人想的是把各家通路的訂單集中管理的工具。這三塊確實會互相影響，但職責不同，如果一開始沒分清楚，很容易買了一套只解決其中一段的產品，剩下的還是靠人工接。這篇把旅館端會用到的模組拆開來說明，包括價格方案、通路管理、櫃檯作業、房務狀態與報表，以及它們之間的資料怎麼傳。
它其實是好幾個模組組成的
從資料流向來看，旅館端大致有四個角色。對外的訂房頁面負責讓客人查詢與成立訂單；通路管理負責把可售資訊送到各家銷售管道、把訂單收回來；旅館管理後台處理入住到退房之間的所有作業；報表則把前面三段產生的資料整理成經營者看得懂的樣子。
市面上的產品有的只做其中一段，有的整包提供。評估時先確認自己缺的是哪一段，以及既有系統能不能對接。最怕的情況是每一段都有工具，但彼此不通，員工得在好幾個畫面之間重複輸入同一筆訂單。
同一間房，可以有很多種賣法
價格管理的重點不只是金額高低，而是同一個房型能不能長出多種銷售方案。含早與不含早、可退與不可退、預付與現場付、連住優惠、專案包裝，這些在系統裡通常叫做價格方案或專案，各自帶著不同的規則。
設計時要注意幾件事：方案要能各自設定退改條件，不能全館共用一套；企業合約價與旅行社價需要限定對象，不該公開陳列在訂房頁上；限定期間的專案要能設定販售起訖與適用入住日，兩者是不同的日期。方案數量會隨時間累積，最好一開始就規劃分類與停用機制，否則幾年後後台會塞滿沒人記得的舊專案。
通路管理：一處設定，多處銷售
旅館通常同時在多個管道賣房，通路管理模組的價值就在於讓可售資訊只維護一份。實務上要留意的是各通路的規則並不一致。
- 不同通路對房型名稱、照片數量、取消政策的要求不同，對應關係要先建立好。
- 有些促銷方案只存在於特定通路，無法從自家後台管理，得註明由誰維護。
- 訂單收回來之後，客人的聯絡方式可能是遮蔽過的代碼，寄送入住通知的流程要跟著調整。
- 通路端的異動（改期、加人、取消）要能自動回寫，否則櫃檯拿到的名單會是舊的。
導入之後仍建議保留一份對帳流程，定期把通路後台的訂單筆數與自家系統核對，異常通常出在特殊訂單，例如長住、跨月或含加購的訂單。
櫃檯作業才是每天真正在用的部分
客人抵達之後，系統的工作才開始。櫃檯需要處理的情境比訂房頁複雜得多：入住登記與證件資料、指定房號、升等或換房、續住與提早退房、加床與加購、多間房合併結帳或分開結帳、押金與掛帳、退房後的補收款項。
這些動作若無法在同一個畫面完成，員工就會私下用紙本紀錄，等空檔再補登，資料落差就是這樣產生的。評估系統時，請對方示範幾個實際情境，例如客人臨時要多住一晚、一群人分別付款、旅行社統一結帳卻由客人自付消費，看操作要幾個步驟、會不會影響房況。
房務狀態要跟訂房畫面連動
櫃檯要分配房號，前提是知道哪幾間已經整理好。房務端的狀態至少要區分待清潔、清潔中、可入住、維修中幾種，並且能即時反映在櫃檯的房況表上。
如果房務人員是用平板或手機更新，設計上要盡量簡化，一兩個按鈕就能改狀態；若還是靠紙本回報，至少要規定回報的時間點，並由櫃檯統一登錄。維修房要能設定起訖日期並自動排除販售，避免修繕拖延期間又被賣出。旅館內的耗材補充、遺留物登記，也可以放在同一個介面，省下另外傳訊息的工夫。
報表要回答經營者真正在問的問題
系統累積的資料若只能匯出訂單明細，價值有限。真正需要的是能回答決策問題的整理方式，例如某段期間的住房狀況、各房型的銷售落差、客源來自哪些管道、取消與未到的比例、平均住宿天數、加購項目的接受度。
另外還有兩類報表容易被忽略：一是每日結帳用的收款彙總，要能跟現金、刷卡與線上收款對得起來；二是預測性的資料，例如未來一段時間已成立的訂房量，用來安排人力與備品採購。導入前先列出你每個月固定要看的幾張表，請服務商確認做不做得到，比事後才發現要另外開發省事許多。
多人使用才會遇到的權限與交接問題
旅館是輪班制，同一套系統會有櫃檯、房務、業務、財務與主管使用，權限必須分開。折扣與退款的權限尤其要設限並留下操作紀錄，事後才查得出是誰在什麼時候改了什麼。
交接班也值得規劃：待處理事項、當班收款、特殊需求的客人，最好能在系統裡留言而非寫在便條紙上。人員異動時，帳號要能停用而不是共用一組，這既是管理問題，也是個資保護的基本要求。
常見問題
訂房引擎和旅館管理系統是同一套嗎？
不是。訂房引擎面向客人，負責查詢空房、選方案與付款；旅館管理系統面向內部，處理入住到退房的作業與帳務。兩者可以由同一家提供並整合，也可能分屬不同服務商。若分開採用，最重要的是確認訂單能自動流進管理端，不需要人工重打。
公司合約價與團體訂房要怎麼處理？
合約價通常設定成限定對象的價格方案，透過專屬代碼或登入身分才看得到，不對外公開。團體訂房則需要能一次建立多間、共用同一組聯絡人，並支援分批確認名單與統一結帳。若旅館常接團體，請特別測試修改團體筆數與換房的操作，這部分各家系統差異很大。
一間房臨時故障，怎麼避免它繼續被賣出去？
系統要允許把單一房號標記為維修並設定起訖時間，該期間自動從可售數量中扣除，同時同步到各銷售通路。如果只在房務端註記、沒有連動可售量，通路仍會賣出。修繕完成後也要有明確的解除流程，避免房間修好了卻遲遲沒放回販售。
櫃檯和房務需要另外準備硬體嗎？
視作業方式而定。櫃檯通常已有電腦與印表機，若要列印登記單或收據，要確認系統支援現有機型。房務端若改用行動裝置更新狀態，得評估館內的無線網路涵蓋，尤其是樓梯間與地下樓層。導入前實地測試訊號，比事後補強便宜得多。
系統需要跟財務或發票流程串接嗎？
如果每天要人工把收款資料重打進帳務軟體，串接就值得考慮。常見的做法是由系統匯出符合會計端格式的檔案，或以介接方式自動傳送。開立憑證涉及法規與作業流程，建議先與自家會計人員確認需求，再請服務商評估可行方式與費用。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「飯店訂房系統」相關的規劃，可以參考我們的系統開發需求討論，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
