課程報名系統 建置費用｜會員、多學生、金流與後台怎麼規劃？

作者：益盛科技 專案經理 Ring

「我們想讓家長在線上報名課程，請問要多少錢？」

學校教育單位來詢價，第一句話常常就是這句。而他們原來的報名系統大部份是 Google 表單。

最近我們替一個教育單位做課程報名系統的規劃，談到最後拆成 21 個工作項目。
首頁與內頁視覺設計只占預算約一成；
會員、學生資料、課程名額、購物車、金流與報名後台這幾項加起來，接近六成。
家長在前台看到的是一個「立即報名」按鈕，但程式要處理的是誰在報名、替哪個孩子報名、報哪一個梯次、還剩幾個名額、錢有沒有付成功。

以下用為我們的的企劃過程，一套課程報名系統要做哪些功能、費用怎麼估，以及簽約前最容易漏掉的營運規則。

課程報名系統和 Google 表單差在哪裡？

單純收報名資料，Google 表單就夠用

一年只辦一兩場免費講座，收姓名、電話、E-mail，Google 表單免費又快，沒有理由另外花錢開發。
我也常勸剛起步的單位先用表單跑一季，看清楚報名量和問題出在哪，再決定要不要投資系統。

碰到名額、會員、付款，表單就開始吃力

表單的問題通常在報名資料收進來之後。

同一個梯次只剩 1 個名額，三位家長同時送出表單，誰算報名成功？
報名後一直沒付款，名額要保留幾天？
一位家長替兩個孩子報不同課程，要填兩次完整資料嗎？
付款成功後，誰去把那一列改成「已繳費」？
家長半年後想查自己報過什麼課，要去哪裡查？

這些都沒辦法靠多加幾個欄位解決。
課程報名系統處理的是會員、學生、課程、梯次、名額、訂單、付款狀態之間的關聯，而表單只負責收文字資料。

家長與學生個資，表單很難管權限

報名資料裡有家長手機、學生生日、就讀學校，這些都屬於個人資料保護法定義的個人資料。
表單回覆通常集中在一份共用試算表，編輯權限開給幾位行政人員之後，很難再細分誰只能看、誰可以匯出；
共用設定一旦誤設成「知道連結的任何人」，整份名單就等於公開。

報名系統可以依角色分權限，後台登入加上兩步驟驗證，匯出名單留下操作紀錄。
這些做法無法保證零風險，但出狀況時查得到是哪個帳號、在什麼時間動過資料。

哪些學校教育單位需要自己的報名系統？

判斷方式很直接：招生是一次性活動，還是每年都在跑的營運流程？後者通常會出現在以下幾類單位。

教育推廣協會與非營利單位

每年固定開課後班、寒暑假營隊，會員資料希望留在自己的網站，並且要能回頭聯繫過去報名的家長。

補習班、語言中心與才藝教室

課程多、班別多、常有多校區，行政人員每天都在對報名名單和繳費紀錄。

夏令營、冬令營與兒童營隊

報名集中在開放後幾天，名額搶得快，最容易出現超收和重複付款。

企業培訓與研習活動

常需要多人團報、開立發票或收據、統計出席，流程比一般活動報名多一層。

有「家長＋學生」關係的服務最需要留意：
付款人是家長，上課的是學生，同一位家長底下可能有兩三個孩子。
這個關係一旦放進資料庫，就會影響後面所有程式模組的設計。

完整的課程報名系統要有哪些功能？

以下七項是這次專案實際列進規格的功能，也是我評估教育類報名系統時會逐項核對的清單。

1. 會員註冊與手機 OTP 驗證

家長用手機號碼當帳號，註冊時收簡訊驗證碼完成驗證。
之後學生資料、訂單、繳費紀錄都掛在同一個帳號底下，下學期再報名不用重填。

OTP 要串國內簡訊商的 API，簡訊費依發送量計算。

2. 一位家長管理多位學生

會員中心可以建立多位學生，欄位通常包含中英文姓名、性別、生日、就讀學校與年級。
報名時直接勾選要報名的孩子。

看起來只是多一張學生資料表，實際上訂單明細必須記錄「哪位學生報了哪個梯次」，退費、轉班、出席統計都要依這個關係運作。

3. 課程、校區、時段與名額

一門暑期營隊可能同時開兩個校區、上午下午各一班，每一班名額不同。
後台要能設定課程類別、招生期間、校區、時段與名額，前台則在額滿時自動反白、停止報名。

這些設定都能由行政人員在後台操作。

4. 購物車與多學生、多課程結帳

兩個孩子各報兩門課，最差的體驗是讓家長填四次表單。
順暢的流程：先選課、再選學生、加入購物車，最後一次確認金額並付款。

結帳頁同時要帶入會員聯絡資料、常用學生資料，收飲食限制與注意事項，並讓家長勾選同意報名須知。

