酒店前台最怕的不是客房不够，而是房態不同步：OTA 已售、酒店系統仍顯示空房；客人到店被告知「正在打掃」，清潔任務卻還在微信群裡喊。超售、漏排房、清潔延誤疊在一起，差比評估空置更貴。
業務怎麼拆：預訂、排房、清潔、入住離店
一套能用的酒店系統，至少把四段狀態機打通，而不是只做「訂單列表」：
- 預訂佔用：渠道單寫入後立即佔庫存，取消與 no-show 規則明確釋放時機
- 排房：按房型、樓層、連房、維修鎖定自動／半自動分配
- 清潔工單：退房觸發清掃，查房合格才改可售；維修單與房態互鎖
- 入住／離店：押金、加收、延遲退房與夜審口徑一致
Excel 能記今晚有幾間空，記不住「清潔中不可售」與「維修鎖定」的併發。真正導致前台扯皮的是多渠道寫庫存時沒有統一佔用鎖。
怎麼設計：角色與數據
角色建議拆成：預訂員、前台、客房主管、樓層服務員、維修、夜審。客房服務員只看自己樓層任務；前台不能把維修房直接賣出；夜審負責關帳與房態日切。
- 房型與物理房間：可售屬性、樓層、連房、吸煙／無障礙標籤
- 庫存日曆：按晚佔用，含預留、確認、鎖房
- 房態：空淨／空髒／住淨／住髒／維修／停用
- 清潔任務：觸發來源、責任人、開始／完成、查房結果
- 訂單：渠道、擔保規則、特殊要求、同來人
界面邊界要硬：OTA／官網下單只寫「房型庫存」，物理排房可後置，但確認到店前必須落到具體房號或明確的可售池。清潔未完成，房態不得變空淨。
怎麼開發與驗收
渠道對接用統一庫存服務：下單佔庫、支付超時釋放、取消回滾。推送失敗要可重試且冪等，避免同一訂單佔兩間。清潔端以掃碼房號開工，防止點錯房。夜審任務把當日未離店、未結帳、異常房態打成清單，而不是靠人肉巡樓。
驗收場景建議覆蓋旺季髒數據：
- 同一房型兩渠道同時最後一間，是否只有一單成功
- 退房後清潔未完成，是否仍可被排給新預抵
- 維修鎖定期間渠道是否還能賣出該物理房
- 延遲退房 overlapping 下一晚訂單時如何提示改排
- 夜審後房態與收銀是否一致
酒店系統的核心不是「漂亮的日曆色塊」，而是佔庫、清潔、維修三條鎖互不打架。
現場常見失敗
超售策略不清：有的店默許超售靠升級消化，系統卻按物理房硬攔，或反過來完全不攔。要把「可超售房型／上限／升級路徑」寫成配置，而不是口頭習慣。清潔計件與質量衝突：只按間數考核會催生漏項；查房不合格應退回任務並影響計件。會員偏好丟失：高樓層、連房等寫在備註裡沒人看，應結構化進排房規則。
落地時先盯什麼
先打通「渠道佔庫 → 排房 → 清潔閉環 → 夜審」，再做收益管理與upsell。上線後兩週重點看：超售／拒單次數、預抵未排房占比、清潔超時導致延誤入住次數、夜審差異單量。這四項降下來，再談智能定價才有基礎。
渠道庫存服務怎麼落
建議單獨做庫存服務，訂單系統與渠道連接器只調用佔庫／釋放／查詢。佔庫要帶過期時間：未支付超時自動釋放，避免「殭屍佔用」。物理排房可以延後到預抵日前一天，但房型級可售數必須實時準確。連鎖多門店時，庫存鍵必須帶門店ID，嚴禁串店扣減。
清潔與維修對庫存的影響要建模：空髒不算可售；維修鎖定從可售池扣除；停用房型在渠道側直接下架。前台手動改房態必須記原因碼，方便夜審查異常。
與收益和會員的邊界
收益管理改價不應直接改歷史訂單，只影響未來可售。會員權益（延遲退房、升房）寫成規則引擎輸入，排房時讀取，而不是靠值班經理記憶。一期可以不做動態定價，但要把「手動調價審批」留好口子，避免人人改價。
數據上至少沉澱：每間夜佔庫來源渠道、排房人、清潔完成時刻、入住辦理時刻。用這些就能定位延誤是清潔慢還是排房晚，而不是開會靠感覺。
夜審與收銀一致性
夜審不僅關帳，還要核對：在住人數、未結帳、鎖房、清潔未完成仍被排房的異常。收銀的延遲退房費、迷你吧消費必須在離店前入帳，夜審後禁止無紅沖改昨天流水。前台交班清單自动生成未完成任務，減少口頭交接漏項。
多渠道退訂規則不同，釋放庫存的時點要按渠道配置。免費升級消耗的庫存要從原房型釋放並佔用目標房型，報表分別統計，避免收益分析被升級攪亂。
培訓前台時用「最後一間房併發下單」和「清潔未完成誤排房」兩個演練劇本，比講功能菜單有效。上線開關建議先關渠道超售，穩定兩週再按房型開放超售上限。
連鎖集團若要中央預訂，先統一房型碼與取消政策字典，再接通庫存服務；字典不統一時不要強行中央化，否則會把單店錯誤放大到全網。
管家式服務的特殊需求（驚喜佈置、接送）建成附加任務單，完成後才允許標記「貴賓預抵就緒」，與普通清潔任務分開考核。