1. PMS 即使已安裝並完成設定，也不代表已準備好接受實際訂房——關鍵在於相關設定是否已依照實際可能發生的情境完成測試
2. 正式上線時的問題主要集中在五個方面：客房庫存不正確、房價與原定價格不符、限制條件未生效、付款設定未經測試，以及員工帳號擁有不當權限
3. 本清單以 30 個可驗證項目涵蓋上述五大領域——每一項都對應一種若未在開放訂房日曆前發現，便會直接影響旅客的具體問題
4. 請在收到第一筆實際訂房前完整執行一次清單，而不是等訂房進來後才檢查
為何住宿業者正式上線時仍會出錯
新 PMS 的設定步驟很明確：建立房型、輸入房價、連接通路並新增員工。大多數住宿業者都會完成這些步驟。問題在於，完成某個步驟與驗證該步驟並不是同一回事。
房價輸入錯誤，通常要等到旅客以錯誤價格訂房時才會被發現。通路連線看似啟用、實際上卻未同步可售房量，通常要等到超賣發生時才會浮現。員工帳號權限過大，也往往要等到有人更改了其無權調整的房價後才會被察覺。
以下清單是驗證流程，而非設定指南。每一項都以設定已完成為前提，用來測試系統是否會產生正確結果。
房型與庫存（檢查 1–6）
1. 每種房型均與實際客房相符。 PMS 中的房型名稱、數量與說明，均與住宿場所的實際客房相符。名為「海景雙人房」的房型，應對應所有真正擁有海景的雙人房——不能多，也不能少。
2. 客房數量正確，且不會超賣。 系統中各房型的容量與實際可售客房數量一致。建立測試訂房，將某一房型訂至滿房，並確認系統會阻擋該房型在相同日期接受更多訂房。
3. 停用客房已設為不可銷售。 任何正在維修、翻新或因其他原因無法使用的客房，均已設為「維護中」狀態並從可售庫存中移除。確認所有已連接通路均顯示此封鎖狀態。
4. 客房設施標籤正確無誤。 供旅客篩選使用的特色——例如無障礙設施、位於一樓、特大雙人床及陽台——均已指派給正確房型。旅客篩選「無障礙」時，只應看到真正符合該需求的客房。
5. 已按房型設定最多入住人數。 系統會限制各房型的入住人數上限。標示可供兩人入住的客房，不得接受五人入住的訂房。
6. 各房型所使用的照片均為最新版本。 顯示於 官網直接訂房頁面 及 OTA 刊登頁面的圖片，均與客房目前的實際狀況相符——而非翻新期間的舊貌。
房價與定價（檢查 7–12）
7. 基本房價涵蓋完整的 90 天期間。 未來三個月內，每種房型在每個日期都已設定房價。未涵蓋的日期可能產生錯誤，或出現零房價訂房。
8. 如有需要，週末房價已分開設定。 若住宿業者的週五至週六房價與平日不同，請確認價差套用於正確日期，且不會誤套至前後相鄰日期。
9. 旺季與活動期間房價已載入。 已知的高需求日期——例如國定假日、當地活動及學校假期——均已設定反映實際需求的房價，而非沿用預設基本房價。
10. 已設定最低房價門檻。 任何房型的訂房價格均不得低於住宿業者的成本底價。確認自動化工具或人工覆寫均無法將房價調至低於設定的最低金額。
11. 扣除佣金後的 OTA 通路房價正確無誤。 若住宿業者刊登的是淨價，請驗證加價幅度能在平台加上佣金後，產生預期的旅客端售價。若刊登的是總價，則應確認 OTA 不會再額外加收佣金。
12. 測試官網直接訂房顯示正確總額。 透過官網直接訂房連結或訂房小工具建立測試訂單，並確認付款前顯示的總額——房價加稅金及任何費用——與原定金額相符。
收到第一筆實際訂房前，先驗證房價、庫存與通路同步
Smart Order 的設定檢查清單會引導住宿業者完成房價設定、通路連線與員工權限驗證——讓正式上線成為經過確認的狀態，而非未經驗證的假設。
限制條件（檢查 13–16）
13. 旺季期間已套用最短住宿天數限制。 設有至少入住 3 晚限制的連假週末，不得只預訂一晚。請進行測試：嘗試在受限日期建立 1 晚訂房，並確認系統會加以阻擋。
14. 所有通路均已封鎖停售日期。 住宿業者不接受新訂房的日期，已在 PMS 中設為停售，且此狀態會同步至每個已連接的 OTA 通路——而非僅顯示於直接訂房日曆。
15. 入住日與退房日限制已啟用。 例如，若住宿業者在夏季不允許旅客於週五入住，則應在系統中設定此限制，並嘗試建立受限日期的訂房以完成測試。
16. 已設定臨時訂房的可接受時限。 系統已設定最晚可在抵達前多久接受新訂房——無論是當日、24 小時或 48 小時——且官網直接訂房與通路訂房均採用一致設定。
付款與取消政策（檢查 17–21）
17. 官網直接訂房的訂金金額與收取時間已完成設定。 訂金的百分比或固定金額，以及收取時間點——例如確認訂房時或 48 小時後——均已設定，並會自動套用至每筆新的官網直接訂房。
18. 取消期限已設定並完成測試。 已設定旅客在抵達日前多少天內取消將喪失訂金。請進行測試：在期限內取消並確認訂金會被保留；在期限外取消則確認訂金可退還。
19. 已設定未入住費用規則。 旅客未抵達且未在規定期限內取消時應收取的費用，已完成設定並連結至系統留存的付款方式。
20. 已透過實際交易測試金流服務商連線。 已透過連接的金流服務商處理一筆測試扣款並將其撤銷。尚未處理過實際交易的付款整合，不能視為已確認可正常運作。
21. 訂房時顯示的取消政策與系統設定的政策一致。 旅客訂房時在確認頁面及確認電子郵件中看到的文字，與系統實際執行的政策完全一致。
員工角色與權限（檢查 22–25）
22. 每位員工均擁有有效帳號。 每位將在正式上線前或上線當日使用 PMS 的人員，均已登入並確認其帳號密碼可正常使用。
23. 櫃檯人員的權限範圍設定正確。 櫃檯人員 帳號可以查看訂房、辦理入住與退房及處理付款——但無法更改房價、存取完整報表或修改系統設定。
24. 房務人員帳號僅限存取房況。 房務使用者只能更新房況（已退房 → 清潔中 → 待檢查 → 已就緒 → 維護中），無法進行其他操作。他們不會看到旅客付款資料或訂房財務明細。
25. 管理階層與業主帳號符合正確的存取權限層級。 經理帳號擁有報表與設定的存取權限，業主帳號則擁有完整權限。任何員工帳號都不得擁有超出其職務所需的權限。
通路連線與訊息（檢查 26–30）
26. 每個 OTA 通路連線均已透過實際訂房測試。 在 Booking.com 或 Airbnb 建立測試訂房，並確認訂房會在兩分鐘內出現在 PMS 中。不要只因設定畫面顯示「已連接」，便認定連線可正常運作。
27. 可售房量封鎖狀態會同步至所有已連接通路。 在 PMS 中封鎖某間客房的特定日期，並確認每個已連接的 OTA 通路均顯示該封鎖狀態。接著解除封鎖，再確認所有通路均已恢復可售狀態。
28. 官網直接訂房連結或小工具顯示正確的可售房量。 以旅客身分開啟官網直接訂房頁面，並確認顯示的可售房量與 PMS 日曆一致——包括任何封鎖或限制條件。
29. 訂房確認訊息內容正確無誤。 訂房確認電子郵件包含正確的住宿地址、可辦理入住的時段及有效的聯絡電話。將測試確認信寄至員工的電子郵件地址，並逐一檢查所有欄位。
30. 行前訊息的發送時間設定涵蓋所有訂房類型。 系統會針對來自各種來源的訂房，自動發送入住前 72 小時提醒——包括 OTA 訂房，而不僅是官網直接訂房。請查看一筆 OTA 測試訂房的訊息排程加以確認。
滿懷信心地開放訂房日曆，不靠未經驗證的假設
Smart Order 將客房庫存、OTA 通路、付款設定及自動化旅客訊息整合於單一系統——因此，本清單中的 30 項檢查只需針對一套設定執行，而不必分別檢查五種工具。
常見問題
新的 飯店物業管理系統正式上線前，應檢查哪些項目？?
系統上線時最容易出錯的五個領域是客房庫存與數量、房價設定、訂房限制、付款與取消政策設定，以及員工帳號權限。每個類別都有可在第一筆正式訂房進來前測試的具體項目——完成設定不代表已確認設定正確。
如何測試飯店 PMS 與 OTA 通路的連線？
在 OTA 平台建立一筆測試訂房，並確認該筆訂房在兩分鐘內出現在 PMS 中。接著，在 PMS 中封鎖某間客房的特定日期，並確認該封鎖狀態已顯示於 OTA 日曆。這兩項測試缺一不可——能同步接收訂房的連線，不一定能正確向外推送可售房量更新；而能推送封鎖狀態的連線，也不一定能正確接收傳入的訂房。
飯店 PMS 應授予櫃檯人員哪些權限？
櫃檯帳號應能查看及修改訂房、辦理入住與退房、處理住客付款，以及在訂房紀錄中新增備註。但不應擁有房價設定、系統層級設定、完整財務報表或其他員工帳號管理的存取權限。將櫃檯人員的權限限制於日常營運工作，可防止意外更改房價，並縮小帳號憑證相關資安事件的影響範圍。
如何確認 PMS 中的取消政策設定正確？
應從兩種情況進行測試：在取消政策期限外取消訂房，以確認訂金會退還；在期限內取消，以確認訂金會予以保留。此外，也應比較住客訂房時看到的政策文字與系統的實際處理結果——兩者所述的條款應完全一致。
飯店 PMS 何時才算準備好正式上線？
當上線前檢查清單中的每個項目都經過實際測試驗證，而不只是完成資料設定時，PMS 才算準備好正式上線。這包括檢查完整 90 天期間的房價、透過每個通路進行一筆正式測試訂房、確認付款交易成功、確保所有員工帳號均已啟用且權限範圍設定正確，以及檢查自動化訊息的內容是否準確。設定與驗證是兩個不同的步驟——必須先完成驗證才能上線，而不是完成設定後就直接上線。
