課程與教育營運系統
教育與培訓公司如何建立課程管理系統？從報名、收款到出席與完課
從帳號、資格、選課與梯次，到付款、點名、補課、完課、通知與權限，規劃能真正承接教育營運流程的課程管理系統。
教育與培訓公司的營運，通常不是把課程放上網站讓學員付款就結束。一筆報名可能還要確認企業身分、會員資格或先修條件，安排正確梯次，核對付款與發票，再一路管理點名、請假、補課、教材、完課資格與證明。當這些資訊分散在表單、LINE、試算表、金流後台與講師自己的名單裡，客服每天都在查資料，營運人員反覆複製貼上，主管則難以掌握每個梯次的招生、出席與收入。課程管理系統的價值，是把學員旅程與內部作業放進同一套可追蹤的規則，而不只是多做一個報名頁。
具體客戶問題與難點：同一位學員被拆成多份不一致的紀錄
常見流程是網站表單收到報名後，由人員將姓名貼進試算表，再到金流或銀行核對款項，最後另開一份點名表給講師。學員改選梯次、企業統一付款或申請補課時，每份資料都要手動修改；只要漏改一處，客服看到的付款狀態、講師拿到的名單與財務認列的收入就會不同。問題不只是行政效率，而是公司缺少一筆能串起帳號、資格、選課、付款與學習結果的主紀錄。
課程本身也有多層關係：一個課程可以有多個梯次，每個梯次有獨立名額、時間、講師、教室或線上會議連結；同一位學員可能由公司採購、本人上課，也可能因請假改到另一梯次補課。若只用一張報名表，很難正確表示候補、轉班、部分退款、團體名額、出席門檻與完課條件，更無法限制不同角色能看見或修改的資料。
以同時經營公開班與企業包班的培訓公司為例：公開班由學員自行選課付款，企業班則由窗口一次提供一批學員名單，部分學員需要先完成線上測驗才可選進階課。營運團隊每週人工比對報名表、匯款、出席與補課名單。
- 帳號與資格：個人、企業窗口、學員與講師之間的關係不一致
- 選課與梯次：名額、先修條件、轉班、候補與團體報名難以同步
- 點名與完課：請假、補課、出席門檻、測驗與證明缺乏共同規則
- 付款與通知：已付款、待補款、退款、發票與提醒散落在不同工具
何時值得做：先判斷流程差異是否已超過一般工具可承接的範圍
如果公司只有少量固定課程、每期學員不多，也沒有複雜資格或補課規則，標準表單、金流頁與整理良好的試算表可能已經足夠。客製系統不是為了取代所有現成工具，而是在課程種類、梯次頻率、角色交接或例外處理增加後，建立一致的營運核心。評估時應計算的不只是每月報名數，也包括一筆報名會被重複輸入幾次、客服要跨多少個後台查詢，以及錯誤會影響多少學員。
通常值得進一步規劃的訊號包括：同一位學員在多個名單中有不同狀態；企業採購與個人上課無法放在同一流程；名額釋出、轉班與候補依賴人工記憶；完課證明必須重新核對出席與作業；財務月底才發現報名與收款無法對帳；或管理者需要跨梯次查看招生、收入、出席與續報。此時可先比較設定既有 LMS、串接 SaaS，與建立客製營運模組三種路徑，不必預設所有功能都要自行開發。
AgentTech 會把高頻、可標準化且容易出錯的流程列為第一階段，低頻例外則先保留人工覆核。例如報名、名額與付款狀態可優先整合，而特殊退費、跨年度學分抵免或複雜企業請款，則可透過後台任務與審核處理。這樣能讓建置範圍對應真實營運價值，也避免一開始就做成難以驗證的大型平台。
- 每週需要多次人工合併報名、付款、點名或補課名單
- 公開班、企業班、會員方案或多據點使用不同規則
- 客服無法在一個畫面回答學員的報名、付款與完課狀態
- 既有 LMS 能管理內容，卻無法承接公司的招生與營運流程
AgentTech 方法與技術設計：先建立資料主體，再讓規則與串接圍繞它運作
AgentTech 會先以真實流程訪談建立服務藍圖，釐清誰建立帳號、如何驗證資格、由誰選課、何時占用名額、付款成功後開放哪些內容，以及出席與完課如何判定。資料模型通常會分開處理使用者、組織、學員身分、課程、梯次、報名、付款、出席、補課與完成紀錄，避免把所有狀態塞在同一張表。企業窗口可以管理所屬名單，但不應看到其他企業資料；講師只需存取負責梯次的點名與教學資訊；財務可查付款與退款，卻不必修改學習紀錄。這些角色與權限會以最小必要存取原則設計。
報名流程需要明確的狀態機，例如待資格確認、待付款、已保留、報名完成、候補、取消與退款。名額不應只在前端顯示，而要由後端在提交或付款關鍵節點再次檢查。付款結果透過金流回呼更新，並保留訂單、交易與狀態歷程，避免使用者關閉頁面後失去結果。通知則由業務事件觸發，例如報名完成、付款失敗、課前提醒、教室異動、候補遞補、缺席後補課選項與達成完課，而不是由人員逐筆複製訊息。
點名可以由後台、講師頁或行動裝置完成，並記錄出席、遲到、請假與缺席。補課不是直接覆蓋原始紀錄，而是建立原梯次缺席與替代梯次出席的關聯；完課判定則依出席比例、必要單元、測驗或作業規則計算，重要資格由管理者覆核。若需要 AI，可用於整理學員提問、產生待回覆摘要或協助分類客服案件，但付款、資格、成績與證明等高影響結果仍由明確規則和授權人員確認。
- 核心資料：帳號、組織、學員、課程、梯次、報名、交易與學習紀錄
- 營運規則：資格、名額、候補、轉班、補課、取消、退款與完課
- 整合介面：品牌網站、金流、Email、LINE OA、視訊或既有 LMS
- 治理能力：角色權限、操作歷程、個資保存、匯入匯出與異常追蹤
分階段落地：先跑通一種課程，再擴到企業班與自動化
第一階段先選一個規則相對穩定、報名量足以觀察的課程，完成帳號、課程與梯次管理、報名、名額、付款狀態、基本通知和營運後台。上線前以真實但去識別化的樣本測試重複報名、付款延遲、名額滿載、取消與管理者更正，並安排舊名單的清理、欄位對照、試匯入與回復方案。此階段的目標是讓一筆報名從入口到確認不再需要重複建檔。
第二階段加入講師點名、請假與補課、完課條件、證明產生，以及企業窗口與團體名單。對每個自動化事件設定失敗佇列與人工處理入口，例如付款回呼未收到、通知退信、學員資料重複或補課資格無法判定時，營運人員能看見原因並安全重試，而不是讓案件沉默消失。
第三階段再依使用數據導入跨梯次報表、續報與會員方案、內容平台串接、推薦或客服輔助。每次擴充都應檢查報名完成率、待人工處理量、名單差異、付款對帳差異、點名完成率與客服查詢時間。若某項規則仍頻繁變動，先保留可設定的後台欄位與人工審核，比把不成熟流程寫死在程式中更穩定。
- 第一階段：報名、梯次、名額、付款、通知與基本營運後台
- 第二階段：點名、請假、補課、完課、證明與企業團體管理
- 第三階段：跨系統整合、營運報表、續報與適度 AI 輔助
最終交付物與驗收：交付可營運的平台，也交付可持續管理的規則
依確認範圍，AgentTech 最終可交付學員端報名與帳號介面、課程與梯次頁、付款及通知串接、講師點名介面、企業窗口功能，以及具權限控管的營運後台。後台會讓授權人員管理課程、名額、資格、報名、補課與完成狀態，並查閱交易、通知和操作歷程。若沿用既有 LMS 或金流，交付也包含資料交換方式、失敗處理與對帳流程，而不是只完成畫面連結。
驗收不只檢查頁面是否能開啟，而要用端到端情境測試：符合與不符合資格的帳號能否正確選課；最後一個名額在同時報名時是否只會成立一次；付款成功、失敗與逾時是否留下可查狀態；取消後名額與候補是否按規則處理；講師點名、學員補課與完課資格是否可追溯；不同角色是否只能看到被授權的資料。報表總數也要能回查到報名與交易明細。
交付內容通常還包括資料字典、角色權限表、重要流程圖、管理操作說明、部署與環境設定、監控與備份安排、第三方服務清單，以及上線後的問題處理與擴充邊界。實際項目會依專案範圍寫入規格與驗收條件，讓教育公司取得的不只是一次性網站，而是一套能持續承接招生與教務營運的產品基礎。
- 可使用的學員端、講師端、企業窗口與營運管理後台
- 金流、通知、既有網站或 LMS 的整合與失敗處理機制
- 資料移轉結果、權限矩陣、操作歷程與關鍵營運報表
- 測試紀錄、操作文件、部署維運與後續擴充規格
這篇文章適用的服務
客製系統與數位平台
SYS Agent
需求診斷、CRM、電商、會員、預約、營運後台、資料權限、API 整合與部署維運。