5. 信用卡、LINE Pay 與銀行轉帳

線上付款串第三方金流，家長付完款後，金流平台把交易結果回傳網站，系統再把訂單改成已付款。
銀行轉帳則提供匯款帳號與後五碼回報欄位，由行政人員在後台人工核帳。

回傳機制要能處理同一筆交易被通知兩次的情況，否則會出現一張訂單被重複入帳，這是金流串接最常見的錯誤來源。

6. 會員訂單與報名查詢

家長登入後看得到訂購日期、課程明細、報名學生、付款方式、付款金額，以及待付款、已完成、已取消等狀態。

這一頁做得清楚，行政人員就能少接很多「我到底報成功沒有」的電話。

7. 報名後台與 Excel 匯出

行政人員每天真正在用的是後台：
新增或下架課程、看各梯次報名人數、篩選已付款與未付款名單、維護繳費狀態，
並把會員名單、報名名單匯出成 Excel 或 CSV。

前台畫面漂不漂亮，會影響家長的第一印象；
後台好不好用，影響的是行政人員往後每一天的工時。

外觀相似的報名系統，為什麼報價差很多？

詢價時最常聽到的問題是「這個網站大概幾頁？」
但客製系統用頁數估價，一定會估錯。

家長按下「立即報名」那一刻，系統要依序確認：
登入的是哪位會員、選的是哪位學生、報的是哪個梯次、名額夠不夠、訂單成立了沒、付款有沒有成功、取消後名額要不要放回去。
兩位家長同時搶最後一個位子時，系統要靠資料庫層級的鎖定機制處理併發，確保名額不會超賣；
金流回傳也要比對交易編號，避免同一筆訂單重複入帳。

開發工時主要花在流程規則、資料關聯、交易狀態和例外處理。
兩套外觀很像的系統，一套有處理名額鎖定與重複回傳，一套沒有，報價就會出現明顯差距，這個差別通常在第一次招生爆量那天才看得出來。

課程報名系統費用怎麼算？

市面上的報名方案大致分三種，差別在「誰去配合誰」。

SaaS 月租型

註冊帳號、付月費或年費就能開始收報名，成本最低、上線最快。
流程固定、報名量不大、沒有特殊資料結構的單位，用 SaaS 很合理。

限制在於品牌介面、會員資料結構、付款流程都照平台設計走。
多數 SaaS 由平台代管資料，停用前要確認資料匯出與移轉方式。

既有網站加報名模組

已經有官網的單位，可以在網站上加裝會員或活動報名模組，再依需求調整。
預算比全客製低，也保有自己的網域和品牌。

一旦出現家長與學生分開管理、多校區多梯次、特殊價格或審核流程，就要先確認程式模組撐不撐得住，改到後來成本可能比重做還高。
現成模組處理不了家長、多學生、課程與訂單之間的關聯，
就進入客製化程式設計／軟體開發的範圍。

完整客製化系統

需要自己的會員資料庫、家長與學生關聯、名額管理、購物車、金流、訂單查詢與專屬後台，就屬於客製化資訊系統。

以這次專案為例，範圍包含官網、會員與 OTP、多學生、課程名額、購物車、信用卡與 LINE Pay、銀行轉帳核帳、後台與匯出，一次性建置費落在 30 萬元上下，
報名成功通知、電子發票、線上退費申請另列選配。
主機、網域與年度維護另計。

這個數字只能當量級參考。
權限層級、第三方 API 數量、歷史資料要不要搬、資安要求高低，都會讓報價上下移動。

第三方服務費要另外算

建置費之外，還有按交易量計算的第三方費用，通常由單位直接跟服務商簽約、直接付款。
以下是 2026 年 9 月查詢的官方公告費率：

費率資料來源為綠界科技服務費率表與LINE Pay 收款服務說明，正式簽約仍以服務商當時公告為準。

電子發票最容易被漏算。
營業人開立電子發票，要先在財政部電子發票整合服務平台取得配號（字軌），上傳方式可以自行架設財政部提供的 Turnkey 傳輸軟體，或付費委託加值服務中心處理。
以綠界為例，2026 年 9 月公告的年度方案是 5,000 張 3,600 元起（未稅），首次另收系統設定費。
協會或非營利單位要開統一發票還是收據，建議先跟會計師確認，只開收據就沒有這筆固定年費。

哪些功能最容易把預算拉高？

會員與權限排第一。
報名不用登入，和需要會員中心、後台分多種角色，工作量差很多。

資料關聯排第二。
家長管理多位學生、學生報不同課程，資料模型一下子就比一般活動報名複雜。

第三方串接排第三。
信用卡、LINE Pay、簡訊、電子發票、LINE 官方帳號、CRM，每多一個 API 就多一套測試與錯誤處理。

