企業買線上課程，誰負責開通與客服？講師、HR、系統管理員怎麼分工

角色	主要負責
講師／課程團隊	教學內容、作業、專業答疑、課程交付
企業 HR／培訓窗口	採購名單、內部通知、員工異動、主管協調
課程系統管理員	帳號、權限、登入、課程開通、系統問題
企業 IT	公司網路、瀏覽器政策、SSO、公司設備與內部資訊系統

這四種角色可以由不同人擔任，也可能小型專案由同一人兼任。

重點不是職稱，而是每一種問題都要有明確主責者。

第一類：名單誰提供？HR 應該是主要窗口

企業採購最常見的開通方式，是由企業提供學員名單。

這時 HR／培訓窗口通常要負責：

確認參訓人數。
提供姓名與公司電子郵件。
確認部門或分組。
處理新增、退出與替換名單。
通知員工何時開始學習。

課程業者不應自己猜：

「這個人是不是還在職？」

員工身份與企業內部人事異動，最接近正確資訊來源的是企業自己。

第二類：帳號誰建立？系統管理員負責執行，不代表 HR 不用確認資料

收到名單後，系統管理員可以負責：

建立帳號。
指派課程。
設定企業／部門群組。
寄送登入通知。
確認席次是否超額。

但如果原始名單就有錯，例如電子郵件拼錯、重複人員、離職員工仍在名單裡，系統管理員也無法自行判斷正確資料。

所以一個完整流程應該是：

HR 確認名單 → 系統管理員建立帳號 → HR 確認開通結果。

企業多人帳號與席次怎麼管理，可以搭配企業一次買多人線上課程怎麼交付？席次、帳號、名單與權限怎麼管理。

第三類：登入問題不要全部丟給講師

登入問題通常包含：

忘記密碼。
收不到驗證信。
帳號不存在。
課程沒有顯示。
權限過期。
帳號被鎖定。

這些大多屬於系統／帳號支援，不需要講師親自處理。

如果學員每次都直接傳訊息給講師，講師還要再轉給技術人員，會多一道無價值的中轉。

更好的做法是提供一個明確入口，例如：

客服表單。
客服信箱。
會員中心支援入口。

學員只需要知道「有問題從這裡進來」，內部再分流。

第四類：公司電腦打不開課程，未必是課程網站故障

B2B 培訓常見一種情況：

學員在家裡可以看，到了公司電腦就不能播放。

可能原因包括：

公司防火牆。
瀏覽器限制。
公司 VPN。
影音網域被封鎖。
公司裝置政策。
企業單一登入設定。

這時課程平台可以協助判斷問題，但如果根本原因在企業自己的網路或裝置政策，最後仍需要企業 IT 處理。

這就是「共同責任」的概念：每一方處理自己能控制的那一層。

第五類：課程內容問題，才應該進講師／教學團隊

例如：

某個觀念聽不懂。
作業不知道怎麼做。
案例要怎麼套用。
想請講師給專業回饋。

這些問題如果丟給系統客服，客服最後也只能回答：

「我們幫您轉給老師。」

因此教學支援可以有自己的入口：

課程問答區。
固定直播答疑。
作業回饋。
指定助教。

技術客服與教學客服最好分開計算工時，否則你很難知道一個企業案實際花了多少交付成本。

第六類：員工新增、離職、換人，誰有權要求變更？

系統管理員可以執行權限變更，但不應接受任何一位學員說：

「同事離職了，你幫我把他的帳號換給我朋友。」

企業名單變更應由事前指定的企業窗口提出。

可以規定：

只有 HR／指定管理員能新增或移除席次。
學員本人只能處理自己的帳號問題。
跨部門轉移要由企業窗口確認。
離職員工依企業通知停權。

這樣權限異動才有依據。

第七類：成果報告由誰產生？系統出資料，HR 與講師共同解讀

完成率、登入、作業與證書資料通常由課程系統產生。

但原始數字本身不等於完整結論。

例如：

完成率只有 55%。

系統管理員可以告訴你哪些人沒完成，但「為什麼沒完成」可能需要：

HR 確認是否有工作排程問題。
講師確認是否內容太難。
技術人員確認是否有系統阻礙。

企業培訓成果怎麼回報，可以看企業培訓成果怎麼回報？完成率、作業、證書與主管報告怎麼設計。

用一張責任表，開課前就把事情講清楚

跨組織合作很適合用責任分工矩陣（RACI）：誰執行、誰最終負責、誰需要被諮詢、誰只需要被通知。

任務	主要執行	最終確認
提供學員名單	企業 HR	企業 HR
建立帳號與課程權限	系統管理員	課程業者
忘記密碼／登入異常	系統客服	課程業者
公司網路／設備限制	企業 IT	企業 IT
課程內容答疑	講師／助教	講師
員工新增／離職	企業 HR 提出	企業 HR
執行帳號停權	系統管理員	課程業者
成果資料匯出	系統管理員	課程業者
培訓結果解讀	HR＋講師	企業主管／HR

不一定每個企業案都用同一張表，但至少不要讓責任只存在某個人的腦袋裡。

對學員最好只有一個入口，內部再分清楚主責者

內部分工可以很細，但不要把複雜度丟給學員。

最差的客服體驗是：

「這不是我們負責，請你去問 HR。」

HR 又說：

「這是平台問題，請你找老師。」

老師最後說：

「我不懂系統，你再去問客服。」

更好的設計是：

學員從單一客服入口提出。
第一線先分類問題。
能直接處理就直接解決。
需要其他主責者處理時，再由內部轉交。
仍由原客服入口回覆進度。

