飯店管理系統與 Booking.com 整合：哪些資料應該自動同步？

飯店管理系統與 Booking.com 整合實際上能做什麼

當飯店管理系統與 Booking.com 整合時，會在飯店管理系統與 Booking.com 管理後台 之間建立雙向資料連線。這項連線取代了必須手動登入管理後台以更新空房狀況、逐一修改每間客房房價，以及手動將訂房明細複製到飯店管理系統的繁瑣流程。

順暢的整合代表在飯店管理系統中所做的變更會自動同步到 Booking.com，而在 Booking.com 上的訂房也會自動顯示在飯店管理系統中。無論是哪個方向，接待處人員在日常營運中都不需要操作管理後台。

了解每個方向同步的資料類別，以及各類別正確的自動化運作方式，能為您提供一個可靠的方法，來測試目前的整合是否運作正常，並知道在評估全新飯店管理系統平台時該提出哪些問題。

1. 空房狀況同步（飯店管理系統 → Booking.com）

空房狀況同步會將您的客房庫存狀態從飯店管理系統即時推送至 Booking.com。當客房被預訂時，飯店管理系統會減少可用的客房數量，並將更新後的庫存傳送給 Booking.com，以確保同一間客房不會被重複售出。

這項同步必須是即時同步，而非批次處理。一個以 15 分鐘為週期更新 Booking.com 的通路管理系統，會產生 15 分鐘的超額訂房空窗期。如果您的旅宿在該空窗期內收到同一間客房的兩筆訂房——一筆透過 Booking.com，另一筆透過 Agoda——第二筆訂房將會在第一筆訂房的空房減少資訊送達通路前就被確認。

空房狀況同步也涵蓋了客房關閉、維修保留與停止銷售的指令。當接待處人員在飯店管理系統中將某間客房標記為故障時，該客房應在幾秒鐘內從 Booking.com 庫存中消失——而不是等到下一個同步週期才反映。

測試方法： 在住房率較低的日子，透過 Booking.com 進行一筆測試訂房。檢查飯店管理系統反映該筆訂房的速度，以及 Booking.com 上可用客房數量更新的速度。任何超過 60 秒的延遲都值得深入調查。

2. 房價同步（飯店管理系統 → Booking.com）

房價同步是將飯店管理系統房價管理模組中的定價推送至 Booking.com。當在飯店管理系統中建立或修改房價方案時，更新後的房價應該在極短的延遲內顯示於 Booking.com 上——對於直接的 API 連線，通常少於五分鐘。

房價同步涵蓋了幾種房價類型：標準房價、依主房價百分比計算的衍生房價、住宿天數房價，以及適用於特定日期區間的促銷房價。每一種都應該能同步至對應的 Booking.com 房價方案，而無須另外在後台手動輸入。

房價一致性（在所有分銷通路上維持一致的定價）取決於房價同步是否運作正常。如果在飯店管理系統中的房價變更未能推送到 Booking.com，旅宿可能會在不知不覺中於不同通路上宣傳不同的價格。Booking.com 會監控違反房價一致性的情況，一旦發現，可能會降低房源的曝光度或對該帳號進行標記。

測試方法： 在飯店管理系統中，將某個特定房型未來日期的房價更改 $10。檢查 Booking.com 上的對應房價是否在五分鐘內更新。如果沒有，請確認您的整合是使用直接的 API 連線，還是經過了聚合器層級。

3. 限制條件同步（飯店管理系統 → Booking.com）

限制條件是控制 Booking.com 在特定房型與日期區間內可接受哪些訂房的規則。常見的限制條件包括最短住宿天數、最長住宿天數、不接受當日入住、不接受當日退房以及停止銷售。

限制條件同步對於收益管理至關重要。在高需求週末的最短住宿天數限制（要求旅客必須同時預訂週五與週六，而非僅預訂一晚）——只有在該限制條件於該日期的訂房湧入前送達 Booking.com，才能發揮作用。

限制條件同步的失敗比空房狀況或房價同步失敗更難被察覺，因為它們不會立即產生明顯的錯誤。未能推送至 Booking.com 的最短住宿天數限制，只會導致您接收了原本收益策略想要避免的單晚訂房。這種損失反映在流失的收益上，而不是超額訂房的警報。

測試方法： 在飯店管理系統中為特定日期設定最短兩晚的住宿天數限制條件。確認在五分鐘內，同樣的限制條件是否出現在 Booking.com 管理後台的房價日曆中。嘗試直接在 Booking.com 上為該日期進行一晚的測試訂房，以驗證限制條件是否已生效。

4. 旅客訂房明細同步（Booking.com → 飯店管理系統）

當旅客在 Booking.com 上訂房時，訂房明細——包含旅客姓名、聯絡資訊、入住與退房日期、房型、房價方案以及入住人數——應該在訂房確認後的幾分鐘內自動流入飯店管理系統。

此同步方向是從 Booking.com 進入飯店管理系統。接待處不應需要從管理後台手動複製任何訂房明細到飯店管理系統中。手動輸入訂房不僅容易產生轉錄錯誤、造成空房狀況更新的延遲，還會消耗接待處人員的時間，這些時間本應更妥善地運用在接待旅客的服務上。

