如何讓直訂官網與 Airbnb 和 Booking.com 保持同步

直訂官網的 OTA 同步，是指飯店官網售出一間客房後，必須立即影響 Airbnb 與 Booking.com 仍可銷售的數量。反向也必須運作：OTA 訂房應在另一位旅客訂下同一間客房前，降低直訂頁面的空房數。

不要維護三套獨立日曆。訂房引擎、飯店管理系統（PMS）與通路管理系統應形成單一循環，並對房價、限制、訂房與例外情況訂立明確規則。

本指南從業主的營運角度說明這個循環。

直訂官網 OTA 同步架構

飯店PMS應保存飯店的房型結構與訂房紀錄。訂房引擎在飯店官網顯示即時客房與房價。通路管理系統則與 Airbnb、Booking.com 及其他線上旅行社（OTA）交換支援的資料。

一般流程如下：

旅客直接訂房 → 訂房進入 PMS → 房型庫存減少 → 通路管理系統將新的空房數傳送至 Airbnb 與 Booking.com

OTA 訂房則採相反流程：

旅客在 OTA 訂房 → 訂房進入 PMS → 庫存減少 → 飯店官網與其他已連接通路收到新的數量

在多數設定中，各通路會透過 PMS 與通路管理系統或整合平台交換資料。

官網與 OTA 之間應同步哪些資料

區分共用來源資料與通路專屬內容。

空房與訂房需要最嚴格的控管，因為錯誤可能讓最後一間客房被重複銷售。房價與限制也很重要，但 OTA 套用自身促銷、費用、稅金顯示、折扣或不支援的規則時，旅客看到的結果可能不同。

Smart Order 將其飯店訂房引擎與 PMS 庫存及飯店通路管理系統連接。直接訂房會進入營運日曆、降低指定房池的庫存，並將更新後的空房數傳送至已連接的 OTA 通路。

選擇單一正確資料來源

連接任何系統前，先決定員工應在哪裡管理各項數值。常見架構如下：

• PMS 或通路管理系統控制房型、基礎房價、空房與支援的限制。
• 訂房引擎讀取核准的直訂方案，並將直接訂房寫入 PMS。
• Airbnb 與 Booking.com 接收支援的更新，同時在需要時保留通路專屬內容、促銷、費用、政策或覆寫設定。

不要讓多名員工在三個後台修改相同的基礎空房。事件發生時可適當手動修改，但必須記錄，並在事後與資料來源核對。

單一資料來源也需要負責人。應由一人核准房型對應、房價邏輯、刻意安排的通路配額，以及已連接產品的變更。

空房必須使用同一組實體庫存

先從飯店實際能分配的客房開始。只有在旅客角度可互相替代時，才將客房歸為同一個可售房型。

假設飯店有四間豪華特大床房。官網與 OTA 的彈性方案和不可退款方案是不同房價方案，但都取用同樣四間客房。售出任何一個方案，都應降低連接至該房池的其他所有方案之空房數。

若直訂頁面有自己的配額，或兩個 OTA 產品指向同一實體客房的不同副本，就會出現問題。軟體可能顯示更新成功，但所有通路合計售出的客房卻超過實際數量。

測試需求較低的日期、接近售罄的日期、停用客房與最後一間空房。只有每個事件都改變正確的共用數量，直訂官網與 OTA 同步才可靠。

房價同步不一定代表公開價格完全相同

選擇基礎房價來源並記錄各通路調整。飯店可刻意發布直訂限定方案、加上 OTA 價差、保留 OTA 促銷，或採用不同取消條款。

同步目標是核准的房價策略，不一定是所有畫面顯示相同數字。請確認每種客房與房價方案的以下項目：

• 哪個系統保存基礎房價
• 通路房價是固定、衍生或經過調整
• 哪些稅金、費用、餐食、入住人數費用與折扣會影響顯示總額
• 連線支援哪些限制

在公開官網、Airbnb 與 Booking.com 搜尋一晚與多晚住宿。比較旅客看到的總額與條件，而不只比較 PMS 傳出的房價。

若母房價變更，請檢查所有衍生的直訂與 OTA 房價。基礎價格更新成功，不代表子房價計算或公開總額正確。

Airbnb 與 Booking.com 的連線運作方式不同

Airbnb 官方支援兩種軟體同步選項：同步所有內容，或只同步價格與空房。只同步價格與空房時，房東可在 Airbnb 維護房源內容與訂房設定，且可能保留本機覆寫。業主必須知道哪些欄位由 PMS 控制，哪些留在 Airbnb 端。

Booking.com 表示，個別住宿通常透過通路管理系統連接，而不是自行建立直接 API 連線。其連線工具支援房價與空房，其他功能則取決於供應商連線與住宿設定。

因此，「已連接兩個通路」並不是完整的營運規則。請建立簡短控管表，列出各平台的空房、房價、限制、內容、促銷、稅金、付款、訂房變更與取消之資料來源。

