旅宿管理系統 PMS選購常見問題

只掛一家 OTA、或幾乎全靠電話與 LINE 接單的話，Excel 確實撐得住。真正的觸發點不是房間數，是通路數：從你掛上第二家 OTA 開始，同一間房一晚只能賣一次這件事就得靠人工在兩個後台同時改房量，一忙就漏改，而漏改的結果是超賣。超賣要自掏腰包幫客人找替代房、補差價，還會被 OTA 記點降低排序，代價遠高於月費。第二個觸發點是不只你一個人管房，家人代班或請了櫃檯，房況就必須有一份大家看同一版的資料。 用一個數字自我檢查：算算你上個月為了怕超賣而在 OTA 上「保留不賣」的房晚數，乘上平均房價。民宿型雲端 PMS 月費多在幾千元等級，通常只要一兩晚房晚就打平。如果你的答案是「我根本不敢多開通路」，那你缺的就是 PMS，而不是更好用的試算表。

這是這個品類最該花時間驗的一題。先問一句話：通路管理是你們自己做的，還是轉接第三方？台灣不少 PMS 的通路後端其實是接國外的通路管理商（SiteMinder 是常見的一家），那份 400 家名單是後端業者的總表，不是你會用到的那幾家。轉接不是壞事，但代表出問題時你的廠商只能代為轉報、修復時程不在他手上，費用也可能另計。接著問同步是即時推送還是定時排程、實際延遲幾秒、房量房價訂單三者是不是都雙向。 Demo 時請對方把你真正要用的那兩三家 OTA 後台跟 PMS 並排開著，當場把某房型剩餘量從 3 改成 0，掐錶看幾秒後各通路關房；再從 OTA 端下一張訂單，看 PMS 多久收到、其他通路是否同步扣減。最後把合約翻到責任條款，看超賣造成的訂房損失是誰負責——很多合約寫明系統商不負賠償責任，這點要在簽名前知道。

OTA 抽 15 至 20% 是旅宿的核心成本，所以官網直訂零抽成成了台廠共同的主打賣點，這件事本身通常是真的，但要拆成三層看。第一層是 PMS 本身抽不抽訂單成數，這層多數台廠確實不抽；第二層是刷卡金流手續費，這是金流商或銀行收的，「我們不抽成」不等於「你不用付手續費」；第三層是官網訂房引擎本身算不算加購模組、有沒有訂單量或訂單金額的級距。這三層要分開問，別讓一句零抽成蓋過去。 實際算法是：月費乘以使用月數，加建置費（月費型導入常另收約一萬元等級的建置費），加金流手續費、簡訊費、發票費，再除以你預估的官網訂房金額，得到一個實質抽成率，拿去跟 OTA 的 15 至 20% 比。房數少、官網轉單本來就低的民宿，這個實質抽成率可能不低，導入的主要價值反而是不超賣與省人工。請廠商直接用你去年的真實訂單結構試算兩年總額。

分界線不是房間數，是你的帳有多複雜。民宿與小型旅館用的雲端 PMS（旅安、滿房寶、OwlNest、旅宿E管家、民宿管家、TRAIWAN 這一群）是月費制、自助導入，強項在通路同步與官網直訂；星級飯店型（德安、金旭、靈知這一群，德安在台灣三到五星市占居前）是專案制、以地端為主，導入費落在數十萬到百萬等級，強項在夜間稽核、房帳與各營收點的過帳、團體與公司合約房價、多館集團與財務系統整合。兩群買家幾乎不互相比價，是因為要解的問題根本不同。 該升級的訊號很具體：開始接團體與公司合約價、住客要簽單掛房帳、餐廳或SPA的消費要併進房帳一次結、需要正式的夜核與稽核軌跡、多館要共用會員。反過來說，如果你現在的痛只是 OTA 同步跟房務排班，買飯店型系統是把錢花在你用不到的模組上。判斷方式：把你上個月最花時間的三件事寫下來，看落在哪一邊。

我們調查的十三家旅宿系統裡，只有兩家在官網公開牌價（旅安、滿房寶），其餘全是洽詢制。原因一半是結構性的：報價會隨房型數、要串幾家通路、要不要官網訂房引擎、要不要門鎖與自助機、有沒有餐飲而大幅變動；另一半是議價空間。你能做的是先把規格寫死，讓每家報同一份東西，比價才有意義。 給廠商的規格至少包含：房型數與總房間數、指名要串的 OTA 清單、要不要官網訂房與線上刷卡、要不要電子發票、幾個操作帳號、單館或多館。要求對方逐項列出月費或年費、建置與教育訓練費、通路管理費（是否按通路家數或訂單量另計）、訂房引擎費、金流手續費百分比、簡訊與發票張數費、加購模組、綁約期與提前解約條件，以及續約時的調幅上限。最後把它壓成一張兩年總額表，同規格找兩到三家比。淡旺季差很大，旺季前一個月談通常沒有議價空間。

