企業買線上課程後，報表需求很容易從一句：
「可以多給我們一個部門欄位嗎？」
慢慢變成：
- 要再加主管姓名。
- 要按照事業部拆分。
- 要把完成率改成公司自己的計算方式。
- 要每週固定寄 Excel。
- 要跟 HR 系統的員工編號對上。
- 要做一個公司專屬 Dashboard。
如果每一項都直接回答「可以」，原本只是企業課程交付，很快就會變成一個沒有邊界的報表開發案。
先分清楚：標準報表、設定調整、客製開發不是同一件事
| 類型 | 典型需求 | 處理方式 |
|---|---|---|
| 標準報表 | 既有完成率、名單、證書、進度 | 方案內提供 |
| 可設定報表 | 換篩選條件、日期、部門、排序 | 若系統已有功能，可由管理員設定 |
| 一次性客製 | 新增欄位、公式、版面或特殊匯出 | 先估工再報價 |
| 持續整合 | 外部資料來源、自動同步、API／BI 串接 | 視為長期維護項目 |
這四類如果不先分清楚，客戶和供應商對「客製」的理解通常不一樣。
標準報表應該先商品化，不要每個企業都從零做
企業最常看的資料其實高度重複。
例如：
- 購買席次。
- 已開通人數。
- 開始學習人數。
- 課程完成率。
- 未完成名單。
- 測驗成績。
- 證書狀態。
- 最後學習時間。
這些資料如果每次都要人工重新整理，就是產品還沒有標準化。
比較好的做法是把「企業基本報表」先固定下來，明確寫進方案：
買這個企業方案，本來就會拿到哪些欄位、什麼格式、多久提供一次。
企業進度報表與權限怎麼設計，可以搭配 企業客戶要看學員進度怎麼辦？管理員、完成率、報表與個資邊界怎麼設計。
「換篩選條件」不一定需要客製開發
成熟的報表系統通常會先有一套資料來源，再讓使用者選：
- 日期區間。
- 部門。
- 課程。
- 學員狀態。
- 完成／未完成。
像 Salesforce、HubSpot 這類企業系統，標準報表與客製報表的差異，本質上也和「可用的資料來源、欄位、物件關聯、篩選與計算」有關。
如果客戶只是要：
「把全公司改成只看行銷部。」
而你的系統本來就有部門篩選，那比較像使用設定，不一定要當成客製專案。
判斷客製前，先問 6 個問題
- 誰要看？ HR、主管、採購、IT 還是財務。
- 要拿來做什麼決策？ 追進度、結案、續約還是稽核。
- 需要哪些欄位？ 欄位現在有沒有被系統記錄。
- 資料從哪裡來？ 課程網站內，還是企業外部系統。
- 多久產生一次？ 一次性、每月、每季或即時。
- 格式是什麼？ CSV、Excel、PDF、Dashboard 或 API。
如果這六題答不清楚，就不適合直接報一個「客製報表費」。
最大的成本通常不是畫表格，而是資料來源
一個報表看起來只有十個欄位，但實際工作量可能差很多。
例如企業要求：
「我要每位員工的部門、主管、職級、課程完成率和年度績效一起看。」
你的課程網站可能只有：
- 姓名。
- 電子郵件（Email）。
- 課程進度。
- 測驗結果。
部門、主管、職級、年度績效都在企業 HR 系統。
這時問題已經不是「新增四欄」，而是：
- 怎麼取得外部資料。
- 用什麼識別欄位對應人員。
- 誰負責資料正確。
- 多久同步一次。
- 員工離職、轉調後怎麼更新。
只要開始跨系統，維護成本就會明顯提高。
客製公式也要算進範圍，不只是資料欄位
有些企業會說：
「我們不要你原本的完成率，我們公司的完成定義不一樣。」
例如企業定義：
- 看完影片 80%。
- 測驗至少 85 分。
- 作業全部繳交。
- 主管確認實作完成。
四項都完成才算「完成」。
這已經不是單純顯示既有欄位，而是新增一套企業專屬商業規則。
只要計算公式會影響報表結果，就應該把公式寫進需求規格，避免雙方日後對同一個「完成率」得到不同答案。
客製報表最好拆成「一次性建置」和「持續維護」
最容易低估的是後續維護。
第一次做完後，企業可能會再遇到：
- 新增部門。
- 改員工編號格式。
- 更換 HR 系統。
- 新增課程。
- 更換完成率定義。
- 報表欄位名稱改版。
所以報價時可以拆成：
一次性建置
包含需求確認、欄位設計、公式、版面、測試與第一次交付。
後續維護
包含欄位變更、資料來源變更、錯誤排查、版本調整或固定週期產出。
不要讓一次性建置費，被視為「未來所有修改都免費」。
什麼情況適合包含在企業方案裡？
如果某個報表需求：
- 很多企業都會用。
- 資料已經存在。
- 不用新增外部串接。
- 維護成本低。
- 能提高續約價值。
那它可能值得變成標準功能。
例如：
- 部門完成率。
- 未完成名單。
- 證書匯出。
- 季度使用摘要。
這種功能一旦產品化，就不需要每個客戶重做。
什麼情況應該另外報價？
如果需求包含：
- 新增外部資料來源。
- 建立企業專屬公式。
- 新增特殊資料欄。
- 建立專屬 Dashboard。
- 固定自動寄送特定格式。
- 和 HR／BI／LMS 系統整合。
- 長期維護企業專用版本。
就比較適合單獨估工與報價。
因為它的價值和成本都只服務少數企業，不應由所有一般客戶一起吸收。
客製報價不要只看「做多久」，還要看長期責任
同樣兩天可以完成的需求，後續責任可能完全不同。
例如：
報表 A
一次匯出特殊 CSV，完成後結案。
報表 B
每週自動同步企業 HR 資料、計算專屬 KPI、寄給主管，而且未來企業系統改版還要跟著維護。
兩者第一次做的時間可能差不多，但 B 的長期責任高很多。
因此客製報價至少要考慮：
- 開發工時。
- 測試成本。
- 資料敏感程度。
- 外部系統依賴。
- 錯誤後影響。
- 後續維護頻率。
客製報表要標明資料來源，不要讓同一欄數字有兩個版本
企業一旦同時有課程平台、HR 系統、CRM 或 BI 工具，同一個欄位可能在不同地方都存在。像部門、主管、在職狀態、完成率，都要先指定哪一套系統才是主資料來源。
報表需求最好不只列「要哪些欄位」，也記錄每個欄位從哪裡來、多久更新、誰負責正確性。這樣數字不一致時，才能知道應該修哪一邊，而不是人工挑一個看起來合理的版本。
資料欄位要先做一份「資料字典」
企業說「我要完成率」，雙方可能理解不同。
所以客製報表需求最好列出：
| 欄位 | 定義 |
|---|---|
| 學員 ID | 企業提供的員工編號或系統會員 ID |
| 開始日期 | 第一次進入課程的日期 |
| 完成日期 | 符合完成條件的日期 |
| 完成率 | 依約定公式計算 |
| 部門 | 由企業提供或系統欄位 |
資料字典可以避免同一個欄位名稱，到了驗收時才發現雙方定義不同。
還沒被記錄的資料，報表做不出來
這點要在銷售時說清楚。
如果企業問：
「可不可以顯示學員看影片時有沒有專心？」
但系統根本沒有這項可合理衡量的資料，就不能因為「客製報表」四個字而答應。
報表只能建立在：
- 已存在的資料。
- 可以合法蒐集的資料。
- 有明確定義的資料。
如果要新增追蹤，還要另外評估技術與個資必要性。
客製報表也要有權限邊界
企業要求的欄位，不代表每一位主管都可以看。
例如：
- HR 可看全公司。
- 部門主管只看自己的部門。
- 學員只看自己的紀錄。
- 採購只需要看整體使用率。
報表權限怎麼分層，可以搭配 企業客戶要看學員進度怎麼辦？管理員、完成率、報表與個資邊界怎麼設計。
公式與欄位變更要有版本，不要直接覆蓋歷史定義
企業若把完成率、活躍率或 KPI 公式改掉，新的算法不應默默套到所有歷史月份，否則前後趨勢會失去可比性。最好記錄公式版本與生效日期，報表上也能標明目前使用哪一版定義。
欄位名稱、部門分類或資料來源變更也是同樣道理。重大變更先確認影響，再決定從哪一天開始使用；需要比較歷史時，保留舊版口徑或重新計算的規則。
驗收標準要在開發前寫，不要完成後才問「這樣算不算好」
至少確認：
- 要有哪些欄位。
- 欄位順序。
- 資料期間。
- 篩選條件。
- 計算公式。
- 格式。
- 更新頻率。
- 誰能看。
如果是自動化報表，還要確認：
- 什麼時間更新。
- 失敗怎麼通知。
- 外部資料缺失時怎麼處理。
這些就是驗收基準。
不要因為大客戶要求，就立刻把客製功能做進所有人的主系統
企業客製功能有一個常見風險：為了成交一個大客戶，把整套產品做得越來越複雜。
比較好的判斷是：
- 這是不是多數企業都需要。
- 會不會提高所有客戶價值。
- 是否值得成為企業版標準功能。
- 還是只有這一家公司的內部流程才需要。
如果只對單一客戶有價值，就比較適合做成加價模組或專案，而不是塞進所有人的基本方案。
定期報表最好保留交付快照，日後才有辦法重現
如果企業每月或每季固定收到報表，建議保留當期輸出版本與資料期間。因為後續名單、部門、課程狀態或公式可能改變，半年後重新跑一次，不一定會得到當時完全相同的結果。
保留快照能讓雙方在查核、續約或爭議時，知道「當時實際交付的是哪一版資料」，也能避免歷史報表被後續變更悄悄改寫。
標準報表可以成為續約資產，客製報表則要看回收
企業續約時，報表通常會扮演重要角色。
如果標準報表能直接回答：
- 席次用了多少。
- 哪些部門完成。
- 哪些人沒有啟動。
- 成果如何。
它本身就能幫助續約。
企業版課程的季度與續約資料，可以搭配 企業版線上課程怎麼續約？席次使用率、完成率、成果報告與下一年度提案怎麼做。
一張表判斷：包含、設定、客製還是整合？
| 需求 | 建議分類 |
|---|---|
| 下載既有完成率 | 標準報表 |
| 只看某部門 | 可設定報表 |
| 新增企業專屬欄位 | 一次性客製 |
| 新增企業專屬公式 | 一次性客製 |
| 每週自動寄特定格式 | 客製＋維護 |
| 接 HR／BI 系統 | 系統整合＋維護 |
常見問題
企業只是多要一個欄位，也要收費嗎？
不一定。若欄位原本就存在、只是顯示或匯出設定，可以包含在服務中；若需要新增資料蒐集、資料關聯、計算或程式開發，就應重新評估成本。
客製報表應該按次收費還是訂閱？
一次性產出可用專案費；若涉及固定更新、資料串接與持續維護，較適合把維護另外計價。重點是不要把長期責任藏在一次性費用裡。
客戶改需求要不要免費修改？
可以先定義包含幾輪需求確認與驗收修正。超出原需求、增加欄位或改公式，應視為範圍變更，而不是默認無限修改。
企業要 Excel 就一定很簡單嗎？
不一定。格式只是輸出端，主要成本通常在資料來源、欄位定義、計算與資料關聯。Excel 也可能是一個很複雜的客製報表。
企業要即時 Dashboard，和每月報表差很多嗎？
通常會差很多。即時或近即時報表牽涉資料更新、權限、錯誤處理與長期維護，應和一次性匯出分開評估。
什麼時候應該把客製需求做成標準功能？
當多個企業反覆提出相同需求，而且資料來源與維護成本可控時，就值得產品化；若只服務單一企業流程，保留為客製項目通常更乾淨。
結論：先賣「標準報表」，再賣「客製價值」，不要賣無限修改
企業客戶要求客製報表本身不是問題，問題是沒有邊界。
先把企業方案本來就包含的標準報表固定下來；能用篩選與設定解決的需求，就不要做成程式開發。
如果要新增資料來源、欄位、公式、外部串接或固定自動化，就先定義需求、驗收、一次性建置與後續維護責任，再決定是否加價。
這樣客製報表才會是一個有價值的企業加購項目，而不是成交後不斷增加的免費工作。
參考資料：
Salesforce Help｜Custom Report Types。
Salesforce Help｜Create a Custom Report。
HubSpot Knowledge Base｜Create reports with the custom report builder。
Microsoft Learn｜Connect to semantic models in Power BI。