美容、美體、按摩與診所評估預約網站製作時，常把需求寫成「顧客能選服務、日期與時間」。這句話只能描述畫面，沒有說明一個時段何時可售、同時能接幾人、跨店支援如何計算，也沒有定義取消後名額怎麼釋出。結果是網站雖然有月曆，櫃台仍得用電話、紙本或群組訊息確認。
真正可開發、可報價的規格，應把預約視為一組會改變狀態的資源配置。人員、房間、設備與服務時長都要一起判斷，通知則是狀態改變後的結果，而不是獨立的行銷功能。
先定義「誰有空」，再顯示空白時段
同一位美容師可能在不同分店輪班，同一間房也可能提供多種服務；若只看員工行事曆，仍可能發生人員有空但房間或設備已被占用。需求書可以將可預約條件拆成四層：門市營業時間、人員班表、服務所需資源，以及前後緩衝時間。四層都成立，前台才顯示時段。
服務時長也不宜只有一個數字。顧客看到的療程時間、店內整理時間與跨店移動時間可能不同。例如一項服務對外顯示六十分鐘，但完成後仍需整理空間；系統應占用完整資源區間，而不是只占用顧客在場的時間。跨店支援則要禁止同一人於重疊區間被兩處預約。
Google Calendar 的 Create events 文件顯示，事件資料會分別記錄開始、結束、時區、參與者、重複規則與提醒。這可作為串接外部日曆時的資料邊界參考，但外部行事曆事件不等於完整預約：容量、服務資源、付款與取消狀態仍應由預約系統保存。若雙向同步，還要定義哪一端可修改、重複事件如何辨識，以及同步失敗由誰處理。
多人服務與多分店要用容量規則
「同時可預約」至少有三種模式：一對一服務、同時多席的團體服務，以及需要多位工作人員共同完成的服務。需求書應為每項服務列出所需人員數、可替代角色、空間或設備數量、單時段上限與最低開課人數。只寫「剩餘名額」會讓工程師無法判斷名額究竟由哪種資源決定。
多分店預約系統還要處理服務與店點的對應。不是每個項目都在每間店提供，也不是每位工作人員都能執行所有服務。前台可以先選服務再篩出店點，也可以先選店點再篩服務，但兩條路徑最後必須落在同一套可用性規則，避免不同入口顯示矛盾時段。
以「澄光美研所」為例，案例中有八項服務與四處空間據點，服務介紹頁會接到站內預約。這類架構的規格重點不是多做四張月曆，而是維持「服務、據點、可執行人員」的關聯；內容頁的預約入口也應自動帶入剛才閱讀的服務，減少顧客重新選擇。
「蘊禾堂中醫診所」則有五間分院、四位醫師與各院所班表，預約可指定分院、醫師與時段。這個案例提醒團隊，醫師排班預約系統要把院所班表與個人班表視為共同限制，並清楚呈現停診、代診或不可預約，而不是讓顧客送出後再等人工確認。實際醫療預約仍應依院所流程與適用規範設計。
候補、改期與取消都要有狀態
預約至少可分為待確認、已確認、已取消、已完成與未到店；若有付款，再加入待付款、付款失敗與退款處理中等狀態。每次狀態變更都應保存時間、操作者與原因。這樣客服才能回答「誰在何時取消」，也能避免同一名額在付款逾時與人工確認之間被重複釋出。
候補不能只收一張表單。應先決定空位出現後是依序通知、保留一段時間，還是直接開放所有候補者搶訂；逾時後是否通知下一位，也要有明確規則。改期則建議建立新時段占用並保留原預約關聯，避免直接覆寫後失去查核脈絡。
LINE 提醒要能追蹤是否送出
LINE Developers 的 Send messages 文件區分回覆訊息與主動推播等方式，並說明推播可向指定使用者發送。預約提醒若採主動訊息，規格應包含帳號連結方式、發送時機、訊息內容、失敗重試與紀錄；顧客封鎖帳號或無法接收時，系統也不能把「已呼叫 API」直接當成對方已讀。
提醒內容應只放完成行程所需資訊，例如店點、時間、服務與取消入口，並避免在鎖定畫面暴露不必要的敏感內容。營運端則要能查到排程時間、實際發送結果與重試狀態。若同時使用電子郵件或簡訊，還要定義優先順序，避免改期後舊提醒仍被送出。
用衝突情境驗收預約網站
驗收不要只測「成功建立一筆預約」。至少應測試同一人員跨店重疊、同一房間容量已滿、服務前後緩衝、付款逾時、候補遞補、顧客改期、店家取消，以及 LINE 發送失敗。每個情境都要核對前台顯示、後台狀態、資源占用與通知紀錄是否一致。
預約網站的價值，不在月曆看起來多漂亮，而在尖峰時段仍能做出一致判斷。先把容量、狀態與通知寫成規則，團隊才有辦法比較現成工具與客製開發，也才能把「不用再人工確認」變成真正可驗收的交付成果。
