預訂引擎、通路管理系統與PMS的差異｜小型旅宿如何選擇

研究如何讓旅宿接受線上預訂時，會看到「預訂引擎」「通路管理系統」「PMS」等詞。各服務的名稱與功能範圍不同，一項產品也可能具有多個角色，因此不能只看名稱選擇。

先整理主要角色如下。

預訂引擎：在旅宿官方網站等地方接受預訂
通路管理系統：同步多個銷售管道的房量、房價與預訂資訊
PMS：管理預訂後的房間分配、入住、清潔、會計、顧客資訊等

本文以小型民宿、日式旅館、Pension為對象，說明如何從目前預訂管道與日常作業判斷需要哪些系統。

先用一張圖思考預訂流程
預訂引擎：官方網站接受預訂的入口
1. 與預訂表單的差異
2. 可能只需要預訂引擎的旅宿
通路管理系統：連接多個銷售管道
1. 減少重複預訂的機制
2. 較容易需要通路管理系統的旅宿
PMS：管理預訂後的住宿作業
1. PMS不是預訂網站
2. 較容易需要PMS的旅宿
比較三者差異
決定「哪個是權威原始記錄」
小型旅宿如何選擇
比較前向服務商詢問的事項
示範時重現實際的一天
常見的選擇失誤
導入前檢查清單
請AI協助比較的提示詞
總結
參考資料

先用一張圖思考預訂流程

旅客
├── 旅宿官方網站 → 預訂引擎
├── OTA A
├── OTA B
└── 電話與電子郵件
↓
通路管理系統
↓
PMS
├── 房間分配
├── 入住
├── 清潔與餐飲指示
└── 會計與顧客管理

這是協助理解角色的一般示意圖。實際上，也有預訂引擎與通路管理系統合一、包含PMS的整合型產品，以及將電話預訂直接輸入PMS的流程。

並不是「一定要分別簽約購買三種產品」。

預訂引擎：官方網站接受預訂的入口

預訂引擎也稱自家預訂系統、Web預訂系統、Booking Engine等。它是在旅宿官方網站設置「查詢空房」「預訂」按鈕，讓旅客選擇日期、人數、房間、方案後申請的地方。

主要功能範例如下。

依日期與人數查詢空房
顯示客房、住宿方案、房價
輸入預訂者資訊
受理預訂與確認電子郵件
受理取消
優惠券與會員房價
線上付款
多語言顯示
顯示預訂規約與取消條件

與預訂表單的差異

一般聯絡表單也能傳送「希望住宿日期」，但不一定具有確定空房的機制。如果直到旅宿回覆才成立預訂，就比較接近受理預訂請求的流程。

預訂引擎通常會參照房量與房價，當場確定預訂。但服務與設施設定也可能採「請求預訂」，因此要在使用規約與確認電子郵件中說明成立時間。

可能只需要預訂引擎的旅宿

客房數少
銷售以官方網站為主
不使用OTA，或只使用一個
目前台帳足以管理房間分配與清潔
每天有人可以確認預訂資訊

但請確認，同一負責人能否立即更新電話與線上預訂的房量。

通路管理系統：連接多個銷售管道

OTA指線上旅行社或住宿預訂網站。在多個OTA與官方網站銷售相同客房，就需要在各處登錄房量、房價，並在每次預訂或取消時更新。

通路管理系統具有集中管理多個銷售管道，整合房量、房價、方案、預訂資訊等的角色。英語服務有時稱為Channel Manager。

減少重複預訂的機制

最後一間房在OTA A被預訂後，若能迅速關閉OTA B與官方網站的房量，就能減少將同一房間賣給兩人的風險。

但導入通路管理系統，不代表絕對不會重複預訂。

整合有時間差
有不支援的方案或銷售管道
忘記輸入電話預訂
房型對應錯誤
發生通訊故障或維護
OTA與設施使用的房量單位不同

導入時要確認哪些銷售管道與哪些項目即時整合。只標示「可以整合」，不代表房量、房價、預訂、取消、方案、付款資訊全部都雙向運作。

較容易需要通路管理系統的旅宿

在多個OTA銷售相同客房
希望官方網站與OTA共用預訂房量
希望將房價或停售批次反映到多個網站
預訂通知的轉抄作業成為負擔
房量更新延遲與輸入錯誤增加

PMS：管理預訂後的住宿作業