先想清楚你要買回來的是什麼：這兩樣東西省的是夜間值班與交接鑰匙的人力，不是房價。所以判斷基準是你每個月為了等客人入住而付出的工時或加班費，加上鑰匙遺失與重配的成本。一人管理、住在現場、房數個位數的民宿，回收期通常很難看；多棟分散、旅客常深夜抵達、或本來就想做無人化的，才算得回來。硬體是一次性大筆支出，門鎖以每房計、自助機以每台計，都要另外算安裝、電池更換與後續維護。 整合面要問到底：門鎖是 PMS 原生支援還是透過第三方轉接、支援哪些品牌型號（不要接受「都可以接」這種答案，要清單）、訂單成立後密碼是否自動產生並在退房時間自動失效、換房與延住怎麼重發、網路斷線時房門還開不開得了。自助機在台灣還要能完成旅客登記與身分核對、收款與開立電子發票，少一項就等於櫃檯還是得有人。Demo 時請對方現場建一張訂單，走完發密碼到退房失效的完整流程。

入住當天最常出事的就這兩件。一是客人到了、房間還沒清好，因為房務清完沒有回報，或回報了櫃檯畫面沒更新；二是排房把三晚連住的客人排進中間某晚已有人的房，到第二天才發現要請客人搬房。這兩件事都不是功能有沒有的問題，是狀態流轉夠不夠即時。可用的系統至少要有髒房、清潔中、待查、可售這幾個狀態，房務用手機更新、櫃檯即時看到，並能分派今天誰清哪幾間、標記退房、續住與加床。 代價要算清楚：該清完沒改狀態，那間房在通路上就賣不出去，等於憑空少一晚營收；反過來把還沒清的房賣掉，就是一則客訴加一次退款。排房那邊還要看得出鎖房維修會不會自動同步關掉各通路的可售量。Demo 請對方用房務角色的手機把一間房從髒改成可售，看櫃檯畫面幾秒更新；再排一組跨三晚的連住訂單，看系統會不會主動擋掉中間有人的房型。

台灣的旅宿業依規定要辦理旅客住宿登記並留存資料以備查閱，所以系統能不能直接產出格式正確、可依日期查詢與匯出的旅客資料表，是台灣在地的硬需求。電子發票同理，開立、上傳、載具歸戶、折讓與作廢都要有著落。這兩塊台廠多半原生內建或已經串好加值中心，國際產品（例如以通路管理見長的 SiteMinder，或國際雲端 PMS Cloudbeds）通常沒有原生支援，要靠在地夥伴另外開發或外掛。 要問的是責任與成本歸屬，不是「能不能做」——誰開發、多少錢、每年維護費多少、國際母公司改版時介接壞掉由誰修、修多久。這段隱藏成本常常吃掉國際產品在通路深度上的優勢。Demo 時請對方現場開一張帶載具的電子發票，再匯出一份當日旅客登記資料看欄位齊不齊。至於保存期限與應載欄位這類法規細節，建議另外向主管機關或專業人士確認，別直接沿用系統內建範本就上路。

這題要在簽約前問，等到想換的時候你已經沒有籌碼。至少確認四類資料匯得出來：歷史訂單（含成交房價、來源通路、住客資料）、房型與房價方案設定（含各通路的價差與規則）、會員或常客資料與消費歷程，以及最容易被漏掉的「未來已成立的訂單」。換系統那天你手上會有好幾個月的未來訂單，如果只能一筆筆抄，抄錯一筆就是超賣。 還有一個旅宿獨有的坑：如果你的通路管理是廠商轉接第三方的，你跟各 OTA 的連線很可能是掛在原廠商的合約帳號下。換 PMS 等於要跟每一家 OTA 重新申請連線、重做房型與房價的對應設定，而這段對應沒做完之前，是超賣風險最高的時候。務必問清楚轉換期能不能新舊雙軌並行幾天。做法上，把「合約終止後應提供全部資料之可讀電子檔，含未來訂單與房價設定，不另收費」寫進合約，並在 Demo 當下就請對方實際匯出一次看欄位。

關鍵字是掛房帳。如果你的餐廳主要服務外客、住客也都當場結清，兩套系統各自獨立完全沒問題，為了串接多花錢反而不划算。真正需要串的是這幾種情況：住客在餐廳簽單、退房時一次結；房價含早餐，要把早餐收入拆給餐飲部門認列；或你要看每間房的總消費而不只是房費。這時候餐飲消費必須能即時過帳到住客的房帳上。 要問清楚的是：是同一家廠商的原生整合（飯店型系統多半有自家或指定搭配的 POS），還是介接你現有的第三方 POS；過帳是即時還是每日批次；退房時能不能分帳，例如房費由公司付、餐飲個人自付；發票是分開開還是合併；介接的一次性費用多少，日後 POS 改版導致介接失效時由誰負責修。Demo 請對方在 POS 開一張單掛到指定房號，回 PMS 看住客帳是否立刻出現，再做一次分帳結帳，看兩張發票怎麼開出來。