快速答案
智慧入住遇到例外時，系統不應只顯示「請洽櫃台」，而要把旅客身份、訂單、已完成步驟、失敗原因、風險等級與建議動作一起交給現場人員。低風險問題可以自動重試；條件明確的任務可以在受限模式下完成；涉及付款、身份、換房、退款或擴大門禁權限的情況，則必須由有權限的人核准。人工接手不是自動化失敗，而是完整服務流程的一部分。
自助入住最容易展示的是順利流程：找到訂單、確認身份、完成付款、取得房卡。但旅館每天真正需要處理的，往往是走不到最後一步的情況。
旅客可能已經填完資料，卻因信用卡授權失敗卡住；房間可能尚未清潔完成；護照姓名與訂單不完全一致；原本核發的手機憑證可能失效；Kiosk、發卡機或門鎖也可能暫時離線。如果畫面最後只留下一句「系統錯誤，請洽櫃台」，旅客就得重新說明，櫃台也得從頭調查。
成熟的智慧入住不必假裝例外永遠不會發生。它真正該做到的，是在自動流程停下來時，把已知資料、失敗原因、風險與下一個可行動作，一起交給能處理的人。
錯誤提示不等於服務交接
「付款失敗」「找不到訂單」或「請洽櫃台」都只是狀態，並沒有告訴下一位接手者該做什麼。對旅客而言，這類訊息甚至會讓人懷疑剛才填寫的資料是否全部消失。
好的交接要保存上下文。櫃台打開任務時，應該立即看見這位旅客是誰、訂單是否有效、身份是否已驗證、房間是否已分配、付款走到哪一步、是否曾核發憑證，以及系統為什麼停止。旅客已完成的步驟不應被清空，需要再次確認的欄位則要清楚標示。
Oracle OPERA Cloud 的入住文件把報到拆成多個相互關聯的檢查點，包括旅客與訂單資料、隱私偏好、證件、房間、付款、登記卡與房卡。這也說明，入住不是按下一個按鈕，而是一連串有前後關係的狀態。例外處理若只留下最後一個錯誤碼，就會把前面累積的資訊全部浪費掉。
比較好的旅客訊息可以是：「付款確認尚未完成；其他入住資料已保留。櫃台將從付款步驟接續處理。」同一時間，櫃台任務卡則顯示：「身份已驗證／房間已分配／付款待確認／尚未核發房卡。」這才是完整的交接。
先把例外分成四級，不要全部丟給櫃台
並非每一個異常都需要真人，也不是每一個異常都適合自動重試。旅宿可以依照風險、可逆性與對旅客權益的影響，把例外分成四級。
第一級：可以自動重試
短暫的 API timeout、印卡機忙碌、網路延遲或資料同步尚未完成，可以在次數與時間受限的條件下自動重試。系統要避免無限循環，也要讓旅客知道目前正在處理，而不是畫面看起來完全沒有反應。
第二級：可以受限完成
如果旅客已完成身份與付款、房號與有效時間也已確定，只是雲端短暫無法連線，現場設備可以依預先下放的授權資料完成驗證或發卡。受限模式只能執行既有、低風險且可稽核的任務，不能順便延長住宿、換房或增加通行區域。
第三級：必須人工核准
付款爭議、身份資料不符、換房、延住、退款、補發高權限憑證，或旅客要求開放新的門禁區域，都需要有權限的人判斷。AI Agent 可以整理資料、標記缺少項目並建立任務，但不能自行放寬規則。
第四級：立即終止並升級
疑似冒用身份、被撤銷的憑證持續嘗試、門鎖與房號對應異常，或系統無法確認權限來源時，流程應停止。這時候的目標不是縮短幾分鐘等待，而是避免把錯誤權限交給錯的人。
一張可以接手的任務卡，至少要回答七件事
自動流程轉交真人時，不需要把所有資料一次塞滿畫面，但至少要回答以下七個問題：
1. 這位旅客是誰，身份驗證做到哪一步？ 2. 對應哪一筆訂單、哪個入住日期與房型？ 3. 哪些步驟已完成，哪些仍待處理？ 4. 系統在哪一個節點停止，原始錯誤是什麼？ 5. 這個例外屬於哪個風險等級？ 6. 下一個建議動作是重試、核准、改發憑證還是終止？ 7. 誰接手、何時接手，最後做了什麼變更？
這張任務卡也是班別交接的基礎。夜班人員處理到一半、設備恢復連線或主管隔天回查時，不必依靠口頭記憶還原現場。付款、房號、房卡與門禁異動都能回到同一筆事件紀錄。
NIST AI RMF 強調，組織需要定義人機配置中的角色、責任與監督方式，也要說明系統能力限制以及人工如何介入。放到旅宿現場，這代表「交給真人」不能只是一個按鈕；接手者必須看得到足夠脈絡，也要真的具備暫停、拒絕、改判或撤回的權限。
AI Agent、PMS、Kiosk 與櫃台各自負責什麼
AI Agent 適合理解旅客訊息、整理已知資料、辨識缺少欄位、判斷任務類型並建立交接摘要。例如旅客說「我剛換手機，房門打不開」，Agent 可以確認訂單、入住狀態與原憑證，接著把問題分類為裝置變更與憑證重發。
PMS 是訂單、房況與入住狀態的主要資料來源。Kiosk 是現場互動與任務觸發點。發卡機與門禁設備負責執行已核准的通行權限。櫃台或值班主管則處理需要判斷、承諾或改變權限的例外。
這些角色不能互相冒充。AI Agent 不應因旅客語氣急迫就自行換房；Kiosk 不應在身份未確認時重發房卡；門禁設備不應因後台暫時無回應就放寬區域；櫃台也不應在看不到前因後果時，只靠經驗猜測系統做到哪裡。
真正順暢的交接，是每個系統只做自己有權限做的事，同時把下一位需要知道的資訊留下來。
五種常見例外，應該怎麼接住旅客
房間尚未就緒
系統可以保留已完成的報到資料、顯示預估等待狀態並通知櫃台；換房、升等或補償則由有權限的人決定。旅客不需要重新填寫資料，也不應在房況未確認時先拿到錯誤房間的鑰匙。
付款或押金失敗
系統可以提示重新刷卡或改用其他支援方式，但涉及爭議款、押金減免或事後付款承諾時，應交由櫃台處理。在付款條件未成立前，房卡與門禁權限不應先被完整核發。
身份資料不一致
姓名拼法、同行者、訂房人與實際入住者不一致，都可能有合理原因，但不能由 AI 自行猜測。系統應保留已掃描資料、指出不一致欄位，讓現場人員核驗證件並記錄判斷。
行動鑰匙或房卡失效
系統要先確認舊憑證狀態與使用紀錄，再決定暫停、撤銷或重發。旅客換手機與手機遺失看似相似，風險卻不同：前者可能是裝置轉移，後者則需要先停用舊憑證。
Kiosk、發卡機或門禁離線
設備離線不代表全部流程都必須停擺，也不代表可以跳過規則。已授權、時間清楚、風險低的任務可以進入受限模式；需要改變訂單、付款或權限的任務則等待恢復連線或轉人工處理。
交接品質也應該被衡量
旅宿常用自助入住完成率衡量系統成效，但只看成功率會忽略那些最後需要真人接手的旅客。更完整的指標還應包括：從異常發生到真人接手的時間、旅客是否被要求重複提供資料、第一次接手是否解決、同一問題是否反覆轉派，以及是否發生錯誤放行或權限未撤回。
人工推翻系統建議的頻率與原因也值得記錄。NIST 在人機互動指引中提到，這類資料有助於理解系統限制。對旅館而言，如果櫃台經常推翻「訂單不存在」的判斷，可能不是員工偏好人工處理，而是姓名比對、OTA 訂單同步或資料格式本身需要改善。
例外不是只能被消滅的噪音。它也是營運訊號：哪個流程最容易卡住、哪台設備最常失敗、哪種旅客需要更多引導，以及哪些規則讓現場人員不得不反覆繞過系統。
真正成熟的自助服務，知道何時把人請回來
自助入住的目的不是把櫃台從旅館裡拿掉，而是讓標準任務更順，讓現場人員把時間留給需要判斷、安撫與承擔責任的時刻。
當一切正常，旅客可以快速完成報到、取得憑證並進房；當事情偏離標準流程，系統則應清楚知道自己可以做什麼、不能做什麼，以及應把任務交給誰。這條從自動化到人工接手的路徑如果被設計好，例外就不再是旅客被丟回起點，而是服務換了一位更適合的接手者。
檢查一套智慧入住系統時，可以先問一個很簡單的問題：當流程停下來，櫃台收到的是一個錯誤代碼，還是一張能立即行動的完整任務卡？
智慧入住例外交接常見問題
所有例外都應該交給櫃台嗎？
不需要。短暫延遲可以自動重試，已授權且風險低的任務可以在受限模式下完成。涉及身份、金錢、換房、退款或擴大通行權限的任務，才應交由有權限的人核准。
AI Agent 可以直接幫旅客重發房卡嗎？
AI Agent 可以整理需求、確認缺少資料並建立任務，但重發房卡前仍要確認旅客身份、舊憑證狀態、房號與有效時間。真正的權限核發應由門禁或發卡系統依規則執行，高風險情況則需要真人核准。
如何避免旅客到櫃台後重新說明一次？
交接任務必須保存訂單、身份驗證狀態、已完成步驟、失敗節點、錯誤原因與建議動作。櫃台應從失敗點接續，而不是重新建立一筆入住流程。