後台管理系統怎麼做？套版、SaaS 與客製開發怎麼選，權限、操作紀錄與報表要先規劃什麼

後台管理系統，就是只有公司內部人員看得到的那一半系統：訂單誰來審、會員資料誰能改、報表從哪裡匯出、誰在什麼時候動過哪筆資料，全部在這裡處理。要做一套，有三條路可以走：買現成的 Admin 模板或低程式碼工具自己組、直接用 SaaS 內建的後台、或找人客製開發。選哪條，看的是你的流程有多特別、要管的人有多少種角色。

在我們的客製化系統諮詢經驗中，「後台」這兩個字幾乎每次都出現在需求訪談的第一句話，也幾乎每次都被低估。老闆口中的「做個後台讓我們管訂單」，拆開來常常是六種角色、二十幾個動作、三份每月要交的報表，再加一條「誰改過價格要查得到」。前台畫面大家看得到，會主動討論；後台沒人看到，最容易在報價單上被寫成一行「後台管理功能」，然後在驗收時吵起來。

後台最常被漏掉的是三件事：角色權限、操作紀錄、報表口徑。這三件事決定後台上線後好不好用，也決定報價會不會一路追加。下面先對齊後台通常管哪些事，再比較三條路的費用，最後附一份可以直接交給廠商的需求清單範本與驗收要點。

後台管理系統是什麼？六個常見模組一次看懂

先講結論：一套後台管理系統大致由六塊組成，前兩塊（帳號權限、資料增刪改查）是地基，後四塊依業務需要往上疊。下表是我們在需求訪談時用來對齊範圍的清單，你可以直接拿來勾選自己需要哪幾塊。

很多人以為後台就是「一個能改資料的頁面」，所以只估了 CRUD 的工。實際上 CRUD 通常是最好做的部分，難的是後面四塊：審核流程牽涉到業務規則、操作紀錄牽涉到資料設計、報表牽涉到統計口徑、通知牽涉到串接 LINE 或 Email。這四塊一開始沒講清楚，報價就會一路往上追加。

如果你的後台主要管的是會員或訂單，同主題可以搭配看客製化會員管理系統開發指南與OMS 訂單管理系統開發指南，那兩篇把各自的關鍵決策拆得更細。審核流程很複雜、跨部門簽核很多的，則可以先讀簽核流程系統開發指南。

套版後台、SaaS 內建後台、客製開發：三條路的費用級距與適合誰

一句話分工：資料結構標準、角色少，用 SaaS 內建後台；有工程師、只缺介面，用模板或低程式碼工具；流程特殊、角色多、要長期養，才走客製開發。下表的金額是整理自公開價目與站內行情文章的業界參考，不是恆遠的報價。

價格的來源依序是：Metronic 的官方定價頁、Retool 的官方方案頁（2026 年各家整理的數字略有出入，月繳與年繳差 20% 左右）、站內No-Code 內部工具平台採購指南的團隊規模試算，以及會員管理系統開發指南整理的 SaaS 月費區間。客製開發的級距和系統開發費用拆解、系統開發全景地圖裡單一模組專案的行情一致。

這張圖最常被忽略的分岔是「使用人數」。低程式碼工具按人頭收費，10 個人用很划算，人數一多，一年的訂閱費就追上一期客製開發的費用。反過來，客製開發的維護費跟使用人數幾乎無關，用的人越多越划算。SaaS 與客製的三年總成本怎麼算，可以看SaaS vs 客製化系統比較。

客製這條路我們走過不只一次。最近一個是政府標案：高雄市幼兒園招生系統，要同時服務家長、園所、教育局三種使用者，後台的角色與資料範圍從第一天就得規劃清楚，這個案子在下面講權限時會再拆開說。

後台權限怎麼設計？先畫一張角色 × 動作矩陣

先講結論：權限要用「角色」來管，不要用「人」來管。把公司裡會登入後台的人分成幾種角色，每種角色能做哪些動作畫成一張表，交給廠商之前自己先填完，這是整份需求裡最值錢的一張表。

權限出錯有多常見？OWASP 在 2025 年版的網頁應用十大風險裡，把「存取控制失效」（Broken Access Control）排在第一名，OWASP 官方頁面寫明受測應用程式全部都被找到至少一種這類弱點。意思是：使用者看到不該看的資料、按得到不該按的按鈕，是網頁系統最常見的漏洞，後台又是這個問題最集中的地方。

下面是一個電商後台的矩陣範例，你可以把角色換成自己公司的職稱：

填表時注意三件事。第一，除了「能不能做」，還要寫「能做到哪個範圍」，像店長只能看本店、退款有金額上限，這叫資料範圍，是客製後台最常被漏掉的一層。第二，「匯出」要單獨列一個權限，個資外洩很多時候是從一個沒人管的匯出按鈕開始的。第三，帳號停用要能馬上生效，員工離職當天就要關得掉。

角色數量也直接影響費用。澳洲一份 2026 年的客製軟體費用指南估計，每多一種使用者角色，前後端的複雜度大約增加 15% 到 25%。那是澳洲市場的數字，台灣行情只能參考，但方向很清楚：角色先收斂，報價才收得住。

這件事我們有兩個可以直接看的例子。第一個是自己的產品：恆遠會員中樞系統，把我們幾個自有產品各自重複寫的註冊、登入、訂閱、權限四件事抽成共用中樞，所有產品共用同一套 SSO（Email 與 Google 登入）和同一個授權查詢 API。設計上刻意把「身分與訂閱」和「業務資料」分開，中樞只管使用者是誰、訂閱到什麼時候、有哪些權限，各產品自己存業務資料，一個產品出狀況不會拖垮其他產品。

