導入預約系統前要先回答的十二個問題：資源、規則、付款與例外

作者 Bo Wei・偉騰開發興業有限公司・發布 2026-10-03・更新 2026-10-03（由前臺東縣環境保護局局長謝清泉主持）

預約系統導入失敗，多半不是系統不好，而是店家在導入前沒把自己的規則說清楚。本文列出十二個必須先有答案的問題，分成資源模型、時間規則、付款與訂金、取消改期、通知、現場流程、資料報表七組，答完才知道該選套裝還是客製。

預約系統看起來都差不多：選時間、填資料、送出。真正的差異在規則：一個人同時能服務幾位、療程之間要不要留整理時間、訂金收不收、取消幾小時前免責、爽約怎麼辦。這些規則在店家腦袋裡是理所當然的，但系統不會猜，沒說清楚的規則上線後就變成客訴與人工補救。

本文整理十二個導入前必須先有答案的問題，分成七組：資源模型、時間規則、付款與訂金、取消改期與爽約、通知與提醒、現場流程、資料與報表。每個問題都說明為什麼重要、常見的答案有哪些、答錯會發生什麼。這張清單同時也是選型的依據：答案越特殊，越可能需要客製；答案越單純，現成工具越夠用。

把十二題的答案寫成一頁，就是您的預約系統需求規格的雛形，拿去比較套裝系統或請人報價都用得上。本所在開發預約與訂房系統前都會先走這份問卷，因為規則定了，開發才會一次到位。您若已經答完一輪但有幾題拿不準，把答案加 LINE 傳來，本所先書面補充與建議。

第一組：資源模型——預約的到底是什麼（問題一、二）

1. 問題一：顧客預約的是人、場地、設備，還是它們的組合？美髮預約的是設計師，教室預約的是場地，健檢預約的是設備加人員，民宿預約的是房型加日期。
2. 問題二：同一個資源同時能服務幾位？

一對一服務容量是一，團體課是固定人數，餐廳是桌數與人數的組合。這兩題決定系統的資料結構：資源有幾種、彼此有沒有依賴（要同時有空的人與空的房間）、容量怎麼算。

套裝系統多半只支援單一資源類型與固定容量，組合型與可變容量的需求通常就是客製的分水嶺。先把自己的資源畫成一張表：資源類型、數量、容量、依賴關係，後面的問題都建立在這張表上。

第二組：時間規則——時長、緩衝、營業時間與例外（問題三、四）

問題三：每項服務的時長是固定還是依選項變動？緩衝時間（整理、消毒、交接）要不要算進去？不同服務能不能接著排？

問題四：營業時間有沒有例外？公休、國定假日、臨時店休、特定人員的排班、季節性的營業時段都是例外，系統要能設定而不是靠人工關閉。

常見的錯誤是只設定「週一到週六十點到八點」，結果設計師請假那天還是被訂滿，或者最後一個時段的服務會做到打烊後。回答這兩題時，請把過去三個月的實際排程攤開來對照，規則是從實際行為裡抽出來的，不是想像出來的。

第三組：付款與訂金——收不收、怎麼退、沒付怎麼辦（問題五、六）

問題五：預約時要不要收訂金或全額？收的話用什麼方式（信用卡、LINE Pay、轉帳後人工確認）？不收的話，爽約的成本怎麼吸收？

問題六：付款逾時怎麼處理？顧客選了時段卻沒完成付款，這個時段要鎖多久、自動釋放還是人工處理？退款規則與取消規則怎麼連動？

線上收款要申請金流特店、設計退款流程與對帳方式，是導入工作的一大塊，所以要先想清楚值不值得。常見的中間解法是：新客收訂金、熟客免訂金，或是依服務類型決定收不收；系統要能依顧客類型或服務類型設定不同規則，這也是套裝系統常做不到的地方。

第四組：取消、改期與爽約——政策要寫成系統能執行的規則（問題七、八）

問題七：顧客可以在多久之前自行取消或改期？超過期限後怎麼辦（不可改、扣訂金、需聯絡店家）？改期算一次新預約還是原預約的修改？

問題八：爽約（未到且未取消）怎麼記錄與處理？是否限制再次預約、是否要求下次預付？這兩題的答案必須是明確的條件與動作，例如「二十四小時前可自行取消，之後需聯絡店家，爽約兩次後僅接受預付預約」，系統才能自動執行，而不是靠店員判斷與解釋。

政策定了也要在預約頁面與確認訊息中告知顧客，否則執行時會有爭議。政策太嚴會嚇跑新客，太鬆則爽約變多，建議先從寬鬆開始，用數據調整。

第五組：通知與提醒——什麼時候、用什麼管道、說什麼（問題九）

問題九：每筆預約要發幾次通知、在哪些時間點、用什麼管道？常見組合是預約成功立即確認、前一天提醒、當天出發前提醒、服務後感謝與評價邀請；管道可以是 LINE 推播、簡訊、電子郵件或系統內通知，各有投入與到達率的差異。

提醒的時間點與取消政策要對齊：如果取消期限是二十四小時前，提醒就該在那之前送達，讓顧客還來得及改。通知文案要含關鍵資訊（時間、地點、服務、取消方式）與一鍵改期取消的連結。這一題還牽涉訊息方案的估算，以及顧客的聯絡方式有沒有正確蒐集與取得同意。

