為你的健身房打造團體課排課與預約應用程式

痛點

• 早上六點的飛輪課滿班了，卻有三個人爽約，十八台飛輪車空了一半，而紙上那份想進卻進不來的候補名單，從來沒人去叫。
• 堂數卡和會籍都記在一張試算表裡，前台根本說不清某位會員的十堂卡是用完了、過期了，還是他的不限次會籍因扣款失敗被凍結了。
• 沒有一條誰都能執行的取消政策——會員開課前五分鐘退課，不必付任何費用，於是爽約成了常態，黃金時段看起來滿班，實際卻空蕩蕩。
• 換教練、連假閉館全靠一則則手動發訊息通知，結果還是有會員為一堂已經取消的課，跑到鎖著門的教室前撲了個空。

系統裡的一天

1. 業主只需把每週課表設定一次——每堂課配好教練、時間和容量——系統就會為接下來幾週產生帶日期的課程實例。
2. 會員在你自己的網域上登入，看到本週課表和即時的"剩餘名額"，預約了週六早9點的 HIIT；系統確認他的卡裡還有堂數，並扣掉一堂。
3. 早6點的飛輪達到了 18 台的上限；下一位會員點"加入候補"，依順位排隊，而不是被直接拒於門外。
4. 晚8點，一位已預約的會員取消——在 12 小時時限之內，於是這一堂數作廢——系統自動把候補名單上的第一位遞補上來，並透過簡訊/電子郵件通知他有名額空出。
5. 一位教練請病假：業主為那一堂課程實例改派代課教練（或直接取消），所有已預約的會員都會自動收到通知，誰也不會跑到鎖著的門前。
6. 上課時，教練在平板上打開簽到名單，為出席會員打卡；預約了卻沒來的人被標記為爽約，依政策在其帳戶上留下記錄。
7. 某位會員的月費扣款失敗，狀態轉為暫停，在帳務問題解決前新的預約被擋下，而他已有的預約維持不變。
8. 到了週末，業主依課程和教練檢視出席情況，找出那些總是空著的時段，把它們砍掉或挪走。

AI 容易出錯的地方

• 容量屬於帶日期的課程實例，而不是那個循環範本。圖省事的做法只給課程設一次上限，結果一次取消就好像替未來每一個週二都"空出了一個名額"。每一次開課都需要有它自己的計數、候補名單、代課和取消。
• 最後一個名額的爭搶：兩位會員在同一秒點下最後一台飛輪的"預約"。如果交易（transaction）裡沒有一次原子性的容量檢查，你就會把課賣超——同樣的 bug 也會把兩個人從候補名單遞補進同一個空位。
• 取消時限的計算必須以課程的當地開始時間為準，還要扛得住日光節約時間的切換。時區或"春季調快一小時"算錯了，你就會對本來完全合規的取消收取爽約費。
• 堂數與退還就是這門生意的經濟模型：在時限內取消，堂數作廢；在時限外取消，堂數退回卡裡。一個總是退還——或者從不退還——的系統，會悄悄毀掉你的營收。過期的堂數卡和被凍結的會籍同樣必須擋下預約。
• 首次到店的會員必須先有一份已簽署的免責聲明／健康篩檢存檔，才能參加課程——讓人在沒簽免責聲明的情況下就預約、訓練，是實實在在的責任漏洞，絕不是可有可無的功能。另外，絕不要自己保存信用卡卡號；一切收款都走符合 PCI 標準的金流服務商的保險庫。

常見問題

堂數卡和不限次會籍如何在同一套系統裡共存？

每位會員的卡記錄都帶有一個方案類型，對堂數卡還帶有剩餘堂數餘額。預約時，持堂數卡者扣掉一堂，不限次會員則只核對狀態是否有效且未被凍結。預約畫面和取消引擎讀的都是這同一個錢包，所以會員絕不可能約上一堂堂數卡涵蓋不了的課。

一堂課約滿了會怎樣？

新的預約請求會進入一份有順序的候補名單，而不是被直接拒絕。一旦有人取消或名額空出，系統自動把排在最前的人遞補上來並通知他——你再也不用手動去追那些空著的飛輪。在 ybuild 上，這一切即時運轉在你自己的網域上，會員整個流程都能自助完成。

我能強制執行取消政策、對爽約收費嗎？

可以。你設定一個時限——比如 12 小時。在時限外取消，堂數退回卡裡；在時限內取消，或乾脆沒來，會員就作廢該堂數，或依你的規則被標記並收費。是教練的簽到畫面，把一筆預約變成"已出席"或"爽約"的記錄。

教練臨時請病假或連假閉館，我該怎麼處理？

因為每一堂帶日期的課都是獨立的實例，你只需取消或改派那一次開課，所有已預約的會員都會自動收到通知。循環範本和其他每一週都原封不動，所以一次性的改動絕不會重寫你的整張課表。

會員一定要先簽免責聲明才能預約嗎？

你可以要求會員在第一筆預約確認前，先簽署一份免責聲明或健康問卷，並把簽署日期存進他的記錄，方便日後員工舉證。收款走符合 PCI 標準的金流服務商，卡號都保管在那裡的保險庫中，絕不落在你的系統上。