運動賽事預約系統客製：用名額、付款與報到狀態避免重複報名

活動報名網站最容易被低估的地方，是把「送出表單」當成「報名完成」。對單次講座也許勉強可行，但運動賽事、球類活動或分梯次課程通常同時牽涉名額、資格、付款、候補、通知與現場報到。只要其中一個步驟延遲或重複，前台顯示的剩餘名額就可能和後台不同，工作人員最後只能用試算表人工補洞。

因此，預約系統客製的第一份規格不應是頁面清單，而應是「一筆報名會經過哪些狀態」。每個狀態要有進入條件、可執行動作、逾時處理與操作紀錄，才能在尖峰報名和臨時變更時維持一致。

把名額、訂單與參賽資格分開

「已填資料」「已保留名額」「已付款」和「可參賽」是四件不同的事。使用者填完資料後，系統可能暫時保留名額等待付款；付款服務回傳成功後，報名才進入待審或已成立；若賽事項目另有資格文件，還要通過確認才能產生參賽資格。把它們全部塞進一個「完成」欄位，會讓客服無法判斷該補款、補件、釋放名額或直接報到。

規格可以先定義一條最小狀態鏈：草稿、待付款、已付款、待確認、已成立、已取消、已退款與已報到。每次轉換都要記錄來源事件、時間和操作者。名額應由哪個狀態占用也要寫清楚：待付款是否保留、保留多久、逾時由排程釋放，候補名單何時收到遞補資格，以及遞補後是否有新的付款期限。

這樣才能處理兩位參加者幾乎同時搶最後一個名額的情境。前台看到「尚有名額」只是讀取結果，不代表送出後一定取得資格；後端仍要在同一個受控步驟確認並扣住名額。驗收時應模擬同時送出、重整重送、付款逾時和管理員手動取消，而不是只測一位使用者順利完成。

Google Calendar 的建立活動文件顯示，行事曆事件可以包含開始與結束時間、時區、地點、參與者及提醒，也能由 API 建立。這很適合把已確認的賽程或課程加入工作人員、教練或參加者的行事曆，但不代表 Google Calendar 應該成為名額與付款的唯一資料來源。

比較穩健的做法，是先由報名系統確認狀態，再把必要資訊同步到行事曆。規格要記錄外部事件 ID，定義改期、取消與重送的處理方式，並確保同一筆報名不會因重試而建立兩個行事曆事件。若同步失敗，報名資料仍應保留，後台要能看見待補送項目，而不是把參加者回退成未報名。

通知也遵循相同原則。成功頁、電子郵件或 LINE 訊息是把系統狀態告訴使用者，不應反過來用「訊息有沒有送到」判斷付款是否成功。通知內容至少要包含活動、梯次、報名識別碼、目前狀態與自助查詢入口，避免參加者只能截圖一則訊息向客服求證。

若活動報名網站允許參加者從 LINE 查詢、取消或確認通知，LINE Developers 的 webhook 文件要求接收端驗證簽章，並建議非同步處理事件。文件也明確說明，同一事件可能重送，可用 webhookEventId 辨識重複；重送事件的抵達順序也可能和實際發生順序不同。

這些限制應直接變成驗收項目。相同 webhook 收到兩次，不能取消兩次、發出兩張票或重複建立報名；較晚發生的事件先抵達時，系統不能把新狀態覆蓋成舊狀態。接收紀錄應保留事件識別碼、驗證結果、處理狀態與錯誤原因，但不要因方便除錯就在一般後台無限制暴露敏感資料。

「SPORTMEET 賽事官網」（sportmeet-event）案例把報名倒數、名額狀態、賽事資訊、路線與注意事項集中在活動網站，並針對手機報名流程最佳化。這個案例適合用來說明：前台不是單獨一張表單，而是從理解賽事、選擇項目、確認剩餘名額到完成報名的一條連續路徑。

實作其他賽事時，不應從案例延伸猜測付款方式或營運成果；可直接借鏡的，是資訊與狀態的安排。首頁倒數應使用明確時區，截止後按鈕與文案同步改變；項目頁應顯示適用資格、時段與狀態；報名完成後應提供可再次開啟的查詢頁。手機驗收要涵蓋較慢網路、返回上一頁、重複點擊與欄位錯誤，而不是只確認版面會縮放。

候補不是另一張無關表單。當正式名額釋出，系統要依已公開的規則選出候補者，建立遞補期限，並在對方逾時後繼續處理下一位。原本取消者、候補者和新取得名額者的紀錄都要能追溯，客服才說得清楚為何有人收到通知、有人仍在等待。

現場報到也應更新同一筆報名。以報名識別碼或經評估的核對方式找到資料後，系統記錄報到時間與操作人；重複掃描要顯示已報到，而不是新增第二次入場。若現場網路不穩，離線或人工備援如何避免事後重複匯入，也要在上線前演練。

一套可用的活動報名網站，不是功能清單越長越好，而是每一筆名額都能回答目前由誰占用、付款與資格是否確認、通知是否送出，以及現場是否已報到。先用狀態與例外寫規格，再畫頁面和估價，才是預約系統客製能被驗收、也能交給營運團隊長期使用的基礎。