學員不需要理解你的公司組織圖。

客服分流可以用 6 個問題快速判斷

學員問題	優先主責者
我沒有帳號	系統客服＋HR 確認名單
我登入不了	系統客服
公司電腦打不開	系統客服初判 → 企業 IT
我看不懂第三課	講師／助教
我要換成另一位員工	企業 HR
主管要完成率報告	系統管理員＋HR

不要讓「講師本人」成為所有問題的單點瓶頸

講師的時間通常是整個高價課程裡最稀缺的資源。

如果講師每天親自做：

修改電子郵件。
重設密碼。
查帳號。
加席次。
匯出名單。

這些低槓桿工作會直接擠壓只有講師最適合處理的工作：

課程設計。
專業答疑。
企業需求診斷。
案例回饋。

所以企業案一開始就要把「只有講師能做的事」和「別人可以標準化處理的事」分開。

分流之後還要有升級路徑，避免問題卡在第一線

有了單一入口還不夠，內部還要定義「什麼情況需要升級」。否則第一線客服知道這不是自己能處理的問題，卻不知道下一步要找誰，問題還是會停在原地。

可以把升級條件分成幾類：影響單一學員的一般帳號問題、影響多人或整個企業的系統問題、需要講師判斷的教學問題，以及需要企業 IT 或 HR 決策的內部問題。每一類都指定下一個主責者，並保留原客服入口追蹤進度，學員不需要重新說明一次。

Microsoft 的企業支援設計也強調，支援模式要先定義支援範圍、支援團隊與支援作業，並把誰處理、何時處理、怎麼處理寫成可執行程序。放到企業課程也是同樣原則：越早把邊界寫清楚，越少靠臨時轉交救火。

客服標準要包含回覆時間與升級條件

企業客戶不只在意「誰處理」，也會在意：

多久會收到第一個回覆。
一般問題多久處理。
重大系統故障怎麼通報。
超過多久會升級。

不一定要做成大型企業等級的服務水準協議，但至少應有內部標準。

例如：

一般帳號問題：一個工作日內回覆。
全體無法登入：列為重大問題。
個別課程內容問題：依教學答疑節奏處理。

不同問題的時效可以不同，不要承諾「所有問題 10 分鐘解決」這種不可能長期維持的標準。

如果企業案有明確上線日期或大量學員同時開課，還可以再加一層「重大事件」標準：例如全體無法登入、課程權限大量錯誤、企業管理員無法操作時，直接跳過一般排隊流程，通知指定窗口並持續回報處理進度。這樣企業知道什麼情況會被優先處理，客服團隊也不需要每次臨時判斷。

哪些事情應該讓企業自助？

如果企業案很多，所有異動都靠客服人工處理會很重。

可以逐步讓企業管理員自助：

查看席次。
新增／停用成員。
查看完成率。
下載證書。
匯出報表。

但自助功能也要有權限邊界。

HR 管理員不一定需要網站最高管理權限；能做工作需要的操作就夠了。

企業採購前就要把支援邊界寫進方案

例如：

是否含帳號批次開通。
是否含名單異動。
一個月可以換多少席次。
是否提供企業管理員。
是否提供完成率報表。
是否含講師專業答疑。
是否含企業 IT 串接。

這些都是成本。

如果銷售時全部回答「都可以」，成交後才發現每家企業都要客製客服流程，毛利會很快被吃掉。

B2B 課程和個人課程最大的差異之一，就是多了一層企業管理責任

個人購買通常只有：

課程業者 ↔ 學員

企業採購則變成：

課程業者 ↔ HR／採購 ↔ 主管 ↔ IT ↔ 學員

角色越多，責任越需要明確。

完整的 B2B 交付差異，可以看 B2B 線上課程和一般個人課程差在哪？從採購、授權、交付到續約完整拆解。

常見問題

企業員工忘記密碼，應該找 HR 還是課程業者？

通常由課程系統客服處理較有效率；若系統查不到該員工，才再由 HR 確認是否原本就在採購名單。

員工離職，講師可以直接把席次換給別人嗎？

不建議只靠學員口頭要求。名單與席次異動應由企業指定窗口提出，再由系統管理員執行。

公司電腦不能播放影片，是平台客服負責嗎？

平台可以先協助判斷；如果原因是企業防火牆、設備政策或內部網路，則需要企業 IT 處理。

學員問課程內容，也走同一個客服入口嗎？

可以使用同一入口收件，但內部應轉交講師或助教，避免一般技術客服回答專業內容。

企業需要一位自己的管理員嗎？

人數少時可由 HR 窗口處理；人數變多後，有企業管理員角色會更容易管理席次、成員與報表。

講師要不要親自處理客服？

講師應優先處理需要專業判斷的教學問題；帳號、密碼、名單與一般系統問題盡量標準化交給客服或系統管理員。

結論：對學員保持一個入口，對內部建立清楚主責者

企業線上課程的客服不是「有人回信就好」，而是一套責任設計。

HR 管名單與內部人員狀態，系統管理員管帳號與權限，企業 IT 管公司自己的設備與網路，講師則負責課程內容與專業交付。

對學員來說，入口越簡單越好；對內部來說，主責者越清楚越好。

把分工、升級條件與回覆標準在開課前建立，才能讓企業案規模變大時，客服不會全部堆到講師本人身上。

參考資料：
Microsoft Learn｜Create a support strategy for your Dynamics 365 solution。
Microsoft Learn｜Set up a technical support team for your Dynamics 365 solutions。
Matthew Skelton、Manuel Pais｜Team Topologies。

先分清楚：企業課程客服其實有 4 種角色