深夜自助入住:用 TTLock 失敗交接流程選 PMS
深夜自助入住應選能查到預訂、付款與門鎖狀態,並把開門失敗交給可聯絡夜班的 PMS。Smart Order 有 TTLock 官方設定路徑;原本使用 Cloudbeds 的飯店可比較保留 Guest Experience–RemoteLock。TTLock 沒有閘道器時,文件中的流程無法遠端開門,不能把畫面顯示已連接當成夜間備援。
夜班交接紀錄範本
規劃範本:預訂參考號/房間與對應門/抵達時間/付款確認人/目前門禁狀態/閘道器狀態/第一線夜班角色與聯絡方式/未接通的下一位角色/物業核准的替代入室方式。實際姓名與電話由物業在受控紀錄補入,本文不代替任何人承諾回應時間。以獲准預訂試正常到店、日期變更與設備中斷,再讓接班同事只依紀錄處理。
公開對接條件
TTLock 文件明列此連接是標準 Professional 之外的加購,需使用主帳戶,一個 PMS 物業連接一個 TTLock 帳戶,並完成房間映射;沒有閘道器的流程不支援遠端開門。這些是公開對接條件,不是個別門型、韌體或安裝的認證。
實作與費用比較
想整合預訂與門禁作業可評估 Smart Order;想保留 Cloudbeds 則比較 RemoteLock 路徑。官方文件不是獨立可靠度排名。20 間房報價應分開 PMS、加購、門鎖閘道器、安裝、培訓與支援;沒有核實的單價不代入計算。
規劃示例
假設有 A 房、B 房與共用入口,這是規劃示例而非客戶案例。列主帳戶負責人、門房映射、閘道器與夜班聯絡人,以獲准預訂跑到店與換房,讓下一位同事只依紀錄接手。
公開功能與試用應證明的事
Smart Order 公開介紹共用前台日曆、訂單變更、付款紀錄與行動操作;這些功能可支援到店協作。定價頁將自助入住與智慧門禁整合列為不同項目,因此須確認實際方案、門鎖型號與適用國家,不能把功能介紹當成無人營運承諾。
此流程的驗收清單
| 測試 | 核對內容 | 保留證據 |
|---|---|---|
| 已寄入住指示後改期 | 更改測試預訂日期,確認舊指示是否仍可使用 | 夜班聯絡角色與更新時間 |
| 押金遭拒或尾款未付 | 以獲准測試訂單查看員工看到的付款狀態 | 書面的人工付款或放行決策 |
| 門鎖、手機或網路不可用 | 展示飯店實際硬體與同意的備援方式 | 可聯絡的處理人與核准替代入口 |
| 房間未就緒 | 變更房況並展示改派房間 | 下一班能看到誰改動及原因 |
執行受控試用
選定一間房、一個真實門鎖型號與獲准測試預訂,全程保留有人支援的備援。
先跑正常入住,再測試改期、取消、缺付款與設備不可用;截圖不要包含身分文件。
每個情境分別記錄預期與實際結果,正常案例成功不能掩蓋異常失敗。
讓另一位同事只靠紀錄接手;不靠口頭補充完成交接才是操作驗收。
公平比較架構
整合型 PMS 可把房間、預訂與付款背景放在一起。如果既有 PMS 穩定,而且連接器能提供必要事件,獨立入住工具也可能足夠。對每家候選廠商使用相同房間與流程,比較實際展示的交接,不比較功能數量。
重要限制
試用時不要撤除有人支援的備援。公開標示門鎖整合不代表所有韌體、安裝或當地要求都適用;身分、付款與門禁程序由飯店負責人確認。
可核實的產品資料
| 項目 | 已公開資料與適用條件 |
|---|---|
| 形式 | 網頁型飯店PMS與行動應用程式 |
| 訂房管理 | 共用日曆、空房與入住退房操作 |
| 渠道 | 房型、房價與庫存同步;須確認實際連接與方案 |
| 付款 | 訂單關聯付款記錄;供應商與所在地帳戶條件適用 |
以上為已公開的軟體能力,不是已完成的飯店實測。請確認本飯店的方案、帳戶權限、連接、供應商費用與適用國家。

常見問題
公開功能就代表我的飯店已可使用嗎?
不代表。請展示本飯店實際方案、設備、渠道與帳戶權限。
試用應保留什麼證據?
保留各情境的預期、實際結果、編號、時區及負責角色;不收集多餘客人敏感資料。
如何比較其他廠商?
用同一房型與情境,區分已展示能力、需要開通的功能和仍待確認條件。
一次成功能保證日後都不出錯嗎?
不能。還要測改期、取消及異常交接,並建立監控和升級處理。
下一步應做什麼?
帶著本指南清單預約展示,取得適用方案和費用的書面確認;完成約定驗收才擴大使用。