床位上架訂房網站：超賣到底發生在哪一步
青年旅館床位庫存怎麼對應到訂房網站房型、落差會出現在哪，以及床位與套房混合經營時的設定檢查清單。
一間套房是一個可賣的單位。一間十二人房是十二個可賣的單位，只是它們剛好共用一扇門。青年旅館幾乎每一次超賣，追到底都是某個系統、某條通路或某個人，把這兩件事當成同一件事。
這篇講的是床位庫存實際上怎麼對應到訂房網站的房型，落差會出現在哪，以及開新通路前該先確認什麼。
床位有三種賣法，先弄清楚你是哪一種
在動任何設定之前，先確定你的模式。同樣十二張床，可以有三種賣法。
- 按床位、不分性別。誰都可以訂任何一張床。十二個庫存單位、一個價格。同步最單純，現場管理反而最麻煩。
- 按床位、分艙。女生房、男生房、混合房是三個不同的商品，即使實體是同一種房型。每一艙是自己的庫存池。
- 整間包房。同一間宿舍也能當包房賣給一個團體。它是一個庫存單位，但賣掉的時候必須同時收掉十二張床。
第三種是系統壞掉的地方。賣掉整間就要關掉所有床位，賣掉最後一張床就要關掉整間。這兩條規則如果沒有連在一起，你遲早會把一張床賣進一間已經被家庭包走的房間。
落差通常出現在這幾個地方
通路根本不支援床位層級的庫存
有些訂房網站原生就把宿舍當床位處理，有些只看得懂「房間」，變通方式是建十二個一人房。這個做法能跑，但代表你從那條通路拉出來的住房率、平均房價和任何報表，算的東西跟你的 PMS 不一樣。事先決定哪一份數字算數。
房型與專案的組合會比你預期的多
三種宿舍分艙、兩種取消政策，再加一個不可退款專案，在你還沒開第二條通路之前就已經是十八種組合。每一種組合都是一組可能設錯的對應。刻意把矩陣維持得小一點：六個專案跟十八個專案之間的營收差距，通常小於一次對應錯誤的代價。
分配庫存而不是共用庫存
如果你把四張床分給這條通路、四張分給那條，而不是讓所有通路從同一個池子取用，你會在帳面上賣光、實際上空床。五十床以下的旅宿，共用庫存加即時推送幾乎一定是對的答案。分配庫存是大型旅館用來控管風險的工具，不是小旅宿該用的。
包房和床位同時上架，但兩邊沒有連動
把同一間宿舍既當床位賣、又當包房賣，是很合理的營收決定，前提是系統知道這兩個商品共用同一批床。如果通路那邊只是兩個各自獨立的房型，那它們就是兩份庫存，中間沒有任何東西會幫你擋。在確認系統真的有把兩者綁起來之前，先只賣其中一種。
只有一邊知道的維修床
一張壞掉的上舖，在 PMS 裡停用了但通路管理系統不知道，那就是一次保證會發生的趕客。這是我們看過最常見的原因，而它完全是庫存存在兩個系統的後果。
床位與套房混合經營的設定檢查清單
- 先在紙上把庫存表畫出來。每一張實體床位、它屬於哪個池、它能不能同時被包房商品賣掉。這件事在打開任何後台之前做。
- 名稱到處都要一模一樣。PMS 裡叫「6F 混合房」，每條通路上就叫「6F 混合房」，不要變成「混合房 6F」。以後在趕時間的狀況下對這些名字的人是你自己。
- 決定哪個單位是真理。床或房，報表上選一個，換算只在邊界做，不要在中間換來換去。
- 把包房商品和床位池明確綁在一起。如果你的系統做不到，那就不要把整間房當包房賣。那筆營收不值得一次趕客。
- 先開一條通路，等一個禮拜。看一張真實訂單怎麼流過來，再開第二條。一條通路時很明顯的問題，四條通路時會變成考古。
- 測一次關房。手動把一張床停用，然後確認它從每一條上線中的通路上消失。沒有消失就先停下來修，不要繼續往下走。
- 每次結構性變動後重驗一次。新房型、宿舍改名、人數上限調整，每一項都是重新驗證，不是改一行字而已。
結構上的解法
上面這張清單，大半是在防守「庫存住在兩個地方」這件事。當日曆和通路串接是同一套系統，床位池跟包房商品共用同一份來源，把一張上舖停用就是一個動作而不是兩個。Kimchee 的功能頁說明我們怎麼處理宿舍：床位層級的日曆，通路管理內含在產品裡，所以沒有第二份庫存要跟。目前串接的平台列在通路頁。
計價上宿舍以四張床換算成一間房，所以床位多不會讓月費跳一個量級，通路管理也不另外收費，實際級距寫在價格頁。
我們會做成這樣，是因為我們自己在釜山的三間住宿就同時經營床位和套房，而維修床的問題在我們從結構上修掉之前，實實在在讓我們趕過客人。
這個禮拜可以做的一件事
不管你用什麼系統，去跑一次關房測試。把一張床停用，然後打開你有在賣的每一條通路，確認它真的不見了。十五分鐘，但它會告訴你今晚的超賣風險到底有多高。