第二個是客戶案例：高雄市幼兒園招生系統，家長、園所、教育局三端各自有不同的後台視角，園所只能管自己的招生名冊，教育局要看全市狀況。抽籤這種牽涉入學權益的環節，設計上要求全程留痕、事後可以重演驗證。這個案子目前依進度建置中，預計 116 年招生季啟用。公部門系統在角色與稽核上的要求比企業案更嚴，細節可以看政府標案系統開發跟企業案差在哪。

你的後台如果也有三種以上角色、或要讓不同單位只看到自己的資料，可以把現在的角色清單丟給我們，我們先幫你看矩陣哪裡會卡住。

操作紀錄與稽核軌跡：後台出事時唯一能還原真相的東西

先講結論：操作紀錄要在第一版就做進去，晚做的代價很高，因為之前發生過的事永遠補不回來。它回答的只有一個問題：誰，在什麼時候，對哪筆資料，做了什麼，改之前和改之後各是什麼。

我們的判斷是：中小企業的後台，最該花錢的是權限和操作紀錄，報表反而可以晚一點。報表做錯了，重算一次就好；權限設錯、又沒有紀錄，出事時連發生了什麼都說不清楚。Verizon 的2025 年資料外洩調查報告（DBIR）分析了超過一萬兩千起確認的外洩事件，大約六成涉及人為因素，其中帳號憑證被濫用是最常見的入侵起點之一。後台帳號被借用、被盜用、或離職沒關，靠的就是操作紀錄才查得出來。

公部門的要求可以當作上限參考。資通安全責任等級分級辦法附表的資通系統防護基準要求系統產生的日誌要包含事件類型、發生時間、發生位置與相關使用者身分，中級以上還要定期審查日誌。企業不一定要做到這麼完整，但這四個欄位是基本款。

另外三個規劃重點：操作紀錄只能新增、不能修改或刪除，連管理員也一樣；保存期限先跟會計或法務確認，通常配合帳務憑證的保存年限；要提供給非工程師看的查詢畫面，能依人、依日期、依資料篩選並匯出，否則出事時還是得找工程師翻資料庫。

報表、匯出與通知：最常被說「之後再加」的後台功能

先講結論：報表的難處在「統計口徑」，畫面本身反而簡單。同樣叫「本月營收」，含不含稅、算下單日還是出貨日、退貨要不要扣，三個部門可能有三種答案。這些沒在規格裡寫死，報表做出來一定對不上會計的數字。

報表需求簡單的，後台內建幾張固定報表就夠；要跨系統拉資料、讓主管自己拖拉分析的，就是另一個專案了，可以看客製化 BI 報表系統開發指南評估要不要分開做。

通知也一樣，先決定「誰需要在什麼事發生時知道」。常見做法是後台內建待辦清單，再把重要事件推到 LINE 或 Email，例如新的退款申請推給店長、超過金額門檻推給老闆。通知太多會被關掉，所以每一種通知都要問一次：收到的人能做什麼？不能做什麼的，就不要推。

規格怎麼寫給廠商：後台管理系統需求清單範本

先講結論：交給廠商的後台規格，至少要有下面八項。每一項都寫清楚了，不同廠商的報價才比得起來；有一項空白，那一項就是之後追加預算的地方。

這八項寫完，大概就是一份可以拿去比價的需求文件。要再往下寫成 SOW 與規格書，可以照發包前的 SOW、規格書與合約指南的格式補齊；合約條款則可以對照軟體開發合約範本，特別是規格附件與分期驗收那幾條。挑廠商時要問什麼，軟體開發公司怎麼選整理了 12 個發包前必問的問題。

寫規格時也要預留「這一版不做」的清單。後台功能很容易越談越多，先把第一版要做的、第二版再說的分開寫，廠商報價會準很多，你也比較好控管預算。整個開發過程每個階段要交什麼，可以參考系統開發流程的七個節點。

後台管理系統驗收要點：上線前逐項點過

先講結論：後台驗收要用「每個角色各登入一次」的方式測，只用管理員帳號點一遍，等於只驗了一個角色。下面是後台專屬、最容易漏掉的驗收項目，通用的 UAT 流程可以搭配軟體驗收 SOP 與 UAT 測試清單。

• 權限逐角色測：照矩陣，每個角色登入一次，確認看不到、按不到不該有的功能，也要試著直接輸入網址進入受限頁面
• 資料範圍：店長 A 看不到店長 B 的資料，搜尋結果、匯出檔案、報表也要一起確認
• 操作紀錄：故意改一筆資料、匯出一次名單、調整一次權限，確認三件事都有完整紀錄，且紀錄刪不掉
• 帳號停用：停用一個正在登入中的帳號，確認下一個動作就被擋下
• 審核流程：送審、核准、退回各跑一次，確認未核准的變更沒有生效
• 報表對數：拿上個月的實際資料讓會計對一次，數字對得上才算過
• 資料量：用接近正式環境的資料量測列表與匯出速度，幾百筆測試資料測不出效能問題
• 交付物：原始碼、資料庫結構說明、管理員操作手冊、帳號清單都要交接到你手上

驗收通過後，記得把管理員帳號改成自己公司的人持有，廠商只留必要的維護帳號，而且一樣要留操作紀錄。後續的修改與擴充怎麼控管預算，可以回頭看客製化系統開發完整指南裡上線後的部分。