現正接案 — 2026 第三季
首頁/行業/Salesforce 平台路徑

教育機構：Salesforce 解法

大專院校、線上學習、補教業導入 Salesforce 真正的關卡是「30+ 年的關係結構」——同一個人從申請者 → 在學生 → 畢業生 → 校友 → 捐款人，要在同一條 timeline 上維護。Education Cloud 提供 Constituent 物件模型把這條 timeline 設計進來；Service Cloud 處理招生 / 學生 / 校友的 case routing；Marketing Cloud 串起跨階段 engagement。EKel 在澳洲累積過大學 Education Cloud 導入經驗。

// 典型功能模組

招生與學生 360°

從申請、審核、錄取、註冊到在學服務的完整 lifecycle。Constituent 物件處理「同一個人多階段」的歷史，advisor 看得到完整脈絡。

校友與捐款 lifecycle

畢業生轉換成校友、engagement 追蹤、捐款歷史、活動參與——把校友辦從 Excel 拉到可治理的平台。

LMS / SIS 整合

SIS（PeopleSoft / Banner / Workday Student / 校務系統）是註冊與成績的 source of truth；LMS（Canvas / Moodle / Blackboard）是學習介面。Salesforce 取必要的 engagement signal，不複製。

// EKel 會怎麼落地
  1. 01盤點現有 SIS / LMS / 財務 / 宿舍 / 線上課程系統，確認哪些 Education Cloud 該擁有、哪些只查詢、哪些必須留在原系統。
  2. 02設計 Constituent 物件模型——讓「同一個人多階段」可以查得出完整 30 年互動歷史，但 sharing rule 確保各單位看得到該看的部分。
  3. 03從一個典型場景的 end-to-end 開始（例如「申請 → 註冊」或「校友互動 → 捐款」），先做完一個再擴。
  4. 04上線後 hypercare + role-based training（招生、學生事務、校友辦三組），audit trail 自我演練。
// 適合的單位
  • →大專院校、職業教育、補教集團需要把招生、學生服務、校友互動整併進現代化平台。
  • →已有 SIS 但需要新的招生 funnel + 校友 engagement 層的單位。
  • →評估從 legacy CRM、自建 .NET 或 Excel 工作流遷移的教育單位。
// 參考來源
Salesforce Education CloudSalesforce for Higher Education
回到行業列表看教育 AI 客製方案 →
// 架構分層

教育 Salesforce 是「關係 + 服務 + 互動」三層 lifecycle 結構。

// LAYER 1
關係主檔層
Constituent 物件模型——同一個人從申請者 → 在學生 → 校友 → 捐款人，30+ 年的關係在同一條 timeline。Education Cloud 把這條 timeline 設計進 schema，不必從 generic Sales Cloud 自己拼。
Education CloudPerson AccountConstituentLifecycle
// LAYER 2
服務與案件層
Service Cloud 處理招生詢問、學生事務、學業輔導、校友服務 case routing。每個 case 帶 audit trail——成績變更、特殊處理、財務決定，事後調得出。
Service CloudCase RoutingAdvisingAudit Trail
// LAYER 3
互動與整合層
Marketing Cloud 處理 prospect → 在學 → 校友的溝通 journey；Experience Cloud 給學生 / 校友 portal；整合層接 SIS（PeopleSoft / Banner / Workday Student / 校務系統）與 LMS（Canvas / Moodle / Blackboard）。
Marketing CloudExperience CloudSISLMS
// 典型導入時程

26 週四階段

完整教育 Salesforce 的標準節奏。MVP 在 Week 14 上線一個業務流程；完整 26 週包含校友與 Marketing Cloud 整合。如果只做招生 + 學生服務的整併，6-8 週能見效。

W1
W4
W14
W22
W26
00
01
02
03
// 00 · Week 1–3
盤點 + 既有系統

訪談招生、教務、學生事務、校友、IT 主管。盤點既有 SIS、LMS、財務、宿舍、線上課程系統的責任分界——確認哪些 Education Cloud 該擁有、哪些只查詢。

