Fake-data demo｜Overlap: low飯店 / 旅宿 / 房務交接
房間放行 Turnover Exception：哪一間不能急著賣給客人？
這個 demo 把 PMS 房態、房務檢查、維修單、客人 ETA、VIP/早到壓力與客訴歷史，整理成「放行 / hold / 換房 / 升等 / 主動通知」的決策。
老闆語言：少一次客訴/退費、少一次櫃台救火、少讓房務靠人腦記狀態。
15:00 前入住壓力摘要
今日假入住46
需 hold 房4
需維修介入3
高價/VIP 早到5
假設：中小型商旅/旅宿；全部為假資料，不代表任何真實旅館。
假房間風險清單
AI 建議處置
櫃台/房務可用說法
房間放行 audit trail
這不是房務 dashboard；是放行權限的例外處理
| 輸入資料 | AI/data 介入 | 改變的決策 | 訪談要驗證 |
|---|---|---|---|
| PMS 房態、房務 checklist/照片、維修單、客人 ETA、訂房等級、客訴/退費紀錄、可替代房型庫存 | 找出晚退房、異味、備品缺漏、冷氣/熱水/門鎖異常、VIP/早到壓力與歷史客訴風險，產生放行原因與缺漏欄位 | 放行、hold、派維修、換房、升等、主動通知延後入住或補償 | 誰有權 hold 房？錯放一間房的退費/差評成本多高？房務/維修/櫃台資料能否在入住前串起來？ |
Gary 可拿去問的 60 秒問題
如果下午 2 點系統指出「這 4 間房看起來已清潔，但有維修/異味/備品/客人早到衝突，建議先 hold 或換房」，現場真的能停放行嗎？還是櫃台只能先賣出去再救火？