PMS是Property Management System的縮寫。日本觀光廳也稱為顧客預訂管理系統，是支援住宿預訂與館內作業的核心系統。

功能範圍依產品與設施規模差異很大，範例如下。

預訂台帳
客房分配
入住與退房
住客資訊與顧客歷史
清潔狀況與客房狀態
餐飲、過敏、接送等指示
營收、請款、入帳、收據
入住率與營收報表
住客名簿相關作業
與電子鎖、POS、付款、會計等整合

PMS不是預訂網站

PMS即使有預訂台帳，也不一定能讓旅客從官方網站預訂。可能另外需要從預訂引擎或OTA接收資料的整合。

反過來，若預訂引擎附有簡易顧客管理或入住功能，小型設施也可能不需要獨立PMS。

較容易需要PMS的旅宿

客房與員工增加，紙本或試算表難以共享
希望連動預訂後的房間分配、餐飲、清潔、會計
希望集中電話、OTA與自家預訂資訊
多位員工或多個設施同時確認
希望將顧客歷史、營收、入住率用於改善營運

比較三者差異

觀點	預訂引擎	通路管理系統	PMS
主要使用者	預訂旅客與預訂負責人	銷售與預訂負責人	櫃檯、清潔、會計、經營者等
主要角色	官方網站接受預訂	同步多個銷售管道的房量、房價、預訂	管理預訂後的住宿作業
主要對象	日期、人數、方案、預訂者輸入	OTA與官方預訂的房量及銷售資訊	房間分配、住客、客房狀態、會計等
即使只有一個OTA也需要嗎	接受自家預訂時可列入候選	人工作業足夠時也可能不需要	依館內作業複雜度判斷
重複預訂對策	可管理自家房量	以同步多個銷售管道為主	集中已整合預訂與電話預訂
產品形式	獨立或整合型	獨立或整合型	獨立或整合型

此表呈現一般角色。即使產品名稱寫PMS，也可能包含通路管理系統或預訂引擎。比較時應確認需要的作業包含到哪裡，而非只看產品分類。

決定「哪個是權威原始記錄」

整合多個系統時，如果同一預訂或房量的修改位置不明確，資料就會不一致。

例如，導入前先決定以下事項。

在哪裡建立客房與房型
在哪裡輸入基本房量
房價與方案以哪裡為權威原始記錄
電話預訂最先登錄到哪裡
在哪裡受理取消，自動反映到哪些範圍
在哪裡更正住客資訊
在哪裡確認已付款與未付款
各系統數字不同時，以哪個為準

即使說明「全部連接」，修改方向與反映時間也不一定相同。應向服務商確認整合圖與營運步驟。

小型旅宿如何選擇

階段1：列出目前預訂管道

以過去一個月或旺季為例，記錄以下件數與作業。

電話預訂
電子郵件與聯絡表單
官方網站預訂
各OTA預訂
熟客與旅行社預訂
當天預訂與直接到店

也要記錄每次預訂、變更、取消時，由誰更新哪個台帳、更新幾次。

階段2：選一個困擾的作業

目的不同，最先需要的系統也不同。

主要困擾	最先考慮的角色
只能接電話，錯過營業時間外預訂	預訂引擎
各OTA房量更新負擔大，擔心重複預訂	通路管理系統
預訂後房間分配、清潔、會計共享繁瑣	PMS
三者都分散，需要大量轉抄	可整合的組合或整合型

目的應具體到「減少每天發生的一項轉抄」，而非只是「導入高功能系統」。

階段3：從最低必要配置開始

客房少，以官方預訂為主

預訂引擎加上立即反映電話預訂房量的流程，可能已足夠。若高功能PMS只會增加輸入作業，就不適合。

在多個OTA與官方網站銷售

通路管理系統的優先度提高。確認使用中的全部OTA與預訂引擎都受支援，並可正確對應房型、方案。

多位員工共享館內作業

可考慮以PMS為中心，集中通路管理系統與預訂引擎的預訂。也要確認不只櫃檯，清潔與餐飲負責人也能在必要範圍內查看必要資訊。

一人或家族經營

比起功能數，更重視代為設定、電話支援、故障時替代流程，以及帳單是否容易理解。避免只有一人了解設定的狀態。

比較前向服務商詢問的事項

整合

