美容工作室導入線上預約系統時，常把 LINE 提醒寫成一句需求：「到店前自動通知顧客。」真正容易出錯的卻不是第一次排程，而是顧客改期、店家取消、服務時間調整或發送端逾時之後，舊訊息是否仍會送出。若顧客先收到原時段提醒，稍後又收到新時段提醒，通知不但沒有降低人工確認，反而增加誤會。
因此，提醒功能應被視為預約狀態的衍生結果，而不是一個獨立鬧鐘。每一則待發訊息都必須知道自己屬於哪一筆預約、哪一個版本、為何需要發送，以及在發送前應再次確認什麼。以下不承諾提醒能消除未到店，而是把可控制的排程與紀錄整理成可驗收規格。
通知必須跟著預約版本，而不是只記一個時間
預約建立後，系統可以依規則產生待發通知，但通知資料至少要連回預約識別碼、預約版本、預定發送時間、訊息範本與接收管道。顧客改期時，不應直接覆寫原本時間後再多排一則；系統要先讓舊版本的待發通知失效，再為新版本建立通知。取消或店家停業時也要有同樣的撤銷動作。
發送工作真正開始前，還要重新讀取預約狀態。只有預約仍有效、版本仍相同、接收者仍符合通知條件時才送出；否則記錄為「已略過」，並保存略過原因。這個最後檢查可處理排程建立後才發生的改期，避免系統照著過期佇列盲目執行。
需求書可明確區分「待排程、等待發送、發送中、平台已接受、失敗、已略過」等通知狀態。它們不等同預約的待確認、已確認、已取消或已完成狀態，兩者應以關聯串起，而不是混用同一欄位。如此櫃台查詢一筆預約時，才能同時看見服務狀態與每次通知處理經過。
網路逾時不能直接重送一則新訊息
通知服務呼叫外部平台時，可能遇到連線中斷或逾時。最危險的處理方式是看不到成功回應就立刻建立一個全新的發送請求，因為第一次請求可能已被接受，顧客最後會收到重複提醒。
LINE Developers 的 Retry failed API requests 說明，同一請求可搭配 retry key 重試，以避免平台重複執行；文件也提醒，安全重試不代表訊息一定送達。把這個原則寫入預約系統時，每次通知工作應有穩定的發送識別，而不是每次重試都產生新身分。系統還要保存請求時間、回應狀態與平台回傳的追蹤資訊，讓維運人員能判斷是尚未送、已被接受，還是資料本身有錯。
驗收時可刻意讓第一次請求在回應前中斷，再執行重試，確認顧客端不會收到兩則相同提醒。另要測試不應重試的輸入錯誤，以及改期剛好發生在重試期間的競爭情境。若預約版本已改變，即使舊請求曾失敗，也不該繼續把舊時段送出去。
「平台接受」與「顧客看見」要分開描述
發送 API 回傳成功，只能證明平台接受了請求，不能直接寫成顧客已讀，更不能推論顧客一定到店。LINE Developers 的 Measure impressions 將 impression 定義為使用者進入聊天室並看見訊息，並列出特定裝置與顯示條件造成的統計限制。這表示後台應使用精確用語，例如「平台已接受」「有可用的瀏覽統計」或「顧客已在系統按下確認」，不要把它們合併成一個綠色勾勾。
如果店家需要確認到店意願，可以在提醒中提供確認、改期或取消入口，將使用者的明確操作另存成事件。沒有點擊不代表沒有看見，有 impression 也不代表同意到店；營運報表應分別呈現發送處理、訊息互動與最終到店結果，避免用一種資料替代另一種事實。
用展示案例建立完整的改期路徑
澄光美研所展示案例包含八項服務、四處空間據點，以及從服務介紹連到站內預約的動線。它是展示作品，不是已上線客戶，也沒有提供降低未到店的成果。可用來檢查的具體情境是：顧客從某項服務頁進入預約，選定據點與時段後收到確認；之後改到另一據點，舊提醒被撤銷，新提醒帶入正確地址與服務資料。
這條路徑還應加入店家取消、顧客連續改期、同一人有兩筆不同服務，以及通知送出前帳號已無法接收等例外。每次操作都核對前台顯示、預約版本、待發佇列、實際訊息與後台紀錄。案例的多據點結構能協助團隊測出最容易混淆的地址與時段，但不能被當成真實營運成效證明。
驗收交付物要能回答「為什麼這則有送」
完工時可要求一份通知狀態表、一份改期與取消測試紀錄，以及能依預約查詢通知歷程的後台畫面。紀錄內容應足以回答：通知由哪個預約版本產生、排定何時發送、發送前檢查結果、是否重試、平台如何回應，以及最後為何送出或略過。敏感憑證與完整訊息內容則不應無限制暴露給所有後台角色。
美容線上預約系統真正需要驗收的，不是「有收到一則 LINE」而已，而是任何改期、取消與網路例外發生後，系統仍只傳遞當下有效的資訊。先定義版本、撤銷、去重與證據，提醒功能才會成為可靠的服務流程，而不是另一個需要人工追查的訊息來源。
