訂房訂位

庫存設定是這類系統的核心

訂房訂位系統與一般購物網站最大的差別，在於庫存是「依日期」而變動的——今天剩三間，明天剩一間，下週六早就滿了。

所以庫存設定不能只有一個數字，需要一套規則。

三層設定邏輯

常見的做法是分三層，由粗到細：

優先順序

單日設定 > 依星期設定 > 每日預設庫存

也就是說：特定日期有設定就用它，沒有的話看星期規則，還是沒有就用預設值。

這個順序不應該被更動——它的邏輯是「越具體的設定優先」，反過來會造成混亂。

調整庫存時的保護機制

這是實務上很重要的一點：不能把庫存調得比已經被預約的數量還低。

例如某天已經有 5 筆預約，就不能把當天的庫存改成 3——那會造成超賣。系統應該擋下這個操作，或至少提出警告。

同樣地，套用預設值或星期規則時，已經有預約的日期應該跳過或提示，不能無條件覆蓋。

庫存扣除的時機

這決定了系統會不會超賣，也決定了庫存會不會被無效佔用：

建議第三種。 送出時先扣，並設定一個保留時限（例如 30 分鐘或到當日結束），逾期未完成付款就自動釋放。

非即時付款的處理見線上付款方式有哪些。

起訖日期的庫存計算

旅宿類型的預約會跨越多天，庫存要逐日檢查與扣除。

例如訂 8 月 10 日至 12 日，系統要確認 10 日與 11 日兩晚都有空房（退房當日不佔用），任何一天沒有就不能成立。

常見的規劃問題

• 最少入住天數——旺季是否限制至少兩晚
• 最多可預約多久之後——例如只開放三個月內
• 不可入住或不可退房的日期

這些規則會增加開發複雜度，需求要在規劃階段就提出。

超賣的防範

超賣是這類系統最嚴重的問題——賣掉了不存在的房間或座位，最後要向客戶道歉並協調處理。

技術面

• 同時下單的處理——兩人同時搶最後一間，系統必須確保只有一個成功
• 調整庫存時檢查已預約數
• 跨項目共用庫存要正確關聯——例如「雙人房 1 人住」與「雙人房 2 人住」是同一批房間

營運面

• 保留緩衝——實際有 10 間，網路只開放 8 間，留給電話訂房與突發狀況
• 雙軌並行時要有同步機制——見訂房訂位系統的常見問題

可用性的呈現

從客戶端來看，庫存資訊怎麼顯示會影響轉換：

• 行事曆檢視——一眼看出哪些日期還有空，體驗最好
• 顯示剩餘數量——「僅剩 2 間」有促進決定的效果，但庫存少時也可能造成壓力
• 已滿的日期要明確標示，不要讓客戶選了才被拒絕
• 提供替代建議——該日已滿時，提示鄰近可訂的日期

最後一項很實用，能挽回一部分原本會流失的客戶。

後台該具備的功能

• 依日期查看各項目的庫存與已預約數
• 快速調整單日庫存
• 批次套用星期規則或預設值
• 手動建立預約——處理電話或現場的訂位
• 封鎖特定日期
• 匯出報表

其中手動建立預約是必備的——沒有它，電話訂位就無法納入同一套庫存，一定會超賣。

規則要先訂，不要邊做邊想

預約規則看似瑣碎，但它同時牽涉客戶體驗、營運彈性與開發成本。規則沒定清楚就開發，一定會反覆修改。

以下是必須事先決定的幾組規則。

一、可預約的時間範圍

• 最早幾天前可預約——例如至少三天前，讓廚房或現場有準備時間
• 最晚可預約到什麼時候——當天可以訂嗎？前一小時呢？
• 最遠可預約多久之後——例如開放三個月內

第一項的實務考量：如果開放當天預約，就必須有人隨時看訂單，否則客戶來了才發現沒人知道。這是營運能力的問題，不是系統的問題。

二、修改規則

• 幾天前可以修改
• 可以改哪些項目——日期、人數、房型是否都能改
• 修改時要重新檢查庫存——改到已滿的日期就不能成立
• 已付款的訂單能否修改

已付款訂單的處理

常見做法是已完成付款的訂單不開放線上修改，需聯繫店家人工處理。原因是修改可能牽涉價差、退款、金流端的異動，自動化的風險較高。

這是合理的設計，但要在頁面上清楚說明，避免客戶以為可以隨意更改。

三、取消規則

• 幾天前可以取消
• 取消後庫存要立即釋放
• 是否收取取消費用——依取消時間分級收費是常見做法
• 已付款的退款方式與時間

階梯式的取消政策

旅宿業常見的做法是依取消時間決定退款比例——越接近入住日退越少。這種規則要注意：