// 01 · Week 4–14
招生 + 學生 360 MVP

一個典型場景的端到端：申請 → 審核 → 錄取 → 註冊。Constituent 物件模型上線（Person Account 處理「同一個人 = 申請者 → 學生 → 校友 → 捐款人」的時間軸）。

// 02 · Week 15–22
校友 + Marketing Cloud

畢業生轉換成校友、捐款 lifecycle、跨單位 engagement 追蹤。Marketing Cloud journey 把招生 → 在學 → 校友的溝通串成一條時間軸。

// 03 · Week 23–26
上線輔導

招生、教務、學生事務、校友四方 hypercare。runbook、role-based training、稽核 trail（個資 / FERPA-equivalent）自我演練。

// 常見問題

教育架構討論裡最常出現的 5 件事。

01為什麼選 Education Cloud 而不是 generic Sales Cloud？
教育機構真正的客戶資產是「30 年以上的關係」——同一個人從 prospect → 申請者 → 在學生 → 畢業生 → 校友 → 捐款人，是一條長 timeline，不是「成交一次就結束」。Education Cloud 的 Constituent 物件模型把這條 timeline 設計進來；Sales Cloud 從零拼，工時 2-3 倍而且每次 Salesforce 主版本升級都要自己處理相容性。對教育場景，Education Cloud 是 baseline，不是 nice-to-have。
02SIS（Student Information System）跟 Salesforce 怎麼分工？
SIS（PeopleSoft、Banner、Workday Student、台灣常見的校務系統）永遠是註冊狀態、課程、成績、學費的 source of truth——Salesforce 不該複製這層。Salesforce 是「關係 + 招生 + engagement」層：申請流程、招生轉換、學生服務 case、校友互動、捐款追蹤。整合用 event-driven（Platform Events）接 SIS 變動事件，避免 nightly batch 造成的「昨天的資料」問題。
03同一個人是申請者、學生、校友、捐款人，怎麼設計？
用一個 Constituent record（基於 Person Account）+ 多個 lifecycle stage records。優點：同一個人在 30 年內所有互動都在同一條 timeline 上——招生時的學業表現、在學的 advising 紀錄、畢業後的 engagement、捐款歷史，都查得到。Sharing rule 要設計好，讓招生看不到捐款金額、校友辦看不到在校成績——但內部跨單位協作仍能拼出完整脈絡。
04LMS（Canvas / Moodle / Blackboard）整合的範圍？
建議淺整合：LMS 留在 source of truth，Salesforce 只取「engagement 訊號」（登入頻率、作業繳交比例、討論區活躍度）作為輔導 / 留校率預警的 input。深整合（把 LMS 內容拉進 Salesforce）通常 ROI 不划算——LMS 的學習介面本來就不是 CRM 該管的。例外：MOOCs 跟線上學分平台需要把學習進度跟招生 funnel 串起來，這時整合會比較深。
05個資 / FERPA-equivalent 合規怎麼處理？
台灣的教育場景對應的是個資法 + 教育部相關規範 + 校級隱私政策。重點：(1) Day 1 設定 Field Audit Trail（學業紀錄變更要有 trail）；(2) Sharing rule 嚴格分層（招生不能看在學成績、校友辦不能看在校生 case）；(3) Retention policy 對應學籍與校友規範（畢業後通常 5-7 年保留學業紀錄）；(4) 跨機構資料分享（如成績單轉發、推薦信 portal）需要明確 consent 機制。國際學生的場景另外要處理跨境傳輸（含原國 GDPR）。

教育 Salesforce 導入，先從 lifecycle 與 SIS 邊界開始。

我們可以先用 30 分鐘對齊你的招生 / 學生 / 校友流程現況、SIS 與 LMS 的責任分界，再判斷該從 Education Cloud 哪一塊切入。

預約免費諮詢→

我們使用 Cookie

我們使用必要性 Cookie 維持網站運作，並使用選用的分析 Cookie（Google Analytics）了解訪客如何使用本站。詳見 Cookie 政策 與 隱私政策。