能否與目前使用的OTA、預訂引擎、PMS整合
房量、房價、預訂、變更、取消哪些屬於整合範圍
單向還是雙向
一般反映時間與故障時行為
能否處理房型、含餐方案、連住、兒童房價
日後能否更換整合對象

預訂流程

預訂成立時間
超額預訂時的責任分工與處理窗口
電話預訂、休館日、包場、封房的登錄方式
如何處理取消費與退款
預訂變更如何傳達各銷售管道

付款

能否同時處理現場與線上付款
付款代辦公司與合約主體
付款手續費、退款手續費、入帳週期
是否採旅宿不保存卡片資訊的配置
取消與未通知而未入住時的收款步驟

預訂系統與付款系統角色不同。即使預訂引擎有付款功能，也應另外確認合約、手續費、入帳、退款、本人驗證的條件。

資料與權限

住客資訊保存在哪裡，由誰查看
能否按員工區分權限
是否保留操作歷史
能否撤銷離職者或網站製作公司的存取
資料保存期限與刪除方式
合約結束時，能否匯出預訂、顧客、營收資料
匯出格式與是否提供移轉支援

故障與支援

故障時能否受理預訂
房量同步停止時如何通知
夜間與假日的聯絡方式
恢復後如何比對預訂重複或缺漏
初始設定、資料移轉、員工訓練由誰負責
說明手冊是否讓不熟悉IT的人也能理解

示範時重現實際的一天

不只看功能清單，也用虛構預訂進行以下操作。不要在示範中輸入真實住客資訊。

從官方網站預訂一間房
確認其他銷售管道剩餘房數是否變更
新增電話預訂
變更日期、人數、餐飲、房間
取消一件預訂
確認退款或現場結算狀態
共享房間分配與清潔狀態
匯出預訂清單與營收
變更員工權限
詢問無法通訊時的替代步驟

除了日常操作，也試做變更、取消、故障等例外，才能了解實際負擔。

常見的選擇失誤

只依月費選擇

比較包含初始費用、預訂手續費、付款手續費、追加整合、支援、資料移轉、裝置費用的總額。即使價格便宜，只要仍需轉抄，就會持續付出人力時間與錯誤成本。

認為功能越多越安心

未使用功能多，初始設定、教育、權限管理、故障位置也會增加。應區分目前作業與一年後需要的作業。

只看支援OTA的數量

重要的是能否以所需方案與房量單位，正確整合旅宿實際使用的OTA。

營運圖漏掉電話預訂

即使線上房量同步，沒人輸入電話預訂，也無法防止重複預訂。熟客、團體、旅行社、包場都要包含。

不確認合約結束時的情況

避免轉換服務時無法匯出顧客、預訂資料，無法查看過去報表，或網域、付款合約是服務商名義等問題。簽約前確認旅宿要持續管理的資產與解約步驟。

導入前檢查清單

已列出目前預訂管道與件數
已掌握預訂、變更、取消時的轉抄作業
已選定最先解決的一個困擾
已區分預訂引擎、通路管理系統、PMS的必要角色
已決定房量、房價、預訂的權威原始系統
已確認全部銷售管道的整合項目與方向
已決定電話預訂與包場登錄方式
已確認線上付款合約、手續費、退款條件
已確認員工權限、操作歷史、個人資訊保存位置
已準備故障聯絡窗口與紙本、試算表等替代步驟
已在示範中試做預訂、變更、取消、退款
已確認解約時的資料匯出與移轉條件
已比較總費用，而非只看月費

請AI協助比較的提示詞

服務費用與整合對象會變更，應記錄官方頁面與報價單的確認日期。不要將管理後台密碼或真實預訂者資訊交給AI。

請協助小型旅宿選擇預訂系統。

首先請提問並整理以下項目。
- 客房數與房型
- 電話、官方網站、使用中各OTA的預訂件數
- 目前使用的預訂台帳、付款、會計系統
- 預訂、變更、取消時困擾的作業
- 員工數與必要權限
- 必要的多語言、付款、清潔、餐飲、報表功能
- 不只月費，也含初始費用與手續費的預算

接著請將必要角色分為
「預訂引擎」「通路管理系統」「PMS」「付款」。

不要一律推薦同一產品，請將官方資訊確認的功能、未確認事項、
報價時應提問的內容整理成表格。
不要處理真實住客資訊、密碼或卡片資訊。