• 計算基準是哪一天（下訂日、入住日）
• 時間如何認定（以送出取消的時間為準）
• 退款的手續費由誰負擔——金流的手續費通常不退還

金流手續費的說明見金流的費用怎麼算。

四、通知機制

每一個動作都應該有對應的通知：

最後一列的提醒通知最有價值——它能明顯降低沒有出現的比例，成本卻很低。

通知的兩個實務要點

• 通知信要能寄達——網站主機寄出的信必須納入寄件驗證設定，否則會進垃圾桶。這是最常見的問題，見通知信收不到怎麼辦
• 店家端的通知要指定到職務型信箱，不要用個人信箱，避免人員異動後漏收

五、沒有出現的處理

訂了位卻沒出現，是這類營運的實際損失。系統面可以做的：

• 事前提醒通知
• 要求訂金——最有效的方式
• 記錄多次未出現的客戶
• 設定確認機制——例如前一天要回覆確認

但規則要寫在預約須知中並取得同意，否則後續處理容易產生爭議。

六、要在網站上清楚說明的事

建議做成獨立的「預約須知」頁面，並在預約流程中呈現：

• 可預約的時間範圍
• 修改與取消的期限與費用
• 付款方式與時機
• 退款政策與作業時間
• 逾時未到的處理
• 特殊需求的聯絡方式

這些不只是體驗問題——如果有串接金流，申請審核時通常也會檢查這些頁面是否完備。

規則越簡單越好

最後一個實務建議：複雜的規則不只開發成本高，客戶也記不住。

「三天前可免費取消，之後恕不退費」比一套五階段的退費比例表更容易溝通，爭議也更少。

先從簡單的規則開始，實際運作後再依需要調整。

先決定收款的時機

訂房訂位的收款方式，直接影響到場率、現金流與客訴量。常見有三種安排：

怎麼選

• 單價低、客人多、取消影響小（一般餐廳）——現場付款即可
• 單價高、空位損失大（旅宿、包廂、活動）——建議至少收訂金
• 名額有限、有成本投入（課程、限量體驗）——可考慮全額預付

現場付款是最省事的起點。 系統不需要串接金流就能上線，等營運穩定、確認未到場率確實造成損失，再導入線上付款。

要串接哪些付款方式

訂房訂位常見的組合：

• 信用卡——即時完成，最適合訂金與預付
• ATM 虛擬帳號——每筆一組專屬帳號，可自動對帳。適合金額較高的訂房
• 超商代碼——年輕客群或小額訂金
• 行動支付——手機下單為主的客群

各方式的特性與費率差異見線上付款方式有哪些。

非即時付款要處理庫存保留

ATM 與超商不是即時入帳的。這代表：客戶取得付款代碼但還沒繳費時，那個位子要不要先保留？

建議做法是先保留並設定期限——例如當日結束前未付款就自動取消並釋放庫存。期限要在頁面上明確告知。

價格規則的複雜度

這是訂房訂位報價的主要變因。同一個項目可能因為以下因素而有不同價格：

• 人數——雙人房 1 人住與 2 人住
• 日期——平日、假日、連續假期、旺季
• 停留天數——連住優惠
• 時段——午間與晚間不同價
• 加購項目——加床、早餐、設備租借
• 身分——會員價、團體價

兩種實作方式

方式一：各自建立預約項目。 把「雙人房 1 人住」與「雙人房 2 人住」列為兩個項目，各自標價。

設定單純，但務必確認兩者共用同一組庫存——否則同一間房會被賣兩次。

方式二：單一項目加價格規則。 一個房型，依人數與日期自動計算。彈性高，但開發成本明顯較高。

建議依實際的規則數量決定。規則少就用方式一，規則多且會經常調整才值得投入方式二。

退款的處理

這是最容易產生爭議的環節，規則必須事先寫清楚：

• 退款比例——依取消時間分級
• 手續費由誰負擔——金流手續費通常不退還，這筆成本要有人吸收
• 退款方式——原路退回或匯款
• 作業時間——需明確告知客戶多久會收到
• 部分退款——例如減少人數時的差額處理

手續費的歸屬要特別注意。 若全額退還給客戶，手續費由店家吸收；若扣除後退還，要在條款中事先說明，否則容易被客訴。

發票與收據

有收款就會有開立憑證的需求：

• 何時開立——付款時或到場消費後
• 訂金與尾款如何開立
• 取消退款時的作廢或折讓處理
• 是否需要串接電子發票系統

電子發票串接的評估見API 串接是什麼。

需要會員才能預約嗎

不一定。兩種做法各有取捨：

