系統導入・案例拆解

會員預約系統的容量怎麼算？以凝聚運動顧問為例

凝聚運動顧問有台北旗艦店和板橋創始店，兩間店共用一套後台。原本的預約系統合約到期後，會員購課、預約、教練排班和主管報表都搬進了自己的系統。這篇從預約容量怎麼計算講起，再談排班和其他功能。

這套系統要處理的事

凝聚的系統由我們開發，裡面有四種角色：會員、教練、主管和管理員，每一種角色看到的畫面、能改的資料都不同。要搬進來的東西包括會員購課、預約、教練排班和主管報表，兩間分店都在同一套後台裡作業。

系統是自己的，規則就能照場館的實際狀況來定，預約容量的計算方式就是一個例子。容量算得太鬆，系統顯示還能約，會員到了現場卻沒有位置；算得太緊，明明還有空間的時段又排不進課。下面先講凝聚的容量怎麼算。

很多預約系統的做法是幫每一堂課設人數上限。場館只有一種課的時候，這樣算沒有問題。凝聚的情況比較複雜，同一層樓、同一個時段，可能同時排了一對一、工作坊和團課。每一堂課各自設上限的話，每一堂都顯示還有名額，加起來卻可能超過那層樓容納得下的量。

所以凝聚的系統用「時段 × 樓層工作位」來算容量。每一層樓有一定數量的工作位，某個時段裡，那層樓能用的就是這些工作位。台北和板橋的樓層各自計算，不管排進來的是一對一、工作坊還是團課，都從同一層樓、同一個時段的工作位裡扣。

舉一個情境：某個時段，一層樓已經排了一堂團課，接著又有一堂一對一排進同一層、同一個時段，這堂一對一也從那層樓的工作位裡扣。之後再排進一場工作坊，如果剩下的工作位不夠，後台就會把這個時段標成超出容量。

三種課就是這樣互相扣減的。一對一排得越多，同一時段的工作坊和團課能用的工作位就越少，反過來也一樣。容量只記一本帳，三種課的預約都算在同一個數字上，不會各算各的。

容量滿了以後的處理方式，一般有兩種設計：系統直接擋下，不讓課排進去；或是允許排入，同時發出提醒。凝聚的系統用的是後者。後台的場地容量頁會標示哪些時段超出容量，主管看到之後，可以把課調到其他時段，也可以評估後照原樣保留。

直接擋下看起來比較嚴謹，可是場館現場總有系統算不到的例外。碰到例外時，硬擋的系統只能讓主管去找工程師改設定，或是回頭用紙本和 Excel 表格另外記。用提醒的方式，系統負責把超出的時段標出來，怎麼處理交給最了解現場的主管。

場地有容量，教練的時間也有限。凝聚有兩間店，教練可能兩邊都有課，系統會做跨店重複排班偵測，避免同一位教練在同一個時段被兩間店都排進去。兩間店共用同一套後台，這項檢查才有辦法做；班表如果分散在兩套系統裡，就得另外想辦法比對。

排班本身也有流程。班表要送主管審核，系統也會依雙週變形工時的規則做檢查。上課紀錄在教練的手機版填寫，打卡也在同一套系統裡完成。

會員用 LINE 一鍵登入，不用另外記一組帳號密碼。課程可以買點數或時數包，子帳號能共享同一份時數，購課和預約都在同一個地方完成。線上付款串接 LINE Pay 和綠界，購買後開立電子發票，合約也是電子合約。

主管這邊偏重營運管理。主管在後台處理審核，也能看到每位會員的進步軌跡；系統會自動幫會員貼標籤，並發送上課提醒和到期提醒。後台操作會留下紀錄，會員的個資欄位加密儲存。

系統用 Next.js 和 TypeScript 開發，資料庫選 PostgreSQL 這套關聯式資料庫。會員用 LINE Login 登入，金流串接 LINE Pay 和綠界。容量計算要同時對照時段、樓層和三種課的預約，資料之間的關聯多，放在關聯式資料庫裡處理比較直接。

你的場館如果也要做預約系統，可以先把下面幾件事整理出來，談容量時會省下很多來回：

第三項建議一開始就想清楚，先上線再改的話，預約流程和後台畫面都要跟著動。這幾項定下來，容量的計算方式和後台要顯示哪些資訊就有了依據，畫面怎麼設計可以之後再談。

傳一段你現在的作業方式，或一張常用表單的截圖，先談 30 分鐘需求訪談，不收費。