案例研究 · 東京 · OPERA Cloud

黃金週不再等於黃金加班

一間東京商務酒店以 OPERA Cloud 的退房數據預測清房工作量,取代30天前的試算表預測,假期季度的客房部加班減少18%。在黃金週的雙重退房高峰期間,每間客房都在15:00前重新納入可售庫存,這在 RevPAR 按年上升15%的情況下尤其重要。

−18%客房部加班時數,假期季度對比基準
15:00黃金週每一天,所有客房重新納入可售庫存
60%日本酒店報告人手不足帝國數據銀行

實測成果,物業應客戶要求匿名。指標已按議定基準核實。

問題:退房量翻倍,排班卻沒有

黃金週的行程在固定日子交替,4月29日至30日和5月3日的退房量接近平日的兩倍。提前30天的人工預測(在該預測期的 MAPE 約15%)把這些高峰拉平成一個平均值,固定排班只能以加班和遲交客房來應對。

改變了什麼

清房預測是指根據物業系統已有的退房日期,預測客房部每天必須清潔多少間退房客房,再透過物業的每房分鐘標準換算成工時。

OPERA Cloud 的退房和抵達數據驅動逐日的清房預測,再透過物業的每房分鐘標準換算成客房部工時。工時從淡日移到高峰日;主管提前一星期批核重新分配。酒店員工排班的運作方式 →

需求配對工時所需工時(按退房量)舊有固定計劃
0501001502004月27日, 需求配對工時: 984月28日, 需求配對工時: 904月29日, 需求配對工時: 1504月30日, 需求配對工時: 1665月1日, 需求配對工時: 1205月2日, 需求配對工時: 1065月3日, 需求配對工時: 1584月27日4月28日4月29日4月30日5月1日5月2日5月3日 4月27日, 需求配對工時: 98 · 所需工時(按退房量): 96 · 舊有固定計劃: 112 4月28日, 需求配對工時: 90 · 所需工時(按退房量): 88 · 舊有固定計劃: 112 4月29日, 需求配對工時: 150 · 所需工時(按退房量): 152 · 舊有固定計劃: 112 4月30日, 需求配對工時: 166 · 所需工時(按退房量): 168 · 舊有固定計劃: 112 5月1日, 需求配對工時: 120 · 所需工時(按退房量): 120 · 舊有固定計劃: 112 5月2日, 需求配對工時: 106 · 所需工時(按退房量): 104 · 舊有固定計劃: 112 5月3日, 需求配對工時: 158 · 所需工時(按退房量): 160 · 舊有固定計劃: 112
黃金週每日客房部工時:需求配對工時(柱)緊貼所需工時(琥珀色);舊有固定計劃(虛線)在4月29日至30日和5月3日的高峰覆蓋不足,加班就藏在這些缺口裡。

圖表背後的數據

日期所需工時舊有固定計劃需求配對工時
4月27日9611298
4月28日8811290
4月29日152112150
4月30日168112166
5月1日120112120
5月2日104112106
5月3日160112158
「行政管家提前十天就看到退房高峰,自己把工時調了過去。以前這種對話都是在加班費已經付出之後才發生。」
房務總監

HotelCadence 是專為酒店而設的人力管理軟件。它讀取您物業系統內已有的預訂,逐小時預測各部門的繁忙程度,據此編排班表,記錄實際工時並準備薪酬計算。每份班表均由部門主管審批。每位排班員工每月6美元起。

人工預測為何沒有捕捉到退房高峰?

排班提前30天鎖定,所依據的預測在該預測期的誤差約15%,而黃金週的退房會隨國內行程的交替集中在特定日子。OPERA Cloud 掌握確切的退房日期;試算表排班卻從未查看。

加班去了哪裡?

實施前:固定人手在高峰日面對翻倍的清房工作量,缺口只能以高價加班填補,客房仍然遲交。實施後:工時從非高峰日移到高峰日,總工時變化不大,加班減少18%,每間客房都在15:00前交回。

假期以外的星期也有幫助嗎?

有。退房量每星期都在驅動客房部的工作量,而60%的日本酒店報告人手不足(帝國數據銀行),所以把稀缺的員工工時對準實際清房量,每天都很重要。黃金週是失誤代價最高的地方。