未滿10間客房旅宿的預訂系統設計：房量、電話預訂與每日營運

未滿10間客房的民宿或Pension，即使導入與大型飯店相同的系統，也可能只是增加設定與輸入作業。另一方面，只依賴紙本台帳與多封預訂電子郵件，容易造成家人或員工之間漏傳資訊、重複預訂及餐飲份數錯誤。

小型旅宿最重要的不是功能多寡。

所有預訂集中在同一處
正確管理最後一間空房
電話預訂也能立即反映
旅宿主人休假時，其他人也能理解狀況
通訊故障時，仍能確認當天住客

本文說明未滿10間客房旅宿所需預訂系統的設計與日常營運，而非比較產品。具體候選可閱讀小型旅宿預訂系統比較。

未滿10間客房時，「一筆預訂的影響」很大
先畫出目前的預訂管道
必要功能1：跨住宿日期的客房房量管理
1. 不要混淆房型房量與實際客房
必要功能2：電話預訂可在30秒內停止銷售房量
1. 在電話旁固定操作入口
必要功能3：集中官方預訂與OTA的房量
必要功能4：不要增加過多房價與方案
必要功能5：確認電子郵件包含必要資訊
必要功能6：一併設計線上付款與取消流程
未滿10間客房時，可稍後導入的功能
小型旅宿實用的每日營運
系統停止時的替代台帳
讓第二個人也能操作
4週導入範例
選擇系統時的最低檢查清單
請AI協助營運設計的提示詞
總結
參考資料

未滿10間客房時，「一筆預訂的影響」很大

8間客房的旅宿若將一間房重複售出，就會影響當天12.5%的房量。通常也無法像大型設施那樣改配其他空房，可能需要聯絡住客、安排替代旅宿、接送及負擔價差。

反過來，即使導入昂貴且功能豐富的PMS，若只有一人輸入、只使用預訂台帳，負擔也可能沒有減少。

小型旅宿需同時滿足以下兩點。

準確管理剩餘不多的房量
讓少量人員也能每天持續完成操作

先畫出目前的預訂管道

選擇預訂系統前，以過去一個月為例，列出預訂入口。

預訂管道
├── 電話
├── 電子郵件、DM
├── 官方網站
├── OTA A
└── OTA B
↓
目前的預訂台帳
↓
房間分配、餐飲、清潔、結帳

回答以下問題。

每月有多少筆預訂
電話預訂占多少比例
有多少筆預訂變更與取消
由誰閱讀預訂電子郵件
會向紙本、試算表、日曆轉錄多少次
在哪裡輸入休館日或包館
向誰傳達餐飲份數、過敏及接送資訊
在哪裡確認營收與入帳

觀光廳的IT活用手冊也指出，將OTA、旅行社、自家網站、電話的預訂轉錄到紙本台帳、房間分配、廚房、顧客台帳與付款憑單，會形成負擔。導入系統的首要目的，就是減少這種重複輸入。

必要功能1：跨住宿日期的客房房量管理

不同於美容院或會議室預訂，住宿會從入住日至退房日占用客房。兩晚預訂，中間那天也不能再出售。

應確認以下功能。

可指定入住與退房日期
連住期間的每一天都會扣減房量
可設定各房型的銷售數
可分配實際客房，或整合其他台帳
可因休館、包館、維修或貓咪休養等封房
可設定不接受單晚、最低連住晚數及不可入住日期

不要混淆房型房量與實際客房

預訂網站可能以「和室」3間等房型為單位銷售，預訂後再分配至「101」「102」。

銷售房型：和室 3間
實際客房：101、102、103

若寵物規定、樓梯、景觀或貓咪可進入範圍等，每間實際客房的條件不同，請確認是否能合併為相同房型。若出現預訂後無法分配的組合，即使房量數正確也無法營運。

必要功能2：電話預訂可在30秒內停止銷售房量

即使通路管理系統同步了OTA之間的房量，若沒有人登錄電話預訂，就無法防止重複預訂。

應能在通話中或結束後立即輸入以下資訊。

抵達與離開日期
房型或暫定客房
人數及兒童區分
餐飲條件
預訂者姓名與聯絡方式
預訂管道為電話
付款方式
暫時預訂或已確認預訂

