自己做 SaaS 產品指南：多租戶架構白話說明、方案權限、試用與上線營運

很多 SaaS 產品的起點都很相似：一間公司為了解決自己的問題做了一套系統，用得很順手，同業看了也想要，老闆心想「不如把它包裝成產品賣出去」。或是一位創業者看準某個產業的痛點，想做一套SaaS 產品按月收費。這兩條路最後都會遇到同一個問題：做給自己用的系統、和做給一百家公司用的產品，是完全不同的兩件事。

自己用的系統，有問題可以直接找工程師改，規則寫死也沒關係，資料只有自己一家。SaaS 產品則要讓陌生的客戶自己註冊、自己設定、自己上手，每家的資料必須嚴格分開，系統要全年穩定運作，而且一次改版會同時影響所有客戶。

以下用白話說明多租戶架構是什麼、方案與權限怎麼設計、試用與導入流程、上線後的營運責任，以及自己做產品和委託接案開發的根本差別，最後提供一份動手前的自我評估清單。

SaaS 和接案開發有什麼不同

先釐清這件事，因為它決定了你的整個規劃方式。

接案開發是為一個客戶做一套系統，需求由這個客戶決定，驗收、交付後專案就告一段落，後續維護另外約定。成功的標準是「符合這位客戶的需求」。

SaaS 產品是為一群客戶做一套系統，需求要從很多客戶的共同點中歸納，而且永遠不會「交付完成」。成功的標準是「有足夠多的客戶願意持續付費」。

這帶來幾個根本差異：

• 需求來源不同：接案時客戶說什麼就做什麼；做產品時，要學會對個別客戶的特殊要求說「不」，否則產品會變成一堆客製的拼裝。
• 責任期間不同：接案的責任有明確的終點；產品的責任跟著每一個付費客戶持續下去，系統停擺就是所有客戶一起停擺。
• 收入模式不同：接案的收入在開發期間就收到；產品要先投入開發，收入在上線後慢慢累積，前期必須有資金撐過這段時間。
• 團隊需求不同：產品需要有人負責方向、行銷、銷售、客戶支援與營運，不只是開發。

如果你還在評估要做成產品還是只做給自己用，可以先參考買現成 SaaS 還是客製開發的判斷框架，從使用者的角度反過來看這件事。

多租戶架構白話說明

**租戶（tenant）**就是你的每一個客戶公司。多租戶架構的意思是：同一套系統同時服務很多家公司，但每家公司只看得到自己的資料。

用大樓來比喻最好懂：

• 共用資料庫、共用資料表：像一棟辦公大樓的開放空間，每家公司的東西都放在同一個大倉庫，靠貼標籤區分是誰的。成本最低、維護最簡單，但標籤只要貼錯一次，資料就可能被別家看到。
• 共用資料庫、各自獨立的資料區：像同一棟大樓裡每家公司有自己的房間，共用電梯與管理處。隔離性較好，但房間數一多，管理與改版的工作量也會增加。
• 每家獨立資料庫或獨立部署：像每家公司各有一棟房子。隔離最徹底，也最容易滿足特殊的資料保存要求，但每多一個客戶就多一套要維護的環境。

多數 SaaS 產品從第一種或第二種起步，再為少數有特殊要求的大客戶提供獨立部署。選哪一種沒有標準答案，但有幾個原則一定要守住：

租戶判斷要集中處理。每一次讀寫資料都必須帶上「這是哪個租戶」的條件。這個判斷應該在系統的同一個地方統一處理，而不是讓每位工程師在每一支程式裡自己記得加。只要一個地方忘記，就是資料外洩。

要有自動化測試守住隔離。刻意用 A 公司的帳號去讀 B 公司的資料，確認一定被擋下來。這類測試要在每次改版都跑。

檔案與備份也要隔離。上傳的附件、匯出的報表、系統備份，同樣要能依租戶區分；客戶要求刪除資料時，要能把屬於他的資料完整移除。

要預防「吵鬧的鄰居」。某一家客戶大量匯入資料或跑大型報表時，不應拖慢所有人的速度。需要限制單一租戶的資源使用，並把耗時的工作放到背景處理。

主機與雲端環境的選擇也會影響架構，可以參考中小企業雲端主機方案選擇。

方案與權限：兩層不同的控制

SaaS 的權限有兩個層次，很容易混在一起：

第一層是方案（租戶層級）：這家公司買了什麼方案，能用哪些功能、有多少額度。例如基本方案不含報表匯出、進階方案可以設定自訂欄位、使用者人數上限依方案而定。

第二層是角色（使用者層級）：在這家公司裡面，每個人能做什麼。例如管理員可以新增使用者與修改設定、一般成員只能處理自己的資料、檢視者只能看不能改。

設計時的重點：

• 功能開關要做成設定，不要寫死在程式判斷方案名稱。程式裡寫「如果是進階方案就顯示」，日後方案調整時要改遍整份程式碼；改成「這個方案是否包含某項功能」的設定，調整方案時只要改設定。
• 方案降級時的處理要先想好：降級後超出額度的使用者怎麼辦？已經建立的進階功能資料是否保留但唯讀？
• 讓客戶自己管理使用者：新增、停用、指派角色應該由客戶的管理員自己操作，而不是寫信請你幫忙。
• 考慮企業客戶的登入需求：較大的客戶可能要求用他們公司的帳號系統登入，可以參考社群登入與 SSO 單一登入指南預先規劃。
• 保留系統管理者的後台：你自己的團隊需要一個跨租戶的管理後台，用來查看客戶狀態、處理支援問題，這個後台本身的權限與操作紀錄同樣要嚴格管理。

