1. 從確切的客房、房價專案、入住日期、入住人數、裝置、市場和 Genius 等級開始。
2. 列出所有進行中的促銷活動，並確認哪些符合同一搜尋條件的資格。
3. 在執行旅客端測試之前，計算可接受的最低飯店負擔價格。
4. 分別在登出和登入狀態下，於電腦版和行動裝置上驗證優惠，接著檢查實際訂房的價格明細。
Booking.com Genius 折扣疊加 會使房價看起來低於單一促銷旁顯示的折扣百分比。Genius 房價可能有資格與行動裝置房價、指定國家房價、限時優惠、行銷活動或其他目標優惠一起使用。有些折扣可能由住宿方負擔，有些由 Booking.com 負擔，而有些則完全無法合併使用。
比較保險的問法不是「Genius 總是會疊加嗎？」，而是「這個客房、房價專案、旅客、裝置、市場和日期套用了哪些調整，飯店最終將收到多少金額？」
為何 Genius 價格難以解釋
Booking.com 根據旅客資格和住宿目前的設定顯示優惠。如果其中一人已登入、具有不同的 Genius 等級、使用行動裝置、從另一個國家搜尋或符合平台贊助的獎勵資格，兩名員工即使搜尋相同日期也可能會看到不同的價格。
促銷活動也可能僅適用於選定的客房或房價專案。因此，最便宜的公開結果可能與收益管理員打算測試的房價是不同的產品。
一個 Genius 折扣 可以與其他符合資格的優惠合併使用，但這種組合並非通用。帳號必須啟用房價疊加功能，且每個優惠仍有其專屬的資格規則。請驗證住宿的設定，而非假設每個 Genius、行動裝置或目標房價都會疊加。
本文著重於該項驗證。並不探討飯店是否應加入 Genius，或將 Genius 與優選合作夥伴 (Preferred Partner) 參與計畫進行比較。
定義您正在測試的確切房價
在開啟後台 (Extranet) 之前，請記錄一個完整的測試案例：
- 住宿和貨幣；
- 入住登記與退房登記日期；
- 房型和房價專案；
- 大人、兒童和客房數量；
- 餐食、取消條款和付款時間；
- 電腦版或行動裝置；
- 旅客所在國家或市場；
- 登出、登入狀態以及 Genius 等級；以及
- 顯示價格中是否包含稅項及費用。
請勿將第一個搜尋結果價格與 飯店管理系統 的基本房價進行比較。請透過最終價格顯示確認相同的客房、專案、入住人數和條件。
接著確定主控房價。如果通路管理系統傳送母房價，請記錄傳送給 Booking.com 的數值。如果房價是直接在後台中管理，請重新開啟日曆並擷取儲存的金額。衍生房價、依入住人數定價和兒童收費都可能在套用任何促銷活動之前改變起始數值。
審查後台中所有符合資格的促銷活動
開啟正確住宿的 Booking.com 後台 並檢查 促銷活動 以及該帳號可用的 Genius 設定。選單名稱可能有所不同，但審查過程應能回答相同的問題。
- 確認哪些客房和房價專案參與 Genius。
- 記錄已設定的 Genius 折扣以及任何更高等級的福利或獎勵。
- 列出進行中的行動裝置、指定國家、早鳥、晚鳥、行銷活動、限時或自訂優惠。
- 記錄每個促銷活動的預訂日期、入住日期、排除日期、最短入住天數、預訂時間範圍、市場、裝置和客房專案範圍。
- 檢查促銷活動是由住宿負擔、平台負擔還是混合負擔。
- 找出帳號中顯示的排除項目或疊加控制設定。
- 注意排定在測試期間開始或結束的促銷活動。
請勿將促銷活動總覽視為顯示的所有優惠都會影響飯店款項的證據。進行中的促銷活動可能不符合選定旅客或產品的資格，而平台負擔的調整可能僅會出現在旅客優惠或訂房明細中。
Smart Order 的 飯店通路管理系統 可保持母房價與對應的 Booking.com 產品具有可追溯性，讓收益團隊在套用特定通路的折扣之前，能獲得可靠的起始數值。
保持 Booking.com 母房價的可追溯性
從單一來源管理對應的基本房價，然後獨立出 Booking.com 內套用的 Genius 與促銷活動層級。
計算可能的最低飯店負擔房價
將每個符合資格的折扣轉換為房價瀑布流。從適用促銷活動的金額開始，接著依序套用可能的扣減。請勿只是單純相加百分比。
舉例來說，如果一間客房的起價為 200，且連續套用兩個由飯店負擔的 10% 折扣，結果將是 162：第二次折扣是套用於 180，而非最初的 200。確切的順序與符合資格的基數可能會有所不同，因此請依據帳號規則與觀察到的結帳明細來計算，而不要假設此範例是 Booking.com 的通用公式。
計算出租售價格後，需考量佣金、住宿負擔的福利、飯店吸收的稅金、支付費用以及變動的入住成本。將平台負擔的折扣分開計算，因為它們可能會降低旅客價格，但不會以相同方式減少飯店合約上的住宿金額。
請使用此對照公式：
預期淨貢獻 = 飯店應收款項減去通路費用減去飯店負擔的福利減去支付成本減去變動入住成本
在測試之前設定一個停損點。如果最低的可能飯店負擔結果低於核准的底線，請在更多日期符合資格之前，縮小範圍或暫停疊加的促銷活動。
測試 Genius 與其他促銷活動是否會疊加
在每次搜尋中使用相同的日期、客房、入住人數、貨幣、市場和取消條件。藉由使用受控的瀏覽工作階段來清除快取的假設，而非比較不同員工的螢幕截圖。
- 在電腦版上登出搜尋，以建立公開參考價格。
- 在電腦版上使用相關的 Genius 等級登入並搜尋。
- 在符合資格的行動裝置上重複進行公開搜尋。
- 在行動裝置上登入同一個 Genius 帳號並重複搜尋。
- 開啟確切的客房與房價專案，並繼續進行至付款前的最終價格畫面。
- 展開所有可見的折扣或價格明細，並記錄套用的標籤。
- 將最終旅客價格與計算出的房價瀑布流進行比較。
一次只更改一個條件。如果行動裝置的 Genius 搜尋結果較低，請在具備行動裝置資格但未登入 Genius 帳號的情況下重複測試。這樣可以獨立判斷額外的折扣是來自行動裝置專屬目標、Genius 還是兩者的組合。
請勿從價差的幅度來推斷費用由誰負擔。表面上可見的 10% 折扣並不能證明飯店負擔了 10%。負擔歸屬與佣金處理方式必須在訂房和財務記錄中確認。
透過受控的訂房進行驗證
對於高風險的行銷活動，請在需求較低的日期建立一筆經過授權且可退款的測試訂房。保留旅客端的最終價格，接著在後台與飯店管理系統 (PMS) 中檢查該筆訂房。
比對客房、房價專案、日期、入住人數、基本住宿價值、套用的促銷標籤、佣金基礎、稅金、費用以及預期的住宿應收款項。在政策允許範圍內取消訂房，並確認空房狀況是否如期恢復。
訂房記錄是比搜尋螢幕截圖更有力的證據，因為它顯示了實際產生的商業結果。如果記錄無法解釋差異，請擷取訂房編號並要求合作夥伴支援團隊找出套用的優惠及負擔歸屬。
診斷常見的疊加症狀
登入後的行動裝置價格遠低於預期。 檢查 Genius 資格、行動裝置房價、目標國家優惠、行銷活動日期，以及同一個專案是否可以疊加第二個促銷活動。
旅客看到低價，但飯店應收款項正常。 在更改飯店的基本房價之前，請先查看是否有由 Booking.com 負擔的獎勵或錢包/獎勵回饋等因素。
只有一間客房有大幅折扣。 比較參與 Genius 的客房與每個促銷活動的範圍。受影響的客房可能是唯一同時符合兩項優惠資格的產品。
在沒有更新房價的情況下價格發生變動。 在診斷為通路同步問題之前，請先檢查促銷活動的開始與結束日期、旅客資格、裝置、市場、Genius 等級、稅金和貨幣轉換。
通路管理系統的底價設定未能阻止最終價格的產生。 傳送的基本房價和通路端的促銷銷售價格屬於不同的層級。除了在來源系統中控制外，也必須在 Booking.com 的商業設定中控制促銷底價。
記錄測試條件、螢幕截圖、母房價、預期的房價瀑布流、觀察到的最終價格、訂房明細和費用負擔證據。在更改任何促銷活動後重新檢查；關閉一項優惠可能會讓另一個符合資格的房價顯現出來。
常見問題與解答
Booking.com Genius 可以與行動裝置房價合併使用嗎？
在符合資格的設定下是可以的，但這種組合並非通用。請檢查住宿的疊加設定，並驗證確切的登入後行動裝置搜尋與訂房明細。
飯店應該將折扣百分比相加嗎？
不應該。請以符合資格的基數為基準依序計算，並將飯店負擔和 Booking.com 負擔的調整項目分開。
為什麼兩位 Genius 會員會看到不同的價格？
他們可能有不同的 Genius 等級、裝置、市場、貨幣、符合資格的促銷活動或客房專案的空房狀況。在比較之前，請確保比對每一個條件。
最低的旅客價格一定會同樣減少飯店的款項嗎？
不一定。最終價格可能包含由平台負擔的獎勵。請利用訂房與財務記錄來確定飯店實際的應收款項。
促銷活動發生疊加最可靠的證據是什麼？
受控的搜尋能獨立出每個資格條件，而經過授權的測試訂房則能確認套用的優惠以及最終的飯店應收款項。
Genius 疊加應被視為一項房價審查，而非僅根據一個標籤進行猜測。請追蹤母房價，列出所有符合資格的促銷活動，一次測試一個條件，並在同意維持疊加優惠啟用狀態之前核准最終的淨貢獻。