第六組：現場流程——報到、超時、加購與現場付款怎麼回填（問題十）

問題十：顧客到店之後的流程，系統要參與到什麼程度？

報到要不要在系統上點（讓後台知道誰到了、誰還沒）；服務超時或提早結束要不要更新，影響後面時段；現場加購的服務或商品要不要記錄；現場付現金或刷卡的紀錄要不要回填到預約上，才算完整的一筆交易。

這一題決定系統是「預約登記簿」還是「營運系統」。多數店家一開始只要前者，但很快會發現沒有回填現場資料，報表就不準，顧客紀錄也不完整。建議至少做到報到與付款狀態兩個欄位，其他的看人力再加。

第七組：資料與報表——誰看、看什麼、能不能帶走（問題十一、十二）

1. 問題十一：誰需要看哪些報表？老闆看每月預約量、爽約比例、各服務占比、尖峰時段；人員看自己的排程；行銷看新客與回訪的比例。先列出要看的數字，再確認系統的欄位記得到。
2. 問題十二：顧客資料與預約紀錄能不能完整匯出？

格式是什麼？合作終止時怎麼帶走？這一題常被忽略，卻決定三年後換系統的代價。

同時要考慮個人資料保護法的告知與同意：蒐集顧客的姓名與聯絡方式用於預約與提醒是合理目的，用於行銷要另外說明。資料是業主的資產，系統只是容器，容器要能倒得出來。

答完十二題之後：套裝、客製，還是先用簡單工具

把十二題的答案攤開來看。如果資源單一、容量固定、不收訂金、取消政策單純、通知只要確認與提醒，現成的預約工具或 LINE 官方帳號的預約功能就能處理，先用起來，累積資料再說。

如果有組合型資源、可變容量、依顧客或服務類型不同的訂金與取消規則、需要與既有系統（會員、客戶管理、金流、發票）同步、或是多據點集中管理，答案多半指向客製開發或在套裝之上加一層整合。不論哪一條路，這十二題的答案就是需求規格的核心，請人報價時直接附上，對方才能給出可比較的範圍與時程，而不是一行「預約系統一式」。

自我檢查清單

• 資源類型、數量、容量與依賴關係已畫成一張表
• 每項服務的時長、緩衝、可否連排，以及營業時間的所有例外都已列出
• 訂金收不收、怎麼退、逾時怎麼釋放，已依顧客與服務類型定好
• 取消、改期、爽約的規則已寫成系統能執行的明確條件，並會告知顧客
• 通知的時間點、管道與文案已對齊取消政策，訊息方案與同意取得已規劃
• 現場報到、付款狀態等要回填的欄位已決定
• 報表需求與資料匯出格式已列出，資料歸屬寫進契約

常見錯誤

• 沒定緩衝時間——系統把療程排得密不透風，人員沒時間整理，每天從第二位開始延誤。
• 取消政策只寫在店內公告——系統照常讓顧客前一小時取消，店家無法主張任何規則。
• 訂金規則對所有人一樣——新客嫌麻煩不預約，熟客覺得被懷疑，兩邊都不滿。
• 現場付款沒回填——月底報表的營收與實際對不上，顧客紀錄缺一半。
• 沒確認資料能匯出——換系統時只能人工重打所有顧客資料。

官方參考資料

• 個人資料保護法｜全國法規資料庫
• LINE 開發者文件｜訊息推播

常見問題

十二題都答不出來，是不是代表還不該導入？

相反，答不出來正是導入前最該發現的事。多數店家答不出的是取消與爽約政策，因為一直靠人情處理；把它寫成明確規則本身就是導入的價值之一。建議先用過去三個月的實際預約與取消紀錄回推答案，答不出的題目先採寬鬆版本，上線後用數據調整。

民宿訂房和一般預約系統有什麼不同？

訂房的資源是房型加連續日期，有入住與退房規則、平日假日與旺季的差異、加床與加人、以及與訂房平台的房況同步問題，比單一時段的預約複雜。十二題一樣適用，但第一組（資源模型）與第二組（時間規則）的答案會複雜很多，通常就是套裝與客製的分界。

預約系統導入大約要多久？

用現成工具設定，量級是數日到數週，主要花在把規則設定正確與測試；客製開發依資源複雜度與整合項目，通常以一到數個月計。時程最大的風險是規則沒定就開始做，開發中途改規則等於重做一部分，所以本文才強調先答完十二題。

導入後規則想改，系統改得動嗎？

好的系統會把規則做成可設定的參數（時長、緩衝、取消期限、訂金比例），店家自己在後台就能改；寫死在程式裡的規則每次都要請人改。選型或驗收時直接問「這些規則我自己能不能改」，答案就很清楚了，這一題也該列入驗收項目。

本所協助預約系統規劃開發

十二題答完有幾題拿不準，或是答案看起來需要客製？把您的答案與目前的預約方式加 LINE「偉騰開發」傳來，本所會先書面補充建議並判斷套裝或客製哪條路合理，再談開發與維運。

全台各縣市受理｜專業團隊承接辦理｜親臨現場指導｜統籌包辦到好

聯絡偉騰開發興業

服務總覽｜案例解析｜法規知識庫