若輸入項目太多，就容易變成「晚點再輸入」。較適合先只登錄停止銷售房量所需的必要項目，再補充詳細資訊的設計。

在電話旁固定操作入口

放置已開啟管理畫面的專用裝置
只使用一個書籤入口
使用個人帳號，而非共用密碼
將最簡輸入步驟整理在一張紙上
決定暫時預訂的有效期限與確認負責人

若採用「稍後再請會操作的人處理」的方式，最後一間空房就會延遲反映。

必要功能3：集中官方預訂與OTA的房量

若只透過官方網站銷售，預訂引擎內的房量管理可能已足夠。若在多個OTA銷售相同客房，請考慮通路管理系統或整合型服務。

不能只確認「可以整合」這句話。

項目	確認內容
房量	預訂或取消時，各銷售管道的剩餘客房是否改變
房價	能否傳送依日期、星期及人數區分的房價
預訂	能否將新預訂匯入同一本台帳
變更	如何收到日期、人數與方案變更
取消	是否自動釋出房量，或需要人工確認
整合時間	正常時與繁忙、故障時需要多久
支援範圍	是否涵蓋目前使用的OTA與實際方案

銷售管道越多，集客機會越多，但設定與比對作業也會增加。在預訂件數仍少時，不必一次登錄到不會使用的OTA。

必要功能4：不要增加過多房價與方案

未滿10間客房的旅宿，若依房型、餐飲、星期、季節、人數與預訂管道建立大量方案，容易漏改。

初期可縮小至以下內容。

基本客房類型
一晚含兩餐、僅早餐、不含餐等實際提供的餐飲區分
平日、假日前一天、旺季等必要房價區分
官方網站與OTA說明一致的取消條件
貓咪互動條件等，須避免誤解的重要事項

不要將「招牌貓一定會到客房的方案」等，會受貓咪意願或健康狀況影響、無法保證的內容列為銷售條件。請在預訂畫面依最新資訊與注意事項，準確傳達可見到貓咪的場所、時間及能否互動。

必要功能5：確認電子郵件包含必要資訊

即使完成預訂，若住客不理解抵達時間或攜帶物品，電話應對也會增加。

確認電子郵件與預訂完成畫面，至少應考慮以下內容。

是已成立預訂，還是受理預訂請求
抵達日、離開日、晚數、人數、客房與方案
總費用及需在現場另外支付的費用
已付款與現場付款的區別
取消條件與變更方法
可辦理入住的時間及延遲時的聯絡方法
交通、停車場及接送的確認窗口
與貓咪相處的方法及設施特有的重要事項
旅宿的正式聯絡方式

不要在電子郵件寫入預訂者的密碼或信用卡資訊。除了確認郵件送達，也應能從管理畫面確認預訂狀態。

必要功能6：一併設計線上付款與取消流程

線上付款可能有助於應對未通知而未入住、縮短現場結帳時間及提升海外旅客的便利性。但除了預訂系統月費，還有付款手續費，也需處理退款與取消費。

導入前應決定以下事項。

預訂時採全額、訂金、部分付款或現場付款
取消費從哪天開始及費率
縮短住宿或減少人數時的價差處理
由誰在哪個畫面操作退款
付款手續費與退款時的手續費
入帳週期與預訂資訊比對方法
付款失敗時何時釋出房量
能否安全寄送電話預訂的付款連結

不要透過電話、電子郵件、筆記或與AI的對話收取信用卡號。原則上，應使用不讓旅宿保存信用卡資訊的付款畫面。

未滿10間客房時，可稍後導入的功能

以下不是指這些功能沒有必要。如果目前問題是房量與轉錄作業，首次導入時可能不必同時開始。

進階需求預測與自動調價
大型飯店的複雜會計整合
跨多個設施的總部管理
大量員工階層與審核流程
客房內裝置或進階自助入住
大量顧客分群與促銷自動化
連接不打算使用的OTA
過度細分的客製報表

應確認日後需要時能否追加。一開始全部設定，容易造成無人理解整體系統的狀態。

小型旅宿實用的每日營運

早上

確認當天抵達、離開與連住
確認未分配客房及清潔狀態
向必要負責人分享餐飲份數、過敏、接送與特別事項
確認未付款與現場付款