方案的計費與定期扣款是另一個獨立的主題，包含扣款失敗、升降級按比例計費、發票開立等，詳細做法可以參考同站關於訂閱收費與金流的文章，例如台灣金流串接指南與台灣電子發票串接指南。

試用與導入：客戶能不能自己上手

SaaS 和接案系統最大的體驗差異，在於客戶第一次使用時身邊沒有你。接案時你會幫客戶設定好一切、開教育訓練；SaaS 客戶則是註冊後自己摸索，摸不懂就離開。

試用與導入流程要設計的幾件事：

註冊流程要短。只問真正必要的資料，其餘可以之後再補。每多一個欄位，就多一些人在中途放棄。

第一次登入不要是空白畫面。提供範例資料、引導步驟，或是讓客戶從範本開始，讓他在短時間內看到這個產品能幫他做什麼。

找出「啟用的關鍵動作」。每個產品都有一兩個動作，是客戶完成之後才真正感受到價值的時刻，例如匯入第一批資料、邀請第一位同事、送出第一張單據。試用期的引導都應該朝這個動作前進。

試用期的狀態要清楚。剩下幾天、試用結束後會怎樣、資料會不會保留，都要讓客戶隨時看得到。

提供人工協助的管道。尤其是賣給中小企業的產品，許多客戶仍然需要有人陪他設定。初期由創辦團隊親自協助導入，也是最快了解客戶真實需求的方式。

觀察客戶在哪裡卡住。記錄試用客戶的使用行為，看他們在哪一步停下來、哪個功能從來沒被點開，這些資訊比任何訪談都誠實。蒐集使用資料時要遵守個資與隱私規範，相關原則可參考隱私權政策與個資法。

上線之後：營運責任才是真正的開始

接案專案上線是終點，SaaS 上線是起點。以下是上線後必須有人負責的事：

穩定性與監控：系統要有監控與告警，出問題時有人收到通知並處理。要事先決定誰在下班時間待命、多久內要回應。

備份與還原：定期備份不夠，還要定期演練還原，確認真的能把資料救回來。客戶誤刪資料要求復原時，也要有可行的程序。

版本更新：所有客戶共用同一套系統，每次更新都會影響所有人。需要有測試環境、分批上線或功能開關，以及更新出問題時的回退方式。重大變更要事先通知客戶。

客戶支援：要有明確的支援管道與回覆時間，常見問題要整理成說明文件。

資安與合規：權限管理、存取紀錄、弱點修補、客戶對資料安全的提問與稽核要求，都會隨客戶規模變大而增加。

產品路線：客戶會不斷提出新需求，需要有一套方法決定先做哪些。這部分可以參考產品上線後的路線圖規劃。

資料匯出與離開：客戶有權帶走自己的資料，提供完整的匯出功能，反而會讓新客戶更願意信任你。

從 MVP 開始，而不是一次做完

做 SaaS 最大的風險，是花了很長時間做出一套功能完整的產品，上線後才發現沒有人願意付費。比較穩健的做法是先做 MVP（最小可行產品）：只做能解決核心問題的最小範圍，盡早讓真實客戶使用並付費，再依照回饋擴充。

設想一間做餐飲排班系統的團隊：MVP 可能只包含排班與換班，先不做薪資計算與報表；找幾家願意試用的店家實際跑一段時間，確認他們願意持續使用、也願意付費之後，再決定下一個要做的功能。

做 MVP 時，多租戶隔離、權限與備份這類基礎不能省，因為這些事後補做的代價很高；可以省的是周邊功能與介面的精緻度。具體做法可以參考 MVP 開發指南。

動手前的自我評估清單

在投入開發之前，建議先誠實回答下面這些問題。答不出來的項目，就是接下來要先釐清的事：

市場與客戶

• 誰會付費？他們目前用什麼方式解決這個問題？
• 是否已經有幾家潛在客戶願意試用，甚至願意預付？
• 他們的流程彼此之間差異有多大？哪些可以標準化？

產品範圍

• MVP 只做哪些功能？哪些明確先不做？
• 方案要怎麼分？依功能、依人數，還是依用量？

技術基礎

• 多租戶要採哪一種隔離方式？是否有客戶有特殊的資料保存要求？
• 登入、權限、計費、發票要自己做還是使用現成服務？

營運能力

• 上線後誰負責客戶支援？誰在下班時間處理系統問題？
• 誰負責決定產品方向，並對客戶的特殊要求說「不」？

資源與時間

• 從開發到有穩定收入，團隊與資金能撐多久？
• 開發要全部自己來、部分委外，還是先委外再逐步內化？

最後兩題往往最關鍵。SaaS 是一場長跑，技術只是其中一環，能不能持續營運到客戶夠多，才是成敗的分水嶺。

把一套系統變成產品，最難的通常不是寫程式，而是決定哪些該做成可設定、哪些該堅持標準化，以及上線後誰來承擔營運。如果你正在規劃自己的 SaaS 產品，想先釐清 MVP 範圍、多租戶架構與方案權限的設計，可以和 NETVANA 聊聊你的產品構想。我們的軟體服務一律採詢問報價制，會依你的階段建議從哪一段開始合作，可以是架構規劃、MVP 開發，或上線後的持續維運；服務內容可參考軟體服務介紹。

延伸閱讀：先用最小範圍驗證產品方向，看 MVP 開發指南；上線後的功能怎麼排優先順序，讀產品上線後的路線圖規劃；主機與雲端環境怎麼選，參考中小企業雲端主機方案選擇；企業客戶要求用自家帳號登入，看社群登入與 SSO 單一登入指南；產品需要跟客戶既有系統串接，先讀系統整合與 API 串接開發指南。