建議的折衷：免註冊即可預約，但預約完成後提供「設定密碼以便日後查詢」的選項。這樣不擋住第一次的轉換，又能逐步累積會員。

會員系統的評估見網站需要做會員系統嗎。

費用怎麼估

訂房訂位系統通常依功能項目逐項計價：預約項目建立、庫存規則、自訂欄位、預約規則、各種付款方式串接，各自都是獨立的工作項目。

所以報價的準確度取決於需求的明確度。把規則寫成文件，是拿到準確報價的前提。

報價單的看法見網站架設費用怎麼算。

上線後才會遇到的真實問題

系統功能都做好了，但實際營運起來會遇到一批狀況。多數不是程式錯誤，而是系統與現場作業沒有對接好。

一、電話訂位與線上訂位打架

這是最常見、也最容易造成超賣的問題。客人打電話訂了位，但沒有登入後台建檔，線上系統仍顯示有空位，於是又被訂走一次。

處理方式

• 後台必須能手動建立預約——電話訂位當下就要建檔，這是最根本的做法
• 保留緩衝——實際有 10 間，線上只開放 8 間，留給電話與現場
• 統一入口——不論從哪個管道來，都由同一套系統管理庫存

第一項是必備功能。 沒有它，雙軌並行必然出錯。發包時要確認。

二、超賣

除了上述原因，還可能來自：

• 同時下單——兩人同時搶最後一間，系統沒有正確處理併發
• 共用庫存沒關聯——「雙人房 1 人住」與「雙人房 2 人住」被當成兩批庫存
• 用人數當庫存單位——1 人訂了雙人房，系統只扣 1 個人的量
• 調整庫存時調得比已預約數低

第三項是規劃階段的問題，見訂房訂位系統要規劃什麼。

真的超賣了怎麼辦

1. 盡早聯繫客戶，越晚通知傷害越大
2. 提供替代方案——其他日期、升等、鄰近合作店家
3. 提供補償——折扣、招待項目
4. 確實退款
5. 檢討成因並修正，不要只處理個案

三、客戶說訂了但查不到

可能的原因：

• 非即時付款尚未入帳——訂單存在但狀態是待付款
• 逾時未付款已被自動取消
• 客戶填錯 Email，收不到確認信而以為失敗
• 送出時發生錯誤但客戶不知道

後台要能用姓名、電話、Email 交叉查詢，包含已取消與待付款的訂單。只能查已成立的訂單，就無法回答客戶的疑問。

四、重複預約

客戶以為沒成功而重複送出。預防方式：

• 送出後按鈕立即鎖定，防止重複點擊
• 成功後導向明確的完成頁面
• 後台對同一聯絡方式、同一時段的重複預約提出提示

表單送出的處理見表單資料存哪裡。

五、假預約與惡意灌單

沒有任何驗證的系統，可能被大量灌入假預約，把庫存全部佔滿。

防範

• Email 或手機驗證——最基本的一道關卡
• 收取訂金——最有效的方式
• 限制同一來源的送出頻率
• 背景式的機器人判斷

驗證方式的取捨見會員註冊與登入該怎麼設計。

六、尖峰時段的搶訂

熱門時段開放預約的瞬間，可能湧入大量請求。要注意：

• 主機是否撐得住——平時流量不大的網站，尖峰可能當機
• 併發處理是否正確——同時搶最後一個名額時不能重複賣出
• 失敗時的訊息要清楚——讓客戶知道是已滿還是系統忙碌

如果有固定的開放時間（例如每月一號開放下個月），建議事先與廠商確認系統能承受的量。

七、現場作業的對接

系統做得再好，現場沒人看也沒用。建議確認：

• 當日預約清單怎麼取得——後台查看、列印，或寄送每日清單
• 手機能不能看——現場人員通常不會開電腦
• 到場後怎麼註記——標記已報到、未出現
• 臨時異動誰來改——現場人員是否有權限

「當日清單能不能用手機看」是很實際的問題，卻常常在驗收時被忽略。

八、報表與檢討

累積一段時間後，這些數字有助於調整營運：

• 各時段、各項目的預約率
• 取消率與未出現率
• 提前多久預約的分布
• 取消的時間點分布——用來檢討取消政策
• 來源管道——線上、電話、現場的比例

例如發現某個時段長期滿載、另一個時段長期空著，就可以調整價格或庫存配置。

上線後的例行檢查

1. 自行送出一筆測試預約，確認流程與通知正常
2. 核對後台筆數與實際到場數
3. 確認通知信沒有進垃圾郵件匣
4. 檢視取消與客訴的原因，找出流程問題
5. 確認未來日期的庫存設定正確

最後一項容易被忽略——如果只設定到今年底，明年一月客戶就訂不了。 建議定期往後展延。