醫美團隊說要做「LINE 預約系統」時，需求常被濃縮成一句：顧客在 LINE 選療程、醫師與時間，店家收到通知就完成。但實際上，聊天室訊息、可預約時段、正式預約、提醒通知與櫃檯修改是不同資料。若沒有先指定哪一份資料才是最終依據，同一個時段可能同時被官網、LINE 與電話占用，顧客也可能收到已過期的確認內容。

這類專案應先把 LINE 定位成入口與通知通道，而不是直接等同排班核心。預約主檔仍要保存據點、服務、服務人員、起訖時間、資源、顧客識別、狀態與異動原因；LINE 則負責把顧客帶入流程、接收特定互動，並傳送確認、改期或取消訊息。兩者透過明確事件連接，才能在聊天以外查回完整狀態。

先定義哪一刻才算預約成立

需求文件至少要區分「查看時段」、「暫時保留」、「等待人工確認」、「已確認」、「已取消」、「已到店」與「未到」等狀態。顧客點擊某個時間，不一定代表已完成預約；若療程還需要資格確認、醫師確認或其他人工程序，畫面與訊息都應如實顯示目前狀態，不能先傳出讓人誤以為已成立的文案。

時段也不能只是一個日期欄位。系統要知道它屬於哪個據點、哪位服務人員、占用哪個空間或設備，以及服務前後是否需要緩衝。電話進線由櫃檯新增預約時，應走同一套可用量檢查；否則網站顯示的空位與現場班表會逐漸分離。改期則應建立新的異動紀錄並釋放原資源，而不是直接覆蓋舊時間，這樣遇到爭議或通知錯誤才有資料可查。

「蘊禾堂中醫診所」（yunhetang-tcm）案例把五間分院、醫師班表與時段選擇放進同一條線上預約動線。套用到醫美情境時，值得借鏡的是先選據點、再依該據點與人員取得有效時段；不是宣稱所有診療流程都能完全自動化。需求方仍要逐項確認哪些服務可直接成立、哪些只能送出預約申請，以及誰負責最後確認。

LINE 身分與顧客資料要分開管理

LINE 使用者識別值不應直接取代顧客主檔。家庭成員可能共用聯絡方式，同一位顧客也可能更換帳號、封鎖官方帳號或改用電話。較穩定的做法是建立身分對照：顧客主檔保留組織真正需要的聯絡資料，LINE 識別值只記錄它與哪位顧客、哪次綁定流程相關，並保留解除與重新驗證的方式。

資料收集也應採最小範圍。聊天中不宜要求顧客反覆傳送不必要的敏感內容；若某項資訊需要由正式表單收集，訊息只提供安全連結與進度提示。後台權限要分開：櫃檯可以處理預約，不代表所有行銷或門市帳號都需要看到完整顧客紀錄。本文提供的是系統分析方法，實際蒐集欄位、告知方式、保存與存取規則仍應由組織依服務流程及適用要求確認。

Webhook 要先驗證，再去重與排隊處理

LINE Developers 的接收訊息文件說明，使用者加入官方帳號或傳送訊息時，LINE 平台會向已登記的 Webhook URL 傳送 HTTP POST 事件；文件也建議非同步處理事件。這代表接收端不宜在一次請求中同步完成排班查詢、建立預約、傳送多則訊息與寫入報表。較安全的流程是先驗證請求、快速接收並記錄事件，再由背景工作依序執行業務動作。

同一份官方文件也指出，Webhook 可能因不同原因被送達不只一次，重送後的事件順序也可能與發生順序不同，可利用 webhookEventId 偵測重複。預約串接因此必須保存事件識別值：同一事件再次到達時回傳既有處理結果，不能再建立第二筆預約或重複發出通知。若取消事件比確認事件晚處理，系統也要依事件時間與目前狀態判斷，而不是以「最後收到」直接覆蓋。

LINE Developers 的 Webhook 簽章驗證文件要求在處理事件前驗證 x-line-signature，並提醒應以收到的原始 request body 驗證，不能先解析或改寫內容。驗收時要包含正確簽章、缺少簽章、錯誤簽章、相同事件重送與順序顛倒等情境；失敗事件應進入可重試或人工檢查的佇列，而不是靜默消失。

通知紀錄不能只存「已傳送」

預約提醒應有自己的紀錄，至少包含預約版本、訊息用途、預定傳送時間、實際送出時間、通道回應、失敗原因與重試次數。顧客改期後，舊提醒必須被取消或失效；若工作排程已取出舊任務，送出前仍要再次核對預約版本。否則系統可能同時傳出原時段與新時段，讓櫃檯承擔解釋成本。

通知文案也要對應狀態。「已收到申請」與「預約已確認」不能共用同一句話。連結應導向特定預約的查詢或操作頁，並在開啟後重新驗證使用者權限，不應只靠網址中的流水號判斷身分。當訊息無法送達時，後台要顯示待處理工作，並依組織規則切換電話、簡訊或人工聯絡，而不是假設每位顧客都持續接收 LINE。

「澄光美研所」（clare-beauty）案例將八項服務頁、四處據點與站內預約入口連接起來。這提醒醫美團隊，LINE 訊息不必承擔所有服務說明；訊息可把顧客帶到內容完整、版本可維護的服務與據點頁，再進入對應的預約流程。當療程說明、注意事項或據點資訊更新時，也比較容易確保顧客看到同一版本。

用改期與重送走完端到端驗收

驗收不要只測「成功預約一次」。可以先建立兩個據點、兩位服務人員與不同緩衝規則，讓顧客從 LINE 進入預約，送出後由櫃檯確認；接著模擬相同 Webhook 重送、顧客改期、舊提醒已排入佇列、LINE 通知失敗與人工電話接手。每一步都應能從預約主檔追到狀態異動、來源事件、通知版本與操作者。

交付清單可包含預約狀態表、資源衝突規則、LINE 與顧客身分對照、Webhook 簽章與去重方式、通知排程、失敗重試、人工工作台、權限矩陣及資料匯出。真正可靠的 LINE 預約系統，不是能在聊天室裡選到日期，而是 LINE、官網與櫃檯同時操作時，仍只有一份可追查的預約真相。