每次收到預訂時

確認預訂日期與房型正確
確認OTA與官方網站的剩餘客房已更新
查看重複、未分配及付款失敗警告
電話與電子郵件預訂當場登錄到台帳

傍晚

確認預定抵達與尚未抵達的住客
分享延遲通知與可辦理入住的時間
確認隔天早餐份數、離開與清潔

營業結束前

比對新預訂、變更、取消通知與台帳
確認未處理的暫時預訂
以故障時也能查看的安全方式，準備隔天名單

不要每天列印所有資料後放任個人資訊無人管理，而應只管理當天必要資訊，並決定使用結束後的銷毀方式。

系統停止時的替代台帳

雲端服務、網路或裝置都有停止的可能。請準備最基本的替代步驟，避免故障時無法確認當天住客。

故障時確認的項目
- 當天與隔天抵達、離開
- 房間分配
- 人數與餐飲份數
- 需傳達給旅宿的安全與過敏資訊
- 付款狀態
- 緊急聯絡方式
- 最後同步與匯出時間

即使保存到紙本或離線檔案，也屬於個人資訊。請決定可閱覽人員、保存地點、更新頻率，以及回收與刪除方式。

恢復後，依時間順序比對故障期間受理的電話預訂、OTA預訂及取消。不要批次覆寫一方的資訊，應逐筆確認。

讓第二個人也能操作

家庭經營常見的風險，是只有導入系統的本人會使用。

準備個人帳號
分開日常操作與管理設定的權限
不要以紙本共用密碼，使用適當管理方法
準備兩步驟驗證的恢復方法
分別將電話預訂、變更、取消、退款步驟整理為一張紙
每月一次，由另一人操作
定期檢查製作公司或離職人員的權限

避免「只有緊急時才借管理員帳號」的方式，否則無法追蹤誰改了什麼。

4週導入範例

第1週：整理作業

計算預訂管道與件數
記錄轉錄位置與錯誤
區分必要功能與可稍後導入的功能
決定客房、房型、房價與方案的權威原始記錄

第2週：建立測試環境

使用虛構客房與房價設定
測試一晚、連住、兒童、餐飲與電話預訂
測試變更、取消、付款與退款
由旅宿主人與另一人操作

第3週：準備正式資料

由兩人比對未來預訂後移轉
對應OTA與房型
校對確認電子郵件與取消條件
確認個人資訊、權限、備份及故障聯絡窗口

第4週：逐一開放銷售管道

先從官方預訂或單一銷售管道試行
確認實際預訂通知與剩餘客房
將輸入電話預訂養成習慣
沒有問題再連接下一個OTA

不要在旺季前一次全部切換。請決定舊台帳與新系統並行的期間，也註明哪個是權威原始記錄。無期限的雙重管理反而容易增加不一致。

選擇系統時的最低檢查清單

能正確處理跨住宿日期的連住房量
能設定房型與實際客房的差異
能快速登錄電話預訂
能整合目前使用OTA的房量、變更與取消
預訂成立時間與暫時預訂的處理明確
能設定餐飲、兒童、連住、休館與包館
能處理付款失敗、取消費與退款
有個人帳號與操作紀錄
能匯出預訂、顧客與營收資料
了解日語支援的時間與範圍
有通訊故障時的確認、受理與恢復步驟
至少兩人能完成日常操作
已確認包含初期費用、月費、付款、連接與支援的總額

請AI協助營運設計的提示詞

請整理未滿10間客房旅宿的預訂作業。

請先提問:
- 客房數、房型及每間實際客房的差異
- 電話、電子郵件、官方網站與各OTA的每月預訂件數
- 一晚、連住、餐飲、兒童與包館的處理
- 目前台帳與轉錄目的地
- 在預訂、變更、取消、退款方面遇到的問題
- 操作人員及休假時的替代負責人

之後，請分成以下部分整理。
1. 必要功能
2. 可稍後導入的功能
3. 每日營運
4. 故障時的替代步驟
5. 4週導入計畫
6. 向供應商確認的問題

不要一律推薦特定產品，請以能減少目前作業多少次為判斷標準。
不要處理真實住客資訊、密碼或信用卡資訊。