營運規則是最常被低估的一項。
取消、轉班、退費、候補、付款期限、自動釋放名額，規則越多，系統要追蹤的狀態就越多。

簽約前要先講清楚哪些規則？

這次專案在報價前，我列給客戶確認的問題裡，一半與技術無關，都是營運規則。
規則沒定，工程師就只能猜，系統寫完再改，就變成需求變更要加價。

取消與退費

付款後可以取消嗎？
退全額還是扣手續費？
取消後名額要不要自動放回去？
部分學生取消、部分保留，訂單怎麼拆？
課程類服務的退費與解除權適用方式，建議由單位先跟法律顧問確認，系統再照規則實作，不要由廠商自行假設。

名額、候補與付款期限

加入購物車算不算占位？
下單後幾小時沒付款要自動取消？
額滿後要不要開候補，候補遞補時要不要重新通知付款？
同一位學生能不能重複報名同一梯次？

金流與電子發票

LINE Pay 可以直接向 LINE Pay 申請合作商店並串官方 API，也可以透過金流服務商提供的付款路徑。
兩種做法的申請流程、費率與測試環境都不同，報價單上寫「LINE Pay」之前，要先確定走哪一條。

金流帳號建議以單位名義申請，審核動輒數週，開案第一週就要送件。

個資與權限

系統會收家長姓名、手機、學生生日與就讀學校。依個人資料保護法第 8 條，直接向當事人蒐集個資時，要告知蒐集目的、資料類別、利用期間與方式，以及當事人可行使的權利。
實務上不建議只放一句「我同意隱私權政策」，網站仍應依實際蒐集內容完整提供個資蒐集告知事項，並妥善保存使用者同意的版本與時間紀錄。

後台管理員帳號建議開啟兩步驟驗證，依職務分權限，匯出名單也要留紀錄。

原始碼、主機與後續維護

原始碼是否交付、設計原檔給不給、主機帳號由誰持有、每月備份幾次、保固結束後的年度維護怎麼計價，這些寫進合約，比上線後再談容易得多。

簽約前的完整準備清單，可以參考我們整理的客製化程式開發前要準備什麼？報價前必備 4 項資料。

客製課程報名系統要做多久？

包含 UI 設計、會員、多學生、課程、購物車、金流、後台與整合測試的完整範圍，我們對外的預估是 10～12 週，從簽約、首期款入帳、素材與第三方申請資料備齊後起算。

各階段加總是 8～12 週，對外抓 10～12 週，是把審稿往返和第三方審核的等待時間算進去。
金流、LINE Pay、簡訊商的帳號審核，常常比寫程式還慢。

SaaS 還是客製，怎麼判斷？

一年幾場活動、流程單純、預算有限，直接用 SaaS。
為了看起來專業硬做客製系統，只會多一筆維護費。

課程已經是長期營運的一部分，有固定會員、多校區多梯次、家長與學生分開管理，未來還可能串 LINE 官方帳號、電子發票或內部系統，自建平台的價值才會一年一年累積出來。

我自己的判斷標準：
行政人員花在「配合現成系統」的時間，開始多於系統幫他省下的時間，就可以認真評估客製了。

課程報名系統常見問題

課程報名系統可以串 LINE Pay 嗎？

可以。
可以直接向 LINE Pay 申請合作商店串官方 API，也可以透過金流服務商提供的 LINE Pay 付款。
兩種方式的申請資格、費率與串接方式不同，建議開發前先定案。

一位家長可以幫多個孩子報名嗎？

可以。
會員與學生資料分開設計，一位家長帳號底下建立多位學生，報名時勾選實際上課的孩子，訂單明細會記錄每位學生報了哪個梯次。

課程額滿可以自動停止報名嗎？

可以。
每個梯次各自設定名額，額滿後前台自動反白並停止報名。
候補名單、逾時未付款自動釋放名額，則要在規格階段另外定義。

報名資料可以匯出 Excel 嗎？

可以。
後台可以依需求匯出會員名單、學生資料或報名名單，匯出欄位建議在需求確認時就跟行政人員對過一次。

銀行轉帳可以自動對帳嗎？

一般做法是家長回報匯款後五碼，行政人員在後台人工核帳。
要自動銷帳，可以改用金流商的 ATM 虛擬帳號，每筆訂單一組帳號，付款後系統自動更新狀態，但會產生每筆交易手續費。

已經有官網，可以直接加上課程報名系統嗎？

可以先評估，不一定要整個網站重做。
我們會先看現有網站用的平台與版本、會員架構、資料庫、主機環境，以及方不方便串金流。
原架構可以延伸，就直接加程式模組；
版本太舊或資料結構不適合，再評估獨立建一套報名系統。

一定要客製化嗎？

不一定。
基本活動報名用現成平台比較省；
會員、學生、金流、權限與內部流程都變複雜之後，再考慮客製比較合理。