不要假設 Airbnb 僅限日曆的 iCal 連線等同完整的雙向 API。日曆資料可能著重於封鎖日期，未必以相同範圍交換房價、限制、訂房詳情或更新。

開放庫存前先對應房型與房價方案

對應會告訴系統哪些產品相等。官網的「豪華特大床房」在 Booking.com 可能稱為「高級雙人房」，在 Airbnb 又有不同名稱。名稱可以不同，但實體客房承諾必須一致。

針對每個有效產品，檢查房池、最多入住人數、床型、景觀或類別承諾、房價條件、取消政策、餐食與付款方式，再將各房價方案對應至預定方案。

不要只因使用同一間客房，就把官網可退款房價對應至 OTA 不可退款房價。空房池可共用，但價格與政策應分開。

關閉或處理未對應的 OTA 產品。被遺忘的房源可能在直訂官網 OTA 同步流程之外繼續銷售。

了解延遲、失敗與手動覆寫

「即時」是營運目標，不代表可忽略傳送狀態。更新會經過多個系統，OTA 可能因對應、憑證、速率限制、不支援的限制或通路維護而拒絕或延遲訊息。

飯店 PMS 或通路管理系統應顯示失敗更新、受影響的日期與產品、重試狀態，以及足以讓員工回應的詳情。

建立簡單的事件處理規則：

1. 找出受影響的客房、房價、日期與通路。
2. 若有立即超賣風險，手動保護庫存。
3. 記錄暫時性的 OTA 覆寫。
4. 修正來源或對應錯誤。
5. 重新傳送或等待核准的重試。
6. 核對每個公開通路並移除暫時性覆寫。

不要因內部日曆已變更就認定更新成功。公開訂房頁面才是最終銷售介面。

測試所有訂房路徑

使用風險較低的未來日期，記錄起始空房、房價、限制與公開總額，再至少完成一筆直接訂房、一筆 Airbnb 訂房與一筆 Booking.com 訂房。

每筆訂房都要確認正確的 PMS 房型、房價方案、日期、旅客、來源、外部 ID、價格、付款狀態與政策，並確認官網及兩個 OTA 的空房數都下降。

在支援時修改日期與旅客人數。取消訂房，確認既有 PMS 紀錄在不重複的情況下變更，且空房只準確恢復一次。

另外測試最後一間客房。設定僅剩一間、完成訂房，並確認產品在所有通路關閉。針對每個不同的實體房池，以及有特殊限制或付款條件的房價重複測試。

保存訂房 ID、時間戳記、截圖、預期結果、實際結果與處理備註。任何修正後都要重新測試完整循環。

上線後監控同步

前 48 小時內，檢查每筆新增、變更與取消的訂房，以及未來 30 天空房。在銷售繁忙期間多次檢查失敗紀錄。

穩定後，每日監控警示並定期稽核公開房價與空房。飯店新增或重新命名客房、推出房價、變更入住人數定價或限制、連接新 OTA、或更換通路管理系統時，應重新測試。

依原因追蹤事件。反覆出現對應錯誤、手動覆寫、取消遺漏、過期庫存或房價遭拒，代表設定或責任歸屬有問題，而非運氣不好。

常見問題

可以將飯店官網直接與 Airbnb 和 Booking.com 同步嗎？

通常，飯店官網的訂房引擎會連接至 PMS 與通路管理系統，再由它管理支援的 OTA 連線。Booking.com 引導住宿透過通路管理系統連接，Airbnb 則支援核准的 PMS 或通路管理軟體連線。

直接訂房後應更新哪些內容？

訂房應進入 PMS、降低正確房型的庫存、更新營運日曆，並將修訂後的空房傳送至 Airbnb、Booking.com 與其他已連接通路。

所有通路的房價必須相同嗎？

不必。飯店可使用直訂方案、通路調整或 OTA 促銷。業主應定義預期關係，並確認最終旅客看到的總額、政策與限制。

iCal 足以防止重複訂房嗎？

iCal 可交換日曆封鎖資料，但範圍與更新方式不同於完整 API 連線。請與供應商確認時間、欄位與限制，不要假設它會同步房價或詳細限制。

應多久測試一次 OTA 同步？

上線前及任何客房、房價、限制、入住人數、對應或整合變更後都應測試。每日監控警示，並定期進行最後一間客房測試。

一個庫存來源、三個銷售通路

可靠的直訂官網 OTA 同步有賴單一實體庫存結構、核准的對應、明確的房價管理責任、支援的連線，以及可見的失敗處理。

將直訂官網視為真正的通路，而非獨立日曆。當每筆訂房都進入同一筆 PMS 紀錄，並更新 Airbnb 與 Booking.com 的空房，飯店就能在不增加手動庫存工作或可避免的超賣風險下提升直接訂房。