1. 從一種客房、一個住宿方案、一類目標客群及明確的入住期間開始。
2. 上線前，先計算套用方案折扣、優惠券、點數及稅費後的旅客最終價格。
3. 確認促銷活動採用的基準房價是由飯店管理系統還是Rakuten Travel控管。
4. 使用確切日期與旅客條件測試公開優惠，並持續監控首批訂房。
設定 Rakuten Travel 促銷活動時，應為旅客提供清楚易懂的優惠，同時不削弱飯店的價格架構。主要風險並非輸入錯誤的折扣百分比，而是方案折扣、優惠券、飯店出資點數或活動福利以飯店未編列預算的方式疊加使用。
Rakuten Travel 透過住宿方案銷售客房，因此促銷活動屬於更完整產品組合的一部分，涵蓋房型、方案、餐食、入住人數、取消條款、訂房期間、入住日期、點數、優惠券及最終付款條件。
請採用可控管的設定流程。先定義商業成果，再將促銷活動套用於範圍較小的產品，確認最終售價，並僅在首批訂房符合核准利潤後才擴大適用範圍。
進入設定畫面前，先寫明促銷規則
建立一份簡短的核准說明，讓其他管理者無須查看帳戶也能理解。請列明促銷名稱、目的、目標旅客、適用房型與方案、訂房期間、入住期間、排除日期、折扣或福利、出資來源、房晚數上限，以及可接受的最低淨收益。
確認此優惠的目的，是填補需求較低的平日、獎勵提前訂房、銷售最後一刻的空房、延長住宿天數，還是觸及特定 Rakuten 客群。缺乏單一可衡量目標的促銷活動很難適時停止，因為每筆訂房都可能被視為額外需求。
請分開設定訂房日期與入住日期。訂房期間決定旅客何時可以預訂；入住期間則決定旅客何時可以使用折扣入住。請檢查國定假日、節慶、旺季週末，以及飯店預期無須折扣也能售出的日期。
指定一名可上線、暫停及審查優惠的負責人。接待處人員應能從訂房中辨識促銷活動，但未經核准，不應在與旅客溝通時自行變更活動內容。
確認基礎方案與房價管理方
選擇用於提供客房、包含項目、取消政策及起始價格的住宿方案。將其房型、餐食、入住人數、稅費、訂房截止期限、入住期間及付款規則，與已核准的促銷活動逐一比對。
接著確認基準房價平時由何處管理。如果飯店管理系統或通路管理系統負責傳送方案房價，日常價格調整應繼續在該系統中進行。如果業者直接在 Rakuten 的業者後台管理方案，則應以該後台為準。在錯誤位置手動修改基準房價，之後可能遭到覆寫，並意外改變促銷結果。
請勿將新折扣套用至原價本身已屬臨時價格的方案。應先恢復或記錄已核准的基準房價。團隊必須能回答一個簡單問題：「這項折扣是以哪個價格為基準？」
如果多個方案共用同一個客房庫存池，請確認促銷活動只是增加同一批客房的銷售方式，而不是增加客房數量。開放促銷方案不應提高實際庫存。
計算旅客最終價格與飯店淨收益
計算時應以旅客最終支付金額為基礎，而不只是宣傳中的折扣。應納入基礎方案價格、促銷折扣、適用優惠券、點數折抵或額外點數成本、稅費、服務費、餐食、付款成本、通路費用及任何由飯店出資的福利。
例如，當飯店出資的優惠券也可套用時，10% 的方案折扣可能變成更深的實際折扣。額外點數不一定會降低畫面上顯示的房價，但仍會增加飯店的獲客成本。餐食或延遲退房福利即使對旅客顯示為免費，也會產生服務成本。
上線前應核准三項數字：一般情況下旅客的最終價格、促銷後旅客的最終價格，以及扣除所有已知費用後飯店預期取得的淨收益。請將淨收益與接待該次住宿的成本，以及將客房保留給其他通路的價值進行比較。
Smart Order可在同一套檢視流程中串連已核准的房價、訂房來源及實際飯店收益。管理者無須只依賴訂房總額，即可查看 Rakuten 優惠是否有效填補預定日期的空房。
逐項扣除成本後，檢視促銷收益
使用 Smart Order 比較客房收益、訂房來源及住房率，再決定是否擴大通路促銷活動。
以小範圍建立促銷活動
選單名稱可能因業者類型、市場、合約及帳戶設定而異。請在 Rakuten 業者管理後台中，開啟該業者可用的住宿方案、活動、優惠券或促銷優惠設定。
請依照以下作業順序：
- 編輯前先確認業者，尤其是在管理多家業者的帳戶中。
- 選擇預定的房型與住宿方案，再確認餐食、入住人數、取消條款及付款方式。
- 分別設定訂房期間與入住期間，並確認使用正確的時區。
- 將已核准的折扣、優惠券、點數條件或附加福利套用至最小的適用範圍。
- 排除旺季日期，以及所有未達最低淨收益要求的房型與方案組合。
- 檢查摘要、儲存優惠，並記錄操作人員、時間及所用設定。
請勿因畫面支援批次選取，就將優惠複製到所有方案。先從一個具代表性的房型與方案組合，以及較短的日期範圍開始。小範圍上線可讓價格衝突更容易被發現，修正成本也更低。
檢查折扣與福利是否疊加
儲存後，檢查可能套用於同一搜尋條件的所有價格影響因素，包括住宿方案本身的折扣、參與中的 Rakuten 活動、優惠券、會員或 App 條件、出資點數、連住福利、提前訂房優惠、最後一刻優惠，以及任何手動修改的基準房價。
應區分「可同時顯示」與「可同時兌換」。搜尋結果中可能同時顯示兩個優惠標示，但只有其中一個會改變最終付款金額。唯一可靠的檢查方式，是沿著旅客訂房流程操作至能查看最終可訂金額與條件的階段。
也請比較取消費用的計算基準。如果取消費是根據訂房價格計算，工作人員就必須保留該筆訂房金額。如果某項福利有獨立的成本或退款規則，應將其記錄在營運與財務部門使用的方案備註中。
當合併後的結果低於飯店核准的價格底線時，請勿僅針對促銷活動提高基準房價以彌補差額。應暫停衝突的福利、縮小適用資格，或重新設計優惠，讓正常房價維持可信度。
以旅客身分測試優惠
請使用優惠要求的確切入住日期、訂房日期、客房數、成人與兒童人數、語言、市場、裝置條件及會員身分進行搜尋，並核對房型、方案、餐食、取消政策、付款方式、稅費及包含的福利。
進行三次搜尋測試：一次使用應符合資格的條件、一次使用排除日期，另一次使用不應符合資格的旅客條件。正向測試可證明優惠已上線，兩次反向測試則可證明適用界線正常運作。
繼續操作至最終訂房確認頁面，並記錄顯示的總金額。除非飯店已核准受控測試訂房，否則請勿完成預訂。若確實需要測試，請選擇需求較低且可取消的日期，並確認訂房顯示正確的方案、最終價格、福利、付款方式及庫存扣減。
監控首批訂房，並在觸發明確條件時停止活動
逐筆檢查首批訂房，不要等到月報出爐才處理。將已訂房型與方案、入住日期、旅客最終價格、優惠券或點數使用情況、付款方式、預期通路費用及淨收益，與核准說明逐一比對。
若最終價格低於核准底線、排除日期變得可預訂、其他優惠意外疊加、庫存從錯誤的客房池扣除，或接待處人員無法向旅客說明優惠福利，應立即暫停促銷活動。
取得具參考價值的樣本後，請比較訂房增量、取消率、住宿天數、淨平均每日房價，以及被取代的全價訂房需求。應根據促銷活動帶來的實際貢獻，決定保留、縮小或結束活動，而不是只看訂房筆數。
預防日後發生房價衝突
為所有通路維護一份統一的促銷活動登記表。針對每項進行中的優惠，記錄日期、客群、房型與方案範圍、折扣、優惠券、點數、出資來源、預期淨收益、負責人、審查日期及停止規則。
每當基礎方案變更、新優惠券上線、點數出資方式改變，或有串接系統接管房價控制時，都必須重新檢查價格。即使無人編輯促銷活動本身，舊活動仍可能變得無利可圖。
優惠結束後，封存核准紀錄與首批訂房的驗證資料。下一次活動應以本次結果為基礎，而不是直接複製某個折扣百分比，卻遺漏原有的排除條件。
常見問題
Rakuten Travel 促銷活動可以與優惠券合併使用嗎？
這可能取決於優惠內容與帳戶設定。上線前，請使用確切的適用條件進行搜尋測試，並確認最終可訂金額。
飯店是否應在加入折扣前提高基準房價？
請採用飯店核准的一般房價策略。只為了顯示折扣而提高基準房價，可能在其他通路造成價格一致性、信任及利潤問題。
通路管理系統可以建立所有 Rakuten 促銷活動嗎？
不一定。串接系統可能負責控制基準房價，而 Rakuten 專屬活動、優惠券或點數設定仍需在業者後台管理。請記錄每個欄位的管理權責。
如何確認促銷活動已準備就緒？
符合資格的搜尋會顯示已核准的最終價格與條件，不符合資格的搜尋不會套用優惠，庫存維持正確，且首筆訂房能產生預期的飯店淨收益。