同步的旅客明細程度取決於旅客的隱私設定與 Booking.com 的資料分享政策。根據旅客的同意設定，其電子郵件地址可能會被隱藏（替換為 Booking.com 的轉發地址）。飯店管理系統應該能正確接收並儲存該轉發地址，以確保透過飯店管理系統發送的任何入住前溝通訊息，都能確實送達旅客手中。

測試方法： 透過 Booking.com 進行一筆測試訂房。確認該筆訂房在五分鐘內顯示於飯店管理系統中，並具有正確的客房、日期、房價與旅客姓名——無需由接待處人員進行任何手動輸入。

5. 付款狀態同步（Booking.com → 飯店管理系統）

付款狀態是不同飯店管理系統與 Booking.com 整合設定中最具變數的同步類別。同步的內容與可靠性，取決於飯店為 Booking.com 訂房所採用的付款模式。

對於採用 Booking.com 虛擬信用卡 (VCC) 付款模式的飯店，Booking.com 會為每筆訂房提供一張可在入住當日扣款的虛擬卡片。飯店管理系統應在訂房同步的過程中接收 VCC 詳細資訊，讓接待處能直接處理扣款，而無須登入後台手動取得卡片資訊。

對於使用 Booking.com Payments（由 Booking.com 向旅客收款並匯給飯店）的飯店，飯店管理系統應接收一個付款狀態標記，指出旅客是否已直接付款給 Booking.com，好讓接待處知道在入住登記時無須再次收款。

對於由飯店直接向旅客現場收款的模式，飯店管理系統中的帳單應在入住登記時反映出未結餘額，讓接待處人員能按正常程序進行收款。

在這三種情況下，進入飯店管理系統的訂房都應該包含付款狀態指示，確切地告訴接待處已支付的金額與未結的餘額——無須登入管理後台進行確認。

測試方法： 當測試訂房進入飯店管理系統後，請確認訂房帳單上已清楚標示付款模式（如適用則為 VCC 詳細資訊，或是付款狀態標記）——完全無須接待處前往 Booking.com 管理後台進行檢查。

直接 API 與聚合器：為何連線類型如此重要

飯店管理系統可以透過 API 直接與 Booking.com 連線（系統與 Booking.com 本身的連線層直接溝通），或是透過介於兩個系統之間的第三方通路管理系統聚合器進行連線。

直接連線能提供更快的同步速度、較少的故障點，以及更簡單的故障排除流程：當出現問題時，只需診斷一個連線即可。聚合器連線則增加了一個轉換層，延遲與錯誤可能會在此處不斷疊加，且缺乏明確的負責方。

您可以向任何飯店管理系統供應商詢問，他們與 Booking.com 的連線是直接連線還是透過聚合器。如果是後者，請詢問使用的是哪家聚合器、他們的正常運行時間 SLA 為何，以及當聚合器停機時會有什麼後果。

飯店管理系統與 Booking.com 整合常見問題

飯店管理系統與 Booking.com 之間會同步哪些資料？

運作正常的整合會同步五個類別：空房狀況、房價與限制條件（飯店管理系統至 Booking.com），以及旅客訂房明細與付款狀態（Booking.com 至飯店管理系統）。每個類別都有不同的同步方向，以及中斷時特定的故障模式。

空房狀況從飯店管理系統同步到 Booking.com 需要多快？

透過直接的 API 連線，空房狀況的變更應該在幾秒鐘內同步至 Booking.com——而非依賴批次週期。任何超過 60 秒的同步延遲都會產生超額訂房空窗期，在此期間，同一間客房可能會在多個通路上被同時預訂。請要求任何飯店管理系統供應商確認他們的同步方法，並提供其 Booking.com 連線的歷史正常運行時間資料。

如果飯店管理系統與 Booking.com 的整合中斷會發生什麼事？

這五個同步類別全都會退回手動流程——空房狀況更新、訂房輸入與房價變更都必須分別在管理後台與飯店管理系統中執行。空房狀況延遲會造成超額訂房風險；房價同步失敗則會引發違反一致性的問題，Booking.com 會對此進行監控並予以懲罰。

飯店管理系統與 Booking.com 的整合是否支援虛擬信用卡？

這是一定要的。Booking.com 的虛擬信用卡 (VCC) 模式會為每筆訂房提供一張獨特的卡片，可在入住當日進行扣款。整合良好的飯店管理系統會在訂房同步時接收 VCC 詳細資訊，讓接待處人員無需登入管理後台即可處理扣款。如果您的系統沒有這個功能，請向您的飯店管理系統供應商確認您所使用的方案級別是否包含 VCC 支援。

針對 Booking.com 整合，直接 API 連線是否比通路管理系統聚合器更好？

通常是的。直接 API 連線具備單一聯絡窗口、更快的同步速度，以及更簡單的故障排除流程。聚合器連線則增加了一個可能發生延遲與轉換錯誤的第三方層級——而且無論是飯店管理系統供應商還是 Booking.com，皆無須負責解決聚合器的停機問題。在評估飯店管理系統時，請務必明確詢問 Booking.com 的連線是直接連線還是經過聚合器。