醫美預約系統客製最容易低估的，不是日曆畫面，而是「完成一次服務需要哪些資源」。同一位醫師不能同時出現在兩個據點，特定療程可能還要綁診間、儀器與助理；若系統只檢查醫師有沒有空，顧客即使成功送出預約，也可能到店後才發現設備或空間已被占用。
需求訪談應先把預約拆成服務、地點、人員、空間、設備與時間規則，再決定顧客看到哪些選項。本文討論的是系統規格與驗收方式，不判斷療程安排或醫療專業流程；實際可預約項目、執行資格與紀錄內容，仍須由業者的專業與管理人員確認。
先定義可預約單位，再產生時段
不要先建立一張全院共用的時段表，再用人工備註誰可以接單。每個服務應明確列出可執行的人員、可用據點、所需空間或設備、服務時間、前後緩衝，以及是否允許同類資源替代。例如 A 儀器可由兩間診間共用，系統就必須在產生時段時同時檢查儀器與診間，而不是等預約成立後才通知櫃檯協調。
Google Calendar 的預約時段說明指出，預約頁會依設定的可用時間開放預約，且行事曆已有其他事件時會阻擋衝突時段。這提供了一個基本原則：對外顯示的可預約時間應由當下可用性計算，而不是一份固定時刻表。不過醫美現場往往同時受多項資源限制，因此客製系統不能只問「醫師行事曆是否有空」，還要把所有必要資源納入同一次確認。
驗收資料至少要包含一筆正常預約、一筆醫師有空但儀器被占用，以及一筆跨分店移動時間不足的情境。三者都用相同服務送出，檢查系統是否只顯示真正可完成的時段，並在後台說明阻擋原因，避免櫃檯只能看到模糊的「不可預約」。
暫留、成立與取消要是不同狀態
顧客進入表單並不等於預約已成立。若系統會在填資料或付款期間暫留時段，就要定義暫留多久、逾時如何釋放、重複送出如何辨識，以及付款成功但預約寫入失敗時由誰處理。否則兩位顧客可能同時看見最後一個名額，或未完成的流程長期占住時段。
建議把狀態至少拆成「可用、暫留、待確認、已成立、已取消、未到」等業務需要的節點，並保存每次狀態變更的時間、操作者與原因。取消不是直接刪除：它可能要釋放醫師、診間與設備，撤銷尚未發送的提醒，再決定是否通知候補者。驗收時可在兩個瀏覽器同時選同一時段，讓其中一邊逾時、另一邊完成，確認名額只會成立一次。
行事曆是同步對象，不一定是預約主檔
若院所把預約同步到外部行事曆，要先決定哪個系統是權威來源，以及雙方資料如何對照。Google Calendar API 的 Events 文件列出事件識別碼、開始與結束時間、狀態、最後更新時間與可見性等欄位，也說明 opaque 事件會阻擋時間、transparent 事件則不會。規格因此不能只寫「串接 Google Calendar」，而要說明哪種內部狀態建立事件、哪種事件阻擋時段、取消如何同步，以及同一事件更新時如何避免新增重複副本。
外部行事曆也不適合承擔全部預約資料。事件標題可使用內部編號或必要的工作提示，把聯絡資料、需求細節與內部備註留在具權限控制的系統中；同步時另行決定事件可見性及誰能讀取。驗收時除了比對時間，也要以不同權限帳號查看事件，確認不會因共用行事曆而讓不相關人員看到不必要內容。
用蘊禾堂案例建立跨分院測試
站內展示作品「蘊禾堂中醫診所」（yunhetang-tcm）包含五間分院、四位醫師、診療項目與線上預約，顧客可依序指定分院、醫師與時段。它不是實際院所營運成果，但可用來具體演練多據點預約的資料關係。
測試時可設定某位醫師上午在甲分院、下午在乙分院，並讓一項服務只在甲分院提供。先確認選乙分院後不會出現該服務，再確認醫師跨院移動期間不開放時段；接著取消上午最後一筆預約，檢查釋放的是正確分院、醫師與資源。若修改醫師班表，既有預約不應被默默覆蓋，而要進入可追蹤的衝突處理清單。
醫美預約系統的驗收重點，不是月曆能否點選，而是每個可見時段都有可解釋的資源依據。當暫留、成立、取消與外部同步都有狀態和識別碼，櫃檯才能處理例外，顧客也不會在看似成功的流程後